Point of higher priced streamer?

Hey Guys and Gal(s):  Maybe some streamers sound better on some systems for a very simple reason:  The system is better and can reproduce the differences.  An example:  With either my Bryston amp or preamp, or just my Audire Diffet 2 with my Audire amps,  my second generation B&W's 803's with subs do not display any ascertainable differences between my Kenwood KT-917, and an fmtuner.com, marginally higher rated B&K TS 108.  With my Audire Diffet 3 preamp, the bass is a slightly bit tighter.  With the, Audire Legato inserted, everything sounds less crisp, but still a bit better than the Bryston preamp, which is even more cajone deficient down low than the Legato.  Put these various streamers into the combos above, and some differences will appear with the Diffet 3 preamps and Audire amps; differences that will not appear with the other quite good equipment, for its era.  New era better?  I should hope so, but most is far from it,  even well touted stuff.  I was given excellent Classe amps and preamps, and did not keep them.

Oh definitely a wall. It was discussed many moons ago how and why a streamer can improve playback. And as I said, any discussion is theory, the proof in the pudding is experience and experimenting. As in good old listening.

And the others told you already: it is NOT about “the packets”. But again, the Wall issue, so there is that.

Unfortunately I don’t see your equipment under the Systems here in Audiogon. What is your DAC?

Okay, I'll take another stab at helping some of the folks around here comprehend what is going on under the hood with digital audio.

First off, the guys who are in the camp of "no perceivable difference" when it comes to streaming seem to have huge gaps in their thought process.

And I've run many people over the years who work for various manufacturers and think along the same lines. They are engineers. I've even personally witnessed the CEO of a  very well known high-end audio music server company tell an individual who had no interest in audio, he didn't understand why people spent so much money on his reference product. 

As a side note, when it comes to digital audio on the software side (software engineers), I know of many who work for these audio streaming companies who have very little experience with high performance audio systems in real-world situations. Depending on the brand, they may not even be involved in listening to anything as a part of their process, and leave that up to the guys further down (or is it up?) the chain. I've sat in a room full of DTS engineers for example, and none of these guys had any experience with reference level systems in domestic, real world environments. I've had audio recording engineers who produce award winning music tell me point blank they've never run a live event and wouldn't feel comfortable doing so. My point is, there are many people who work within the industry (let alone consume within it) simply parroting information they've gathered from colleagues and such who haven't actually spent any real time with audio systems to be able to make the claims they do.

Anyway, back to the gaps, and the topic at hand -

A network streamer is a computer. This computer can be a typical PC/Mac or what have you, an integrated chipset as a part of a DAC board, a Raspberry Pi, etc.

The computer requires an operating system to run. This can be a software suite like Mac OS or Windows, or a headless OS like Linux. It could be a customized Linux software designed specifically for music (such as Roon), or an off the shelf distribution like Ubuntu or Archlinux.

Next you have the audio playback software. If it's a PC or Mac, it's any number of programs one can download and install. If it's Roon, it's Roon. If it's MPD on a headless Linux box, it's MPD. if it's Sonos, it's whatever Sonos is using for this process (likely MPD or something similar). If it's Pro Tools, it's Pro Tools.

At this stage any number of processes can be applied such as bypassing the kernel audio in the case of a traditional OS. This is also where the metadata information is gathered into usable information by the application. 

Also the digital audio information can be treated in a number of different ways by the player software before sent out as packet data over whatever interface one is using. Up-sampling/oversampling, DEQ, compression, etc.

This is where things get tricky. At this point the player software needs to send the audio data downstream to the DAC. It needs to do this over an interface. The interface can be serial packet data sent over USB, Firewire, Ethernet, or other proprietary serial links. The interface can also be SPDIF stream data, or I2S linked data.

How the player software delivers the data to the interface, and what interface is being used by the streamer to the DAC, can dramatically affect performance. Please consider the following. 

In order to link the data stream to the DAC the DAC needs to properly determine the clock signal (word length and sampling rate) embedded in the data. The DAC can clock the data to itself using an Asynchronous transfer method in which the DAC clock is the master clock (this is how most USB and Firewire interfaces function). If using SPDIF, the clock in the DAC needs to use a phase-locked-loop to synchronize the frequencies of the sending clock with itself. If the DAC is well designed for use with SPDIF it will typically have independent PLL circuits for each sampling rate. If using I2S, a master clock is shared between the DAC and sender. 

