Dac for an arcam delta 170.3 transport

Dedicated to the silver disk spinner
User avatar
Nick
Site Admin
Posts: 13662
Joined: Sun May 06, 2007 10:20 am
Location: West Yorkshire

#31 Re: Dac for an arcam delta 170.3 transport

Post by Nick »

Yep, and I suggested the first thing to try was to see if we could convert the data stream from the sb and the transport back into a WAV file to see if there was any difference there.
Little known fact, coherent thought can destructively interfere with itself leaving no thought at all, that’s why I prefer incoherent thought.
User avatar
ed
retired
Posts: 4716
Joined: Thu Jun 21, 2007 4:01 pm
Location: yorkshire
Contact:

#32 Re: Dac for an arcam delta 170.3 transport

Post by ed »

Ant wrote: Thu Sep 24, 2020 9:47 am The thing that i was commenting on is the fact that the squeezebox into the topping dac sounds fine, but the cd transport into the topping dac sounds different.
Oh...my bad, I did misunderstand, apologies!
There's nowhere you can be that isn't where you're meant to be
Ant
Needs to get out more
Posts: 1663
Joined: Mon Jul 31, 2017 6:45 pm
Location: Yorkshire

#33 Re: Dac for an arcam delta 170.3 transport

Post by Ant »

No worries ed, its just piqued my interest

I wonder if this soundcard would provide a way of accessing the data somehow, with its optical in, though is have thought it was just a dac

https://www.ebay.co.uk/itm/274468255000

I was looking at it for the kids gaming pc as it doesnt have a nice soundcard, it just uses the soundcard part on the motherboard. I neglected the soundcard when i had it built and put the money into the graphics card at the time
Also starring Rex Hamilton as Abraham Lincoln

www.bte-designs.weebly.com
User avatar
pre65
Amstrad Tower of Power
Posts: 19559
Joined: Wed Aug 22, 2007 11:13 pm
Location: North Essex

#34 Re: Dac for an arcam delta 170.3 transport

Post by pre65 »

Ant, do you have a preference between the two "different" end results, and is it the same with different genres of mooooooosic ?

This 2011 review of the Delta 170.3 found no discernible difference compared to other digital output CD players.

https://www.stereophile.com/content/arc ... -transport
Last edited by pre65 on Thu Sep 24, 2020 10:29 am, edited 1 time in total.
Life is what happens to you while you're busy making other plans. John Lennon

G-Popz THE easy listening connoisseur. (Philip)
User avatar
Nick
Site Admin
Posts: 13662
Joined: Sun May 06, 2007 10:20 am
Location: West Yorkshire

#35 Re: Dac for an arcam delta 170.3 transport

Post by Nick »

If its got optical in (which it seems to have) then yep, that would do it.
Little known fact, coherent thought can destructively interfere with itself leaving no thought at all, that’s why I prefer incoherent thought.
Ant
Needs to get out more
Posts: 1663
Joined: Mon Jul 31, 2017 6:45 pm
Location: Yorkshire

#36 Re: Dac for an arcam delta 170.3 transport

Post by Ant »

pre65 wrote: Thu Sep 24, 2020 10:23 am Ant, do you have a preference between the two "different" end results, and is it the same with different genres of mooooooosic ?
Yep i do phil, i have been finding the delta is alot better
I played loads of stuff yesterday, martin taylor, claire martin, art pepper, feeder, some foo fighters, and other stuff. ( i ended up delving into the cds i bought as a teenager, placebo, oasis, garbage, ect, and nearly forgot to pick son no 2 up from school :oops: )and the delta was better to me every time

I think ill get that soundcard, the kids use headphones with it anyway as its downstairs in the dining room and i dont want to hear the music and generally gunfire from their games.....
Llus they are always moaning that the headphoes cut out because the socket is abit wonky

Ive read that review too, its originally from 1989 iirc, and i though the same thing before, hence the question
Also starring Rex Hamilton as Abraham Lincoln

