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

 

delmatae

Showing 4 responses by jaytor

I seriously doubt that the difference in streamers has anything to do with data integrity. I would expect that every streamer can deliver the digital information to the DAC without introducing any data errors. 

But DACs are very sensitive to analog noise and timing errors on the digital data signal. Higher-end DACs put a lot of effort into minimizing these effects by using digital isolators, reclocking, PLLs, etc. but these DACs also tend to be more resolving allowing differences in streamers to be more obvious. 

High-end streamers go to great pains to minimize noise and clock errors by utilizing complex data isolation and FIFO reclockers, extremely high-accuracy clocks with low jitter and phase noise, ultra-quiet power supplies (even battery or ultra-capacitor powered), high-bandwidth digital line drivers, etc. to deliver the cleanest possible signal to the DAC. This does not come cheap. 

How much this affects sound quality will, of course, depend on the DAC being used, how noisy the signal to the streamer is, the cables and connection type being used, and the resolving power of the overall system. 

But if I was spending $20K on a DAC, I certainly wouldn't expect to get the best out of it with a $500 streamer. 

@delmatae - yes, that is the approach used by many DACs (including my Denafrips Terminator Plus), and this helps, but doesn't fully solve the problem. A FIFO buffer can be used to reduce timing errors, but as @andy2 notes, this doesn't really deal with noise issues.

And if a synchronous data interface is used (such as SPDIF, I2S, TosLink, or AES), there are challenges with FIFO buffers. In these cases, the source clock is used to clock data into the FIFO. If the DAC uses its own clock to clock data out, then you risk overflow or underflow conditions. Many Denafrips users reported this problem, particularly those using the lower-end models connected to modest-priced streamers and transports (where the clock accuracy of both devices is not as tight as higher-end models). . 

Many DACs use a phase-locked loop or some other similar mechanism to adjust the output clock frequency to match the input clock, but its significantly more difficult to achieve the timing accuracy with this approach compared to a high quality oscillator. 

There are ways to reduce the overflow/underflow potential, such as resetting the FIFO between songs (when possible), using very deep buffers, adjusting the buffer depth based on the difference in source clock and DAC clock frequency, and using highly accurate clocks in both the DAC and streamer. 

Using deep and/or variable depth FIFOs also has issues though, particularly if the DAC output needs to be synchronized with another media stream (such as video).

Using an asynchronous data connection, such as USB, allows the DAC to control the timing, which eliminates the overflow/underflow situation, but USB is notorious in the amount of noise that is carried with the signal, particularly if it is generated by a noisy computer or cheap streamer.

An optical connection will eliminate noise carried on the ground, but not on the data signals themselves. The optical signal is still an analog signal and will carry whatever noise was on the electrical signal in the source (streamer or transport) before the signal was converted to optical. This noise will still be present when converted back to an electrical signal in the DAC. That said, eliminating the ground noise is still a significant benefit. 

Some DACs have clock outputs which can be used to control the timing of the source, so that a relatively small FIFO can be used inside the DAC to reclock the data without worry of FIFO over/under flow. But this requires non-standard devices, or an additional digital-to-digital converter that uses an asynchronous source connection (e.g. USB) and a synchronous output that is clocked by the DAC clock. 

Removing noise on high-speed digital signals is far from trivial. It's a lot easier (but still challenging) to prevent (or at least minimize) the noise from being generated in the first place. Any circuitry implemented in the DAC to reduce noise and timing errors has a much easier time when the problems are minimized in the first place.

In my system, I use a Denafrips Gaia DDC which accepts clock inputs from the Terminator Plus DAC. The DDC is fed with USB from the streamer, and then uses a synchronous connection to the DAC (I like I2S best). I started out using a fanless NUC with LPS, then switched to using a Sonore Optical Rendu, and finally to a Sonore Signature Rendu SE. Even with my moderately high-end DAC/DDC, I was able to discern improvements in clarity and soundstage width/depth moving up in streamer performance.

I'm now working on building my own DIY streamer which will use multiple levels of data isolation and reclocking, very high quality SC-cut oscillators, super-capacitor power supplies (allowing off-grid operation), and extensive electrical and mechanical isolation, to provide the cleanest possible signal to my DAC. 

It would be quite straight-forward to measure the noise, rise and fall time, etc. on streamer outputs with the inputs shorted, but this is not particularly valuable since the streamer isn't doing any work under these conditions. I don't believe that there is any "reference" input signal that can be used to compare one streamer to another.

The amount of noise and jitter from a streamer will depend on how clean the input signal is and what the streamer is doing (e.g. what content is being played and how it is decoded). 

So, while some kind of measurements are certainly possible, it's not clear how these would be useful in making comparisons. And correlating these measurements with the way a streamer sounds would be even more difficult. 

 

@mdalton - I agree that it would be possible to measure differences between streamers in a test environment that includes a known source and known DAC. But this isn’t really measuring the streamer - it’s measuring the combined system. This could still be useful, but I’m not sure how relevant the information would be for other sources and other DACs. Still, I’d love to see someone do this kind of testing.

But I think for this to be broadly meaningful, a variety of sources (and source content) and a variety of DACs would need to be used, and then a concerted effort made to correlate the resulting measurements with the way the combination sounds. All possible, of course, but probably not very practical.

@carlsbad2  - I assume you are talking about data errors between the streamer and the DAC.

As other’s have mentioned, the data from the streaming servers (whether across the internet from the likes of Qobuz or from a local server) is transferred to the streamer using the TCP/IP protocol which will fix any data errors. If the connection is so flawed that this is not possible, the music will skip or stop playing. No streamer that I am aware of will attempt to fix network data errors.

It is possible to have data errors internal to the streamer or between the streamer and the DAC since these signals (I2S, AES, SPDIF, Toslink) do not include any error detection (let alone correction). USB does include error detection, but no error correction for Isochronous audio data transmission.

I doubt very much that any decent streamer has data corruption problems within the streamer itself, but I do think it is possible that data errors could occur between the streamer and DAC, particularly if the streamer output connection has high signal noise, if long or poorly shielded cables are used, and/or if there is a lot of EMI/RFI present in the environment where the system is located.

I still believe that the larger difference between streamers is caused by timing issues and electrical noise transmitted to the DAC, but this is speculation on my part.