Point of higher priced streamer?

Obviously nobody can tell apples from oranges if eaten in a blind test controlled environment 🙄

I wondered how long it would take to see through the apples to oranges comparison. At any rate take the apple 320kb Mp3 and orange FLAC through identical streamers to identical amps and speakers and I wonder how many could tell the apple from the orange without knowing which was which of course. 

@ironlung

A.You are talking about something different - upstream services/clients *intentionally* pulling a different resolution or transcoding/decoding to a different format/resolution/shaping/whatever. Of course the data output from those processes will be different. I think most of us know this. What I was talking about was that any streamer set to a baseline setting of not modifying a file and simply sending that data to its output, is usually referred to as “bit-perfect” output and will have identical 1’s and 0’s with the same source file/stream. Bit-perfect implies that the source data has not had a single bit modified. If you can’t compare two streamers in this same apples-to-apples way then it’s pointless.

2. With all due respect the file format stuff makes no sense. Of course a lossless FLAC and a lossy MP3 file will be different and thus sound different. And different file types exist because they serve different purposes - compression formats like FLAC exist to save space at the expense of encoding/decoding time. Most compression formats allow one to specify the level of compression. Even a zip file can compress the same original file at different levels - the result is that the compressed file will be different. But once uncompressed they will again be identical. Another aspects of different file formats are security and recovery. Regardless I assumed that this was a given to the discussion. I will guarantee you that any given source file that is compressed with any LOSSLESS format like FLAC or ALAC will result in an identical bit-perfect output from 2 streamers if they have no additional settings to modify said file/stream. (A stream and a file basically the same thing to an application reading them btw - they are usually wrapped in buffers and the underlying process deals with pulling the bytes off of disk or off an http stream respectively).

As for proprietary storage formats like Kaleidoscope, they do this to optimize the performance of and add features relevant to their domain. But the same source file will be bit-perfect identical when read off a Kaleidoscope disk or a ZFS disk array or raided windows NTFS or whatever. Unless they are intentionally modifying the data, which includes lossy compression like MP3 or JPEG or MP4.

Well said. Spot on! Good things happen to those who try.

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.

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.

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 

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.

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.

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]

Reading this while listening to my Node 2i streaming internet music (Radio Swiss Jazz) to a recently acquired (Cyber Week) Wyred4Sound mPre made me realize that there is a DAC input in the mPre. So changed the hook up to digital out of the node to the digital in of of the mPre. Think sound is better. Speakers are Madisound BK16 and amps are  Amp Camp monos.

Hey @pc...numbers ... numbers. You literally posted right below a huge explanation of everything. May I humbly suggest you read it. Enjoy your Rotel “DAC”. I have a sweet spot on Rotel. It was my first decent system back in 2003-2004 with RB-1080/ RC-1070 / RCD-1072 combo. We have something in common presently too. My speakers are B&W 803 D3. Merry Christmas 

@Thyname, again, you are not giving me any technical explanation. Just subjective measurements. Streamer does one thing, instruct DAC how to create the audio.
Regardless, Merry Christmas. Enjoy the music.

this is what I have:

Streamer: Hifiberry Digi+ Pro on Raspberry 3B+ running Volumio (currently)

DAC: Rotel RDD-1580

Amp: Mcintosh MC-302

Pre: Mcintosh C53

Speakers: B&W 805 Maserati Edition

NAS: WD mycloud mirror 8Tb

Dave Lalin. How are you doing buddy? Glad to see you posting again. It sounds like you beat Covid-19 and the stroke caused by it. 

Guys we gave a totally different set of experiences with servers and streaming

First our major test system is a a 150k reference system that can easily show differences

First we started with laptops and mac minis then an sotm computer with a linear supply

Tried auralic then heard higher end streamers went with innous zenith rthen upgraded to an innousstatement and each time the higher end servers made the system sound far better same dac same system there are audible differences in these devices

You could hear the diferences even sending the signal over the network to a roon endpoint in another room the server improved the sound even over streaming directlyfrom the endpoint to tidal directly

Dave and troy
Audio intellect nj
Streaming specialists

Thank you @thyname1 and a Merry Christmas to you and yours!
Merry Christmas to all and to all a good night. 