www.bte-designs.weebly.com
JamesD
Old Hand
Posts: 894
Joined: Tue Oct 09, 2007 4:26 pm
Location: North Yorkshire

#37 Re: Dac for an arcam delta 170.3 transport

Post by JamesD »

Nick said
Yep, but on top of the wifi stack will be a TCP/IP (or UDP) endpoint, so you should (will) get error free transmission or no data. The world as we know it would stop if there was errors in what comes out of a socket interface.
That doesn't match my (and my colleagues) experience with video and audio links between IP endpoints where we have route associated errors in the encoded video and/or audio data streams but the TCP/IP or UDP layer isn't showing associated errors. The clearest case I have of this was an IP route between Washington DC and Rome that had these errors when routed via Frankfort switching centre but not when routed through France (forget the exact path) so layer three path switching caused these errors to appear or disappear- we were never told what the network experts found to be the cause and I guess it could have been caused in the signal processing along the route between the IP layer and the Application layer...

We have also seen these errors in studios when multiple WiFi channels has been used to route multiple audio and video devices around that closed environment and increasing channel separation has helped remove or ameliorate the problem...

This is beyond my expertise so I don't know the cause beyond speculation but 'cleaning up the signal path either at rf or physically affects a cure (partial or complete).

Not sure what else I can add as this is purely anecdotal but I love to understand it more... Happy to continue discussing it though :D

Ant - Sorry to add noise into your thread...

j.
Ant
Needs to get out more
Posts: 1663
Joined: Mon Jul 31, 2017 6:45 pm
Location: Yorkshire

#38 Re: Dac for an arcam delta 170.3 transport

Post by Ant »

Not noise james, its all related to the question :D
Also starring Rex Hamilton as Abraham Lincoln

www.bte-designs.weebly.com
User avatar
Nick
Site Admin
Posts: 13662
Joined: Sun May 06, 2007 10:20 am
Location: West Yorkshire

#39 Re: Dac for an arcam delta 170.3 transport

Post by Nick »

That doesn't match my (and my colleagues) experience with video and audio links between IP endpoints where we have route associated errors in the encoded video and/or audio data streams but the TCP/IP or UDP layer isn't showing associated errors. The clearest case I have of this was an IP route between Washington DC and Rome that had these errors when routed via Frankfort switching centre but not when routed through France (forget the exact path) so layer three path switching caused these errors to appear or disappear- we were never told what the network experts found to be the cause and I guess it could have been caused in the signal processing along the route between the IP layer and the Application layer...
What makes me question if this was a TCP or UDP link was you know how it was routed, but it may be that the transport software preferred timely arrival of data over error free data, so replaced drop outs with something else. I know ISDN was used for a lot of data links, and there you would setup a fixed path, and depending on the protocol used (x25 was common and error corecting, but others could be used) may or may not be error free.
We have also seen these errors in studios when multiple WiFi channels has been used to route multiple audio and video devices around that closed environment and increasing channel separation has helped remove or ameliorate the problem..
Again, cant say, but again without knowing what protocol stack was used. But if you have a TCP link I have never seen a case of data corruption. Not saying it can't happen. The IP checksum will fail to catch a error 1 in 64k packets, but there are normally more than just the one checksum in the chain, so the likleyhood of error is small. I found a paper that puts it at between 1 in 16 million to 10 billion packets could contain an uncaught error.
Little known fact, coherent thought can destructively interfere with itself leaving no thought at all, that’s why I prefer incoherent thought.
JamesD
Old Hand
Posts: 894
Joined: Tue Oct 09, 2007 4:26 pm
Location: North Yorkshire

#40 Re: Dac for an arcam delta 170.3 transport

Post by JamesD »

Thanks Nick,

