Point of higher priced streamer?

1. TCP/UDP and network protocols are only tangentially relevant to this discussion. At the end of the day, the one thing I think that 99% of us will agree on is that a streamer or network endpoint (roon or hqp or direct tidal/quboz) will deliver exactly the same bit-perfect digital audio from it’s *output*. How the data got from source/cloud/drives/whatever via streamer to the output is somewhat moot. All streamers are going to deliver bit-perfect digital audio output.

2. That said, while the *content* of the data is the same, the timing of the delivery of the content may differ for various reasons, something that manifests as "jitter" and could have subtle audible results. Could be due to network issues (wifi or ethernet), or processing/cpu issues on either sending source or receiving side. As @ironlung described above, this is dealt with in various ways between a streamer/network endpoint and a DAC, via combination of clock synchronization and buffering. Better streamers/endpoints will output with less jitter and thus make it easier for a DAC to reconstruct the timing with the most precision possible. Similarly, better DACs will be able overcome inbound jitter more easily than others. Things like asynchronous USB audio were also formalized in order to minimize these issues. At this point in it’s evolution, it’s questionable if jitter is really ever an issue, particularly to the point where it affects the audible end-result. Some still think it is, some don’t. As long as the protocols, devices, and network in use are of sufficient quality it should probably be fine.

3a. The remaining unknown is electro-magnetic noise and interference that might get ’passed along’ from a streamer/endpoint to the the DAC along the cable. In theory, this noise might affect the output of the DAC process with audible consequences. Indeed, this seems to be often realized when people connect DAC’s directly to PC’s/laptops. The PC’s have high-noise switching power supplies and other processes running that cause issues. This issue has been exacerbated by the fact that USB Audio, unlike SPDIF/etc, allows for a 5V power bus signal. So on most implementations, the USB connection is carrying not only the (bit-perfect) digital audio but also an inherently noisy max of 5V @ 500ma power. This power bus will transmit any excess electrical noise from source to DAC, just like a power cord may. And until recently, most USB receiver cards/implementations inside of DAC’s did not deal with this well or at all. This is why many, when doing A/B comparison, have felt that SPDIF sounded better than USB, all else being equal. More recently, some USB receivers self power and don’t pull power over USB and/or galvanically isolate the input to mitigate the issue. Just like one wants a good low-noise (linear) power supply for their DAC, they should also want a low-noise input. And the better the power supply on the streamer/endpoint the less noise it will transmit in the first place.

3b. Noise can also similarly travel along ethernet cables. So any wired connections carrying upstream/source data/audio to a streamer/endpoint maybe also carry some noise. Ways to mitigate this include using high-quality wifi, but as per above, may induce electro-magnetic interference of it’s own. Or using fibre optic instead of copper ethernet - which effectively carries only 100% data - and isolates any upstream noise.

My personal setup includes a cheap Roon core running on a PC in my basement which is then hardwired (via routers/whatever) to a Sonore OpticalRendu endpoint ($1000) via a fibre optic media converter. The OpticalRendu is powered by a low-noise LPS and has low-noise data input over fibre, buffers source data and clocks to provide clean low-jitter output. I then use USB to my DAC which importantly has a USB receiver that is *not* bus powered. While the noise issues may be overstated I sleep well knowing that I removed any potential gremlins and have not spent too much $$$ in doing so.

IMO, the ’streamer’ part of a digital audio chain has very basic needs and can be done on commodity hardware it if’s properly isolated from the DAC/endpoint. $4000+ for a entry-level Lumin streamer with a noisy switching power supply??? $10,000 with mainly off-the-shelf PC parts wrapped in a nice chassis with a 3 line UI on the front? Unless you really really have to have a fancy faceplate with the song name, bitrate showing on your rack ...

[for what it’s worth, I have spent the last 15 years designing/coding low-level protocols over both TCP and UDP for real-time financial data]

Streamer does one thing, instruct DAC how to create the audio.