In the case of USB Asynchronous transfer there is potential for data loss within the transmission which can result in intersample-overs or just plain dropouts/scratchiness in the signal. I've experienced this with so many different varieties of USB DACs over the years I'm surprised it is still such a popular interface for audio enthusiasts.

Firewire might still be used in studios and was a better link at the time for professionals in most applications but it's mostly irrelevant now so not going to spend time on that much.

In the case of Ethernet transmission on a typical local area network, the streamer can send the real-time audio data out over the network using a number of different methods. As far as I am aware, nearly all of these methods are UDP-based protocols - AES67, Dante, Ravenna, AirPlay, Roon, Songcast, etc. 

Alternatively, if the streamer (computer and player software) is embedded on the device containing the receiving DAC, then the streamer can use TCP/IP to download the file information into a memory buffer where it can be managed better. Essentially, this is what Sonos, BluSound, Marantz, Yamaha, Sony, Linn, Naim, etc. are doing when you are using their native applications to "stream" audio from any number of services, or from your local content library. In the case of real-time internet radio streams, or services like Pandora, the streams are "captured" using UDP protocol from the sending player. This is why so many users of any of the above products I've mentioned may experience dropouts and/or interruptions in the stream.

This brings us to the topic of - where is the streamer (computer/player software) obtaining the file from? The files can come from a network share on the local or wide area network, a local storage attachment (USB, SATA, SD Card, etc.),  or a "captured" stream of a file being played on a remote server somewhere. All of these different solutions have potential for degradation of the audio depending on how the data is sent out/obtained from the server by the client. For example, Spotify's entire library is at the very least lossless (I happened to have had a conversation with someone who manages their storage arrays), but the audio is transcoded to 320kbps OGG before it is received by their API on a client.

This all becomes far more complicated when you introduce other devices on the network all competing for the same protocol traffic. 

Anyone who wishes to still believe, after this thorough analysis, that "all streamers are the same", simply hasn't done their homework.

I think the comment that ROON RAAT is using UDP is rather important here. Back in the day when I was programming Tibco RV messaging we used UDP for broadcast messages in one part of the system and I recall it was unreliable. It did not have to be reliable in that instance because it was just for a debug dashboard and the next broadcast would update accordingly. So packets could be dropped and I was OK with that.

Almost everything people "stream" uses UDP, unless the file is being transferred to an internal memory buffer using TCP/IP or SCTP (100% CRC error-checked).

While I hesitate to rely on them as a reliable source for all things, I find this comment on Wikipedia regarding UDP to be of interest:

"It has no handshaking dialogues, and thus exposes the user's program to any unreliability of the underlying network; there is no guarantee of delivery, ordering, or duplicate protection. If error-correction facilities are needed at the network interface level, an application may use Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose.

UDP is suitable for purposes where error checking and correction are either not necessary or are performed in the application; UDP avoids the overhead of such processing in the protocol stack. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for packets delayed due to retransmission, which may not be an option in a real-time system.[1]"

To be clear my contention isn't that UDP itself somehow affects sound quality. My reason for bringing it into the conversation was based around reliability reasons, in terms of how important the network architecture is.

For example someone wishing to use Roon to run a multiroom distributed audio system on a network where kids are going to be playing online video games and the TV is on in the kitchen streaming cooking shows, should consider paying close attention to how the network is implemented to avoid problems.

An analogy an industry friend has sometimes used is that your network is like a freeway with lanes. UDP would be similar to a lane on the freeway, but designed only for a particular kind of car. What happens when you flood the lane with a bunch of that particular car? Crash!

Another offering, as I have some experience with my high end tube amp mono block system.

Implentation can always be an issue for streamers as for DACs. But there is some differentials as a result, in other cases, things are different.

So I just conducted a test with optical audio for my rig going with a) Amazon Firestick through an LG TV and b) 2008 Macbook Pro.

For both, I'm using the superb Audrivana 3.5 software. Via the Amazon Firestick, I have a Macbook Pro laptop that I use and it sends the music data to the Amazon Firestick no 15 feet away.

I use an optical audio device as a bridge to a Schiit Modi 3 which produces great results into the amps.

I played the same song off "Duets" by Kevin Eubanks with Stanley Jordan (highly recommended).

With  remote, I can change the optical audio from either with the push of a button. While my ears are not 22 year old quality, they are pretty good.

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.

So, while there are certainly differences with various streamers and DACs, this test shows the quality of streaming can be preserved with a good implementation. 

IMHO, many people are losing out by not taking advantage of the very inexpensive Amazon Firestick and using the optical audio output available through most TVs.

You'll be surprised.

Happy listening folks.