I'll check my notes to see what other info I have kept - particularly around the 'stack' it was running on but from what you have said it seems you think it was either a UDP connection and hence dropped packets are preferable to interruption of the stream continuity as in, for instance, a real time 'broadcasting' link or, if it was a TCP/IP link, something was happening above layer four that caused encode data loss rather than transport packet loss i.e a session layer or higher problem. That makes some sort of sense to me (my limited understanding not yours!) and seems to fit the anecdotal evidence that I have.

thanks

James
User avatar
Nick
Site Admin
Posts: 13662
Joined: Sun May 06, 2007 10:20 am
Location: West Yorkshire

#41 Re: Dac for an arcam delta 170.3 transport

Post by Nick »

above layer four
Ahh, the old OSI model, kids today will wonder what you are talking about :-)

It may be the case that something in the system was running out of processing power/time, depends on what encoding/decoding was going on. Or it could have just been a bug?
Little known fact, coherent thought can destructively interfere with itself leaving no thought at all, that’s why I prefer incoherent thought.
JamesD
Old Hand
Posts: 894
Joined: Tue Oct 09, 2007 4:26 pm
Location: North Yorkshire

#42 Re: Dac for an arcam delta 170.3 transport

Post by JamesD »

Yeah OSI 7 layer model- isn't it still relevant? It helps and old dinosaur think about these things :?

What do the kids use now-a-days?
User avatar
Nick
Site Admin
Posts: 13662
Joined: Sun May 06, 2007 10:20 am
Location: West Yorkshire

#43 Re: Dac for an arcam delta 170.3 transport

Post by Nick »

Not sure it was ever relevant as the top layer (If I remember involved Corba). Ok, that's a bit harsh.IP was what happened and while you can push that into the OSI model, its not as segregated (and RFC 3439 explains why).
What do the kids use now-a-days?
Magic pigeon transport wrapped around by a library for the language of this week, which is normally written in the language of last week and so on down until it hits BSD sockets).
Little known fact, coherent thought can destructively interfere with itself leaving no thought at all, that’s why I prefer incoherent thought.
User avatar
Nick
Site Admin
Posts: 13662
Joined: Sun May 06, 2007 10:20 am
Location: West Yorkshire

#44 Re: Dac for an arcam delta 170.3 transport

Post by Nick »

Oh, and while there is a non zero chance that a error could creep in past the multiple check sums. The chances of it resulting in a continuous small change in the sound that comes out of the DAC instead of a click or burst of noise is zero.

I can see network problems causing more or less jitter on the output because of power supply and general system timing issues, but again, that's then down to the DAC receiver being able to clean up the input. If the data stream is the same (using the sound card) then there is only the receiver left to cause a difference in sound. If the data stream is different that will be interesting.
Little known fact, coherent thought can destructively interfere with itself leaving no thought at all, that’s why I prefer incoherent thought.
JamesD
Old Hand
Posts: 894
Joined: Tue Oct 09, 2007 4:26 pm
Location: North Yorkshire

#45 Re: Dac for an arcam delta 170.3 transport

Post by JamesD »

Nick,

Many thanks for that and the reference to RFC3439 - a fascinating read for me as I developed the first MPEG multiple transport stream video server and had to build it on an ATM infrastructure running MPEG packets over the ATM network I actual understood the points it made - well some of them! We had fun with realtime switching of mpeg streams at the ATM level without packet loss or triggering a re-sync of the receiver - that took quite some work and was very inefficient in carrying MPEG packets in the ATM data frames but we did get the switching down to just a single packet loss on switching and since this was for redundancy switching between A/B video servers this was acceptable (the video servers would fail about once every six hours and need an application re-start). This was for a PAY per View service so we had to maintain the multiplexed broadcast stream output... The first one cost about $600,000 but was still 50% cheaper than the video playout systems and MPEG encoders, etc that it replaced... Three years later we replaced the ATM infrastructure with IP infrastructure running UDP connections over a closed network - even less efficient but much easier to get working and cheaper - and by then we could get away with a few more lost packets on A/B switching so we effectively crashed switched as the receiver was much faster to re-lock. James
Post Reply