Hey @romanesq : happy listening to you too! Enjoy your music. That’s all that matters. Merry Christmas 

Lots of good feedback and lots of ignorance as always. Net is - With almost everything in audio, differences are directly related to the quality and resolution of your system (including your room and your ears). For example, if your system's total cost is ~$2000 and it's located in your den and, due to WAF challenges you employ no acoustic treatment and you compare a Sonore ultrarendu to a SOTM SMS200 Neo you'd be hard pressed to hear a difference. Take the same streamers and compare them in a 5 figure system well - balanced in an acoustically well treated room and the differences are easily discernable. 

 

Sorry thyname, your point doesn't equate here about the old laptop. The reason (which I urge others to try too) is Audirvana 3.5.

The software Audirvana 3.5 bypasses Apple's Core Audio so the "noise" you're referencing is in fact not present. 

As an aside to demonstrate this, I've also tested a direct connection from the laptop using USB to the Schiit Modi 3. I thought the USB implementation should be as good or better since upsampling would be entertaining but discovered that the optical audio out from both the Amazon Firestick & from the 2008 Macbook Pro is superior.

If one looks at the ratings on Modi 3 and its quality of output, it ranks very high with others but I'm quite interested in the Schiit Unison USB implementation which gets great reviews and is their own design on the Modius balanced DAC.

I'd also add that with my custom mono block amps, I'm getting the best ever sound in a couple of decades of listening with various equipment including a former McCormack DNA 300 Rev. A. I've also had in my system, various tube amps from completely redone McIntosh 225, 240, 275 among many others. 

The current implementation I hear now is easily the most transparent and the best using my custom tube amp mono blocks.

I urge others to consider the easy and cheap investment as they see best and allow their ears (if the setup permits) to decide.

As stated, the unifier here is the Audirvana 3.5 software application in both instances via the Amazon Firestick and the Macbook Plus direct connection.

Audirvana offers a 30 day free offer. On this great day, I would urge others to give that a try in their system too. It's outstanding.

Happy listening to all! 

While I appreciate the enthusiastic and positive tone of your post @romanesq you are comparing an Amazon fire stick with a noisy 12 years old general purpose  computer for streaming audio. Not exactly earth shattering in streaming audio in a (hopefully) high end audio system comprised (only from what I can tell) cheapest Schiit DAC. No schiit there is no difference. But as you say, happy listening!

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. 

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!

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.

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?

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.

@thyname, there is no wall here. If you all so sure about a $5000 streamer (no DAC) being so much better than a $100-$200 setup, why don’t you also tell us how they accomplish this, so we can all be properly educated?
how do you improve your ethernet or wireless connections? Did you install ‘better’ cabling to your house?
how are the high end streamers making digital signals (yes 1s and 0s) so much better than cheaper setups? How do you make those network packets ‘better’? After all, streamers ‘tell’ DACs how to recreate the audio. They transport/stream only the instructions.  High end streamers do not provide ‘better’ instructions than low end streamers.  Instructions are the same!
I spend my money on speakers, passive crossovers, DACs, class-A amplifiers and room improvements. Just don’t want to throw away money unnecessarily.

@djones51 is correct.

The point of getting a dedicated streamer is that some may like the UI of a particular streamer, the instant on feature and the idea that there are no other services getting in the way to slow things down and cause dropouts like on a computer. There is no sound difference. Both receive the same digital file via packets using error correction. No mystery here. Networks have worked this way for decades (even before I started in the field way back when). Here is a very simple video from a Spotify engineer explaining the process.

As I have a dedicated laptop, I don't find any need for a streamer. But realistically, I stream through Alexa 95% of the time. Both methods send wirelessly to my DTS Play-Fi device.

@Sangbro  I'm sure everyone has an opinion, here's mine. Speakers ProAc K6 signatures or if they are to big K3.. or even the New K1 with the matching stands. I've owned many speakers in my 62 years from Apogee to Quads.. I've never found a speaker that's as listenable for hours with no fatigue as ProAc. Plus ProAc really sound best with Tubes or Class A so your Pass will work great.

Streamer: Auralic Aries G1 or G2..

 Dac: Chord Dave or Hugo TT2, maybe add MScaler.. 

