2. digital
  3. 190027-170711

why expensive streamers

@soix and others

I am unclear about the effect on sound of streamers (prior to getting to the dac). Audio (even hi-res) has so little information content relative to the mega and giga bit communication and processing speeds (bandwidth, BW) and cheap buffering supported by modern electronics that it seems that any relatively cheap piece of electronics would never lose an audio bit. 

Here is why. Because of the huge amount of BW relative to the BW needs of audio, you can send the same audio chunk 100 times and use a bit checking algorithm (they call this "check sum") to make sure just one of these sets is correct. With this approach you would be assured that the correct bits would be transfered. This high accuracy rate would mean perfect audio bit transfer. 

What am I missing? Why are people spending 1000's on streamers?

thx

 

128x128delmatae
mitch2
3,910 posts
 

@andy2 

So, if you connect your server to your streamer using an optical cable, and USB from the streamer to a DDC that reclocks, and then a short s/pdif or AES/EBU to the DAC, are the bases mostly covered? 

andy2
1,545 posts
 

 The sole purpose of this fifo would be to take care of the streamer noise. 

I don't think the FIFO (or what I called a memory buffer) can isolate the noise.  I think you may be referring to data jitter - I am talking about ground and power supply noise.  The noise from the streamer can inject directly to the ground and power supply of the DAC.  I am not sure that the FIFO can fix that. 

As for data jitter, yes the FIFO can eliminate that if you are using asynchronous USB interface.  All you have left is the jitter of the DAC clock itself. 

andy2
1,545 posts
 

So, if you connect your server to your streamer using an optical cable, and USB from the streamer to a DDC that reclocks, and then a short s/pdif or AES/EBU to the DAC, are the bases mostly covered? 

If I understand correctly, what you have is a s/pdif interface to the DAC - it's not asynchronous USB.  So you're still dealing with the data jitter in the spdif interface.  Spdif is a synchronous interface so you still have to recover the clock from the data stream.  If the data stream has jitter, then the recovered clock also has jitter.  Basically the the clock has to move with the data.  

DCS solves this problem by using what they call "reverse clocking".  Basically you have the clock of the DAC clocking the data stream from the transport or streamer.  In this case you would have something similar to asynchronous USB clocking.

 

mitch2
3,910 posts
 

I can use either s/pdif, AES/EBU, or USB into the DAC.  I could run USB directly from the streamer into the DAC, or I can run the USB from the streamer into the DDC where the signal is reclocked and then from there to the DAC by either s/pdif or AES/EBU.  All three sound good with no discernable noise but maybe a slight sonic difference between USB and the other two.  Any technical reasons one should be better than the other?

andy2
1,545 posts
 

^^^ I see that your DAC can take either spdif or usb. In general asynchronous usb is better than spdif everything else being equal - though it will also depend on implementation.

More to discover