@pc997 Yes, and if you bothered to read through my technical explanation about how different streamers can and do provide DACs with varying "instructions" dependent on multiple factors, you'd be able to comprehend how the streamer itself is just as important as the DAC.

But then I see why you can't hear the difference - your amplifier is applying a filtered buffer in it's gain stage from the upstream components. Your system sounds like your amplifier designer intended it to.

For both, outputting at the same volume I could not hear any difference at all. This even though the external laptop is upsampling to 192K while the direct connection from the 2008 Macbook Pro via its optical audio is not.

That's not surprising, since the receiving interface in your DAC (Toslink which is SPDIF) is treating the incoming data stream the same. Sample rate may have no affect if the internal SRC on the DAC itself overrides what it is receiving from the interface. I'd imagine Schitt go through some great lengths to reduce jitter (word clock timing variations) on the SPDIF/Toslink interface, which is why there's no perceptible difference.

If you compared the Toslink to the USB interface though, my guess is that with the same source (MacBook Pro and Audirvana) you might hear some different results.

When you talk about your understanding, I assume that is based on your understanding of the electronics involved.   There is clearly sonic differences between different streamers (I have both blue sound and lumin).  The question becomes the quality of the overall system and what you are looking for.   The blue sound is perfectly fine where we use it to fire up a loud 4/4 beat in our workout room.  But it would be sub-par in our main listening rooms where critical listening matters 

How the data got from source/cloud/drives/whatever via streamer to the output is somewhat moot. All streamers are going to deliver bit-perfect digital audio output.

With respect to your knowledge of TCP/UDP, I offer the following consideration.

I'd suggest delving a bit more into computational theory and architecture before making this claim. I.E., "the network is the computer" and processes within the computer are analogous to/similar to the OSI layer system used to deploy WANs/LANs.

I've mentioned it before but people seem to think there is no difference between the content of the data from a server.

If this were true then why do companies like Kaleidescape write proprietary file systems to store specific types of data (movies and music) on their servers?

Further, why do we have different file formats for audio in the first place? If it's all just 1's and 0's shouldn't everyone be using the same exact file type, conversation done, over?

To break this down a bit more, consider what I mentioned about Spotify.

If I happened to be an insider beta tester for lossless FLAC streaming (I'm not but I've heard rumors of those who are) from Spotify, the App I would be using would include the necessary code to tell the server that the client API was authorized to receive a FLAC encoded file.

A "normal" Spotify use requesting the same exact file from the same server on the same exact network would receive a 320kbps OGG file because the FLAC files are being transcoded before they leave, for use within the "normal" Spotify API.

In other words, not only can the server API and subsequent processes change the data through encoding/encapsulation/delivery on a particular bus, but the client API and how it is integrated with the server can also affect the data, while still remaining "bit-perfect".

In either case, if I sent the signal to a DAC, the signal is arriving bit-perfect.

Bit-perfect does not preclude that something has not happened to the data further up the chain. It's a misconception amongst digital audio "experts".

I can prove this on a smaller scale. I could set up two identical network streamers (I'll use UPnP) on the same exact network. I can configure a NAS device with multiple LAN ports to operate on two different VLANs with two different IP addresses. I can assign each UPnP network streamer to it's own VLAN.

I can then configure the UPnP/DLNA server software on the NAS with a huge file library of FLAC files, and tell the software to send native FLAC over one LAN while transcoding the FLAC to MP3 or OGG over the second VLAN.

If you tested both UPnP streamers with a DAC that can indicate "bit-perfect" output, they would both show as bit perfect after the streamer performs the necessary decode of the encapsulated file. 

It's this encode/decode process which seems to befuddle audio guys from realizing that yes, the file data can indeed (and sometimes is) be altered by the server/client in many more ways than one.

The rest of your post is otherwise spot on, I'd just encourage people who really want to enjoy their music at a higher level to keep an open mind with respect to some of this stuff and realize that yea, better hardware and software can provide better results in the right circumstances.