Power: Shunyata Everest or Denali , Shunyata Power cords

Cables: Audience AU24-SX , Cardas Clear Beyond

Good luck..FYI I own or have owned everything I've recommended and I've been doing audio as a profession and hobby for 50 years.

initial question of a basic nature segues into $50k budget?   Shaky ground indeed.    

I have a node 2(not the i), it does have a internal dac that works but connecting the node2 to a schiit YGGDRASIL sounds much better, why because the DAC design is better.  In this system the node2 is connected via wire, not through wifi, same IP packets comming from the source, just processed via a different DAC so network connection & delivery has nothing to do with sound difference.

I will also add that I have compaired the node2/YGGDRASIL on my main system that has a Linn Kimax DSM and that sounds significantley better than the YGGDRASIL, why, because the DAC design is better.   DAC design does make a differernce in how a system sounds, of course this assumes that the system is capable of benefiting from the higher quality source.

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.

I will get out my bottle of Double Black Johnnie Walker (found it at Costco) pour some juice and get my head around some of this tech we are talking about. I have nothing to do on Boxing day.

Interesting discussion on this thread. Merry Christmas to all.

Coming from Auralic Aries femto to LDM Server. It's a huge jump. I even tested two different firmware of LDM intensively for a week to compare between the two. Apart from the server itself, the firmware also plays a big chunk of the audio journey.

With my LDM connected to Lampizator Pacific Dac balanced version, the 1st firmware projects an unbelievable depth of stage, ample bass and stunning pinpoint. With newer firmware, it becomes wider and stage, but less depth. With my room character and my listening preference, I really need to go back to the 1st firmware. 

It gives me the best combination from the LDM server to Lampizator Pacific.

You are distorting reality to suit your desired outcome. IF there were packet sized dropouts in audio due to UDP/WiFi then you absolutely would hear clicks and pops and breaks. If that happens you know you have a problem. It’s not a matter of well maybe my WiFi does not sound as good. It works or it does not.

Actually I'm not distorting reality at all, you are doing so by completely failing to address anything I've stated in any comprehensive way. Again. my entire point was, that if @yyzsantabarbara was considering WiFi for a Roon endpoint because of purported SQ differences (not my claim, but is claimed by Auralic owners and other Roon endpoints owners with WiFi connections as indicated by @yyzsantabarbara ) not to mention a supposed "better" connection to the LAN, and he is already using a hardwired connection - he should ignore using WiFi and stick with his hardwired connection precisely to avoid what you describe above - packet loss, audio dropouts, pausing of the stream by the renderer/endpoint, etc., all of which can and does happen to all sorts of different products depending on the application and environment.

My comment comes from years of experience with this stuff and so if you want to continue arguing about minutiae while ignoring the actual content of my post then I'm happy to continue providing you with an education.

Noise in chipsets is just noise in this discussion.

Again, your lack of comprehension with respect to how wireless radio-wave based transmissions occur and the potential to cause unwanted noise or interference in other devices has no basis in reality.

I'm sure there are plenty of people who have experienced the phenomena of mobile phone tower interference causing bursts of audible noise through poorly designed audio equipment. And most of the devices I've experienced this with didn't even have an aerial antenna of any kind.

From a pure data standpoint, again I won't belabor the point that the data arriving at the WiFi chipset itself is somehow changed or affected by the noise, but the noise generated by a WiFi chipset with aerial antenna can certainly affect other devices in the component itself or in other components in the overall system. 

If you had a dropout you would have clicks and pops just like your have stuttering on video streaming or block artifacts from incomplete data. It is very obvious when data is lost.

Thank you for yet again confirming my point. This is precisely my reason for recommending not using WiFi if you can avoid it, and use a hardwired connection if it is available. I have had plenty of experience with end users of a myriad of different wireless streaming technologies and this is exactly what would happen to them and why they would be looking for help.

I laugh at your comment ironlung, because you telegraphed the thinness of your knowledge and position when you said you switched out WiFi for wired due to DROPOUTS. Not a perceived loss of quality but DROPOUTS.

Who is laughing now? I think it's plain that it's your knowledge which is quite thin and your thought process and analysis of my comments needs to be checked.

It's apparent you have very little if any real world experience with the stuff, I simply cannot comprehend why an individual would continue to insist to counter my advice to @yyzsantabarbara with respect to this topic. 

It's like you want him to increase the complexity and undermine the integrity of his current configuration just to prove a point. It's foolish.

Why use a dedicated server? First, you have to ask yourself, why use usb input on the dac?
Once you decide to use a network interface and not usb, then your requirements change. If you use a network interface on the dac, then you can use a OS X or Linux server to run Roon or Audirvana. Never use a server in your audio room. If you decide to use usb, then you should use a music server that has the best usb link, then you have to buy other accessories to help usb sound decent. Years ago I demoed many music servers and found the Auralic Aries the best, over Lumin and Aurender, and their DS Lightning software was in a different league over its competitors. If you want to go cheaper, then find a Aries mini, much better than the bluesound.

Any non digital aspects coming from a streamer to a DAC like distortion or noise would show on the analog out of the DAC if it is bad enough. If not  the DAC is capable of dealing with it. The point is not are there differences but are they audible. Every streamer I tried was with the same DAC and speakers. I didn't do blind tests so they are just my subjective opinion and I present them as such. I heard no or minor difference in SQ . You say you can hear differences in IC pretty clearly unless you used some level of control for bias then your assessment of IC is no better than mine of streamers. I understand  bias can influence our perceptions, our other senses can as well. 

Me too. I hear difference in some stuff, and nothing on some other stuff. I just move on, and decide that’s just not for me. But I am totally aware of the possibility others may hear differences in stuff I don’t. It’s pretty simple, no need to get worked up on that.

Case in point, tried a Mutec Ref10 SE-120 to clock my DAC. In two-three weeks I had it, I struggled big time to hear any difference at all, OK maybe some small stuff, I was not even sure it was for good or bad. So I returned it. Meanwhile, several people I know, including two friends with the same as DAC as me, swear by it. Go figure! It is what it is, probably my ears are not sensitive enough to such changes. So I move on, but, I don’t go and call my friends, and people who own it, suckers, or stupid. 

@thyname  

Hey @three easy payments, good post. Although I am afraid you are talking to the wall

Thanks.  It's hard to get the "bits are bits" camp to contemplate that the SQ differences likely (as in 100%) have nothing to do with the digital portion of the streamer/DAC interaction....yet they continue to drone on about packet data quality etc...even though I totally agree with them on that part.  They refuse to contemplate the non-digital aspects of the component interplay.

@thyname  I agree...there is firm entrenchment.  I'm just sharing what I've experienced through lots of A/B testing over the years.  I can hear a difference in some things and others I can't...or just barely.  In this example with the streamers I can hear it.  Speaker cables and power cords rarely make a difference to my ears (A23 speaker cables are the only ones to make a profound difference in my system likely due to their impedance and interaction with my particular speaker).  I can hear IC differences pretty clearly.  I've tried a SR fuse and it made no difference in my system.  I go in with no bias and no agenda...sometimes I can hear it and other times I can't.

Hey @three easy payments, good post. Although I am afraid you are talking to the wall

There is no point to argue this in the Internets. Two groups firmly entrenched in their bunkers:

1) People who only try cheap stuff, maybe because the rest of their system is just a cheap and crap: there is no difference in streamers. They don’t even need to try. They just know 

2) People who are open minded enough to venture and try different streamers: there is a difference, and an easy one to discern.

One thing I can tell you for sure: it’s extremely hard to convince the first group. They also tend to have the same opinion on everything, DACs, power, cables, you name it. Also, I am OK with whatever pleases them. I just don’t understand their inner urge to go online non-stop and proclaim their “knowledge” with no experience and experimentation whatsoever. I guess this phenomenon is a hobby too 🙄

@pc997  I don't believe the sonic differences have anything to do with the packet delivery...I mean honestly, how could it?  Because you're right....the information is either received or it's not.  My working theory relates to keeping noise off the line.  Those packets don't get delivered magically from the streamer to the DAC, they are delivered via electrical impulses which are interpreted as 1's and and 0's. The electrical signal doesn't just magically disappear once it hits the DAC - it has to go somewhere and that introduces the potential for the residual electrical signal to impact the analog components within your DAC.  Removing as much hash as possible from the electrical impulse may contribute to to better SQ within the DAC....again, nothing to do with packets or data quality.  I realize DAC's are designed to minimize this issue but the reality is some do it better than other.  

The difference could be just ‘perceived’. There can’t be any. Unless someone tell me where the differences are in technical terms. I call this a ‘snake oil’.
Are the comm packets are different? One operating system is better than others (has nothing to do with sound Q)?

When you stream digital data over the network, the sender and receiver agrees in the packets and each packet are checked for completeness (CRC checks, etc), if not incomplete, the the packet is resent. Resending does not impact the flow as the stream is buffered. So there will be no difference between high end streamer vs something like $80 - $100 pi based setup.

@pc997  

You need to compare streamer vs streamer using the same DAC. You will see no difference.

I have done exactly this in my system.  A/B comparison streamed my Node2 and Lumin U1 to the same Lampizator DAC using same inputs.  Massive difference.  I can't explain why....perhaps better power supply, reduced line noise traveling from streamer to DAC?  I don't know...all I know is massive sonic difference. It has nothing to do with the 1's and 0's.

You need to compare streamer vs streamer using the same DAC. You will see no difference. 

I have a Node 2i as well as an expensive Moon 680D DAC with the internal MIND streamer.  I have done a direct compare.  As such, there is a very noticeable difference streaming from the higher end streamer vs streaming from the Bluesound player.

Don’t waste your money. There are no differences in the digital packets. I built few pi3 B+ with hifiberry Digi based streamers. They are doing tremendous job streaming hi-res files from my NAS drive and internet.
Spend your money on the DAC, speakers, and room acoustics. 

i have 2 streamers, a node & a marantz in the same system.
i prefer the marantz. one day i came home & my 15 y/o had the system sorta loud & was using the node, it sounded awesome.
he explained to me that the node wasn’t quite as efficient as the marantz, allowing him to turn up the amp & get more gain.
(he is a big guitar player & loves his guitar amps with tubes). he told me turning up the power on the amp, because the node wasn’t as efficient, allowed him the get more gain from the amp by turning up the power to the amp. and that the human ear lives gain, that’s why it sounded different. he’s 15. maybe, maybe not.
im really working on moving him from Tool to Stevie Ray Vaughan. we all have our battles.
 

Iron lung,

You are distorting reality to suit your desired outcome. IF there were packet sized dropouts in audio due to UDP/WiFi then you absolutely would hear clicks and pops and breaks. If that happens you know you have a problem. It’s not a matter of well maybe my WiFi does not sound as good. It works or it does not.  Noise in chipsets is just noise in this discussion.


Starting with wired the typical home network has near 0 data loss. Effectively 0 wrt audio usage. WRT wireless the streaming protocols build in bufferering and retry. Data loss absolutely occurs but streaming protocols handle that on packet and encapsulated data sets. If you had a dropout you would have clicks and pops just like your have stuttering on video streaming or block artifacts from incomplete data. It is very obvious when data is lost.

I laugh at your comment ironlung, because you telegraphed the thinness of your knowledge and position when you said you switched out WiFi for wired due to DROPOUTS. Not a perceived loss of quality but DROPOUTS.

I am 100% SURE there are sonic differences but like anything else in Hi-Fi, is it worth north of $10K vs south of $0.5K ?  Only you can answer that question of value.. Just like automobiles:  Toyota /Ford SUV's are excellent (@ around $50K)  yet there's the Rolls Royce Cullinan (@ $400K +).  I am sure RR is "better".. If all that matters is it is better without regard for cost, RR should be selling hundreds of thousands of units of the Cullinan.. But they are not.. They are selling around 5000 units.  Bottom line, we have options and it all depends on your preferences and pocket book. 

Data transmission over wifi is perfectly capable. There was nothing in the "explanation " to refute it. If "ones" were not "ones" and "zeroes" not "zeroes" binary digital language wouldn't work. Noone disputes there are differences in streamers the point is are these differences audible after being sent through any modern competently built DAC?