why expensive streamers

@mikhailark right I am not saying there is no room for poor processing, flawed transmission. I just don't get the $1,000 vs $20,000 streamer argument. 

The only reason I went with a streamer was to use i2s, I used ethernet prior to using i2s. All the streamer does is to accept data from another server using ethernet, then output using i2s to my dac.

grislybutter

I just don't get the $1,000 vs $20,000 streamer argument. 

Have you tried listening for yourself, perhaps at a dealer who's willing to demo?

I’m not sure the price matters so much as a separate steamer matters and seperates tend to be higher end than integrated.  But as to why a separate streamer:

 

1.  Tech constantly changes. So it’s a generally better long term proposition to get distinct components, so you can just replace the parts that get outdated.  Or break.

2.  As far as why a nice streamer sounds better than an integrated:  

a  isolation from the noise on the network

b  isolation from the noise of the streamer itself

c.  It’s a dedicated component that does one thing well, with less compromise than in an integrated component 

d.  A quality streamer will:  check data, isolate and organize, and present the data in the best, most digestible, form for the DAC, allowing the DAC to do what it is supposed to do without it having to use resources making corrections or removing junk.

 

FWIW I use a Lumin U1X, which is not a cheapo streamer but hardly a $20k.  You can buy them used for $3-5k all day long.  I think they are about $10k new.

 

@mikhailark I have ripped my CD collection to uncompressed FLAC using dB Poweramp. I have it on an external drive hooked to my ASUS PC - the same one I use for streaming. I have listened dozens of times with different songs to see if I can hear a difference between the CD played through a Jay's Audio CD3 MK III vs. a Qobuz stream of the same file vs. my ripped FLAC. The process I use is to make sure the volume is equalized between sources and then play an entire song from the two sources I'm comparing at the time. I even take notes of things I've noticed and their place in the track so that I can listen for that event in the other source. FWIW I'm running through a Berkeley Audio Alpha Reference II MQA DAC. The streamed files are run through an Alpha USB before the DAC.

So far, the sound of the CD, the streamed file, and the FLAC have sounded identical. One of my main points is that people are spending thousands of dollars on fancy streamers because a PC supposedly adds noise and distortion to the signal. I admit I haven't compared  a 5 figure streamer to my PC but if my PC sounds as good as a CD played through a state-of-the-art transport then I think that's probably about as good as it gets. I don't think I've ever read a review that says that a high end streamer sounds way better than a CD or a ripped FLAC.

If your point is that we should be using a ripped FLAC as the control for comparison (I suggest using zero compression) than that is fine. My point is that comparing streamers to one another by disconnecting one and hooking up another without any means to compare them against a control is inviting expectation bias to influence what we hear. Without any means of comparison to a standard, I submit that the more expensive streamer will always sound better - along with the ultra expensive internet switch and the thousand dollar USB cable.

@cleeds   every time I go to a nearby dealer, they point to the "No Loitering" sign and lock the door.

grislybutter

... every time I go to a nearby dealer, they point to the "No Loitering" sign and lock the door ...

You must have treated him very badly. I can only hope you learned from the experience.

If we focus purely on the 1's and 0's arriving at the DAC in the correct, unmolested sequence then we can relax as all streamers will sound the same; all we then need to do is pick the streamer with an app/user interface which we like most.

Unfortunately, streamers also incorporate clocks so the sound quality they help produce may be affected by there being more or less jitter.

Unfortunately, streamers vary in the amount of noise they generate or pick up and this noise reaching the analog(ue) parts of the DAC will also affect sound quality.

If noise wasn't a thing and jitter wasn't a thing, all streamers would sound the same.  Unless I've missed something, and I'm sure someone will be along shortly to politely enlighten me if so...

@cleeds hope dies last :)

@nigeltheflash I am sorry I am slow and thick. This is too abstract for me. And let's just focus on the "noise". 

Noise from where? The machine noise? Noise in the signal?

The signal comes from a server. Travels through a lot a steps, finally arrives to a streamer. Does the streamer add noise? Or it knows how to remove the noise?

And a good streamer sends "clear" signal to the DAC?

Sorry, feel free to ignore me. Just trying to understand. 

 

Theorizing why a streamer should or should net have a major effect on the sound quality is like theorizing on any other aspect… it may not make sense logically… until your jaw drops upon hearing a good one. I have heard at least a dozen in controlled circumstances and the difference is like between a VW bug and Porsche… night and day difference in performance. 

@grislybutter Slow and thick? I doubt it!

RFI noise accompanying but not part of the digital signal. It can arise anywhere along the playback chain and is why many people choose to incorporate an optical connection or a switch close to their streamer.

You say the signal comes from a server; sometimes it does, and sometimes it comes from a router. Both require a streamer to unpack the packets into a stream of 1s and 0s.

Some streamers simply pass the noise on. Some might add their own (do they have noisy circuitry? does this include LEDs?). Some might incorporate the sort of galvanic isolation we see in switches so actually mitigate the noise they receive and pass only some or none of it on.

So yes, a good streamer sends on to the DAC as close to the purely digital signal as it can. I’m not sure "clear" is the right word, as this might suggest that some streamers send more accurate 1s and 0s than others and it would be a truly terrible streamer which shuffled these!

The effectiveness of how various streamers handle/address noise is therefore a key factor in their performance.

The second thing a streamer does it to add a time signal to the bitstream it creates from the data packets/frames it receives, but this is a separate point.

Does this help?

Nigel

yes it sure does, thanks @nigeltheflash 

I hear a lot about timing, slow and fast, so I have to learn about the clocking part. I would have thought when analog is converted to digital and it becomes a stream, timing is encoded in the stream, the 0s and 1s. There is no layers of data, such as content and "pace" or whatever timing means, it's all one linear series. The DAC has to figure out how to unpack it.

@nigeltheflash

If noise wasn’t a thing and jitter wasn’t a thing, all streamers would sound the same. Unless I’ve missed something, and I’m sure someone will be along shortly to politely enlighten me if so...

As you wish . . .

@blisshifi eloquently summarized the analog electrical aspects of 1’s & 0’s in this post.

Synergistic Research has understood these aspects for a while - and has created products around it.

- - - -

Pre: streamer - during the ethernet packets/frame stage. My router & access point each have dedicated clocks.

A Synergistics Research digital power cord is delivering electricity to the LPS to my router. This SR cable accepts proprietary SR tuning modules. When different tuning modules are installed, the SQ changes.*

Everything else in the digital chain remains the same.

- - - -

Post: streamer - during the bitstream stage. My streamer & DDC each have clocks.

A Synergistics Research USB cable is delivering data between my streamer and my DDC. This SR cable accepts proprietary SR tuning modules. When different tuning modules are installed, the SQ changes.*

Everything else in the digital chain remains the same.

Also:

A Synergistics Research Galileo digital cable is delivering data between my DDC and my DAC. This SR cable accepts proprietary SR tuning modules. When different tuning modules are installed, the SQ changes.*

Everything else in the digital chain remains the same.

Also

A Synergistics Research digital power cord is delivering electricity to my DDC. This SR cable accepts proprietary SR tuning modules. When different tuning modules are installed, the SQ changes.*

Everything else in the digital chain remains the same.

- - - -

A streamer’s SQ can differ if manufacturers implement different electrical properties within the component chassis. In other words, inside the box. Synergistic did it outside the box. Innovators.

- - - -

* UEF Tuning Modules work outside the signal path to contour the sound of your cables by changing the way your cables resonate. By altering the relationship between signal and ground resonance you take control of the sonic balance of your cables and in the process, the overall sound of your system.

RED Tuning Module’s Sonic Characteristics:

• Warmth
• Liquidity
• Musicality

BLUE Tuning Module’s Sonic Characteristics:

• Refinement
• Detail
• Focus

noise is easy to measure, which is why I find it extraordinary when high $ streamers are advertised as lowering noise without any measurements/data to back it up.  However, there are a few places where some analysis of the differences - or lack thereof - across different streamers - is done more comprehensively.  These include hifinews (paul miller’s measurements sections of streamer reviews), archimago, goldensound, and, yes, ASR.  (For a reaction to the point from @blisshifi, see Amir’s video entitled “Is digital transmission really analog?”)

 

 

 

grislybutter

I would have thought when analog is converted to digital and it becomes a stream, timing is encoded in the stream, the 0s and 1s. There is no layers of data, such as content and "pace" or whatever timing means, it's all one linear series.

Oh no, "streaming" is a misnomer in that sense. It isn't linear at all. The data arrive in packets and they can arrive out of sequence, and perhaps even multiple times if errors are detected.

@cleeds 

I meant stream = the end result, the sum of the packets, glued back together. The serialized data. What I know from writing code for reading data from e.g., text to binary and back. But in short I have no idea. I should read up on it before asking questions. 

In addition to what others have said, there is a difference between streaming and data transfer via a bit perfect FTP.  Banking, nuclear weapons, government records, etc can't tolerate dropped bits.  they can't just guess what it should have been via interpolation.  So they use a checking program and will not terminate the file transfer until it is 100% verified.  That is why in the early days of the internet it took forever to download files and sometimes they would fail because they couldn't get to 100%. 

You don't have the luxury of this for streaming.  thus dropped bits are estimated by the streamer and the music must go on.  Thus we do everything we can to prevent dropped bits.  And it is quite audible.

Jerry

 @cleeds Quite possibly but if ethernet protocols didn’t sort this then the internet wouldn’t work. Error checking and correction are built in. The streamer input side deals with this so the output side doesn’t have to.

@grislybutter Cool, glad to help. The signal coming out of the streamer containing 1s and 0s does incorporate a timing element. Jitter is therefore a “thing” from the streamer onwards in a way it isn’t up to that point.

@steakster I’m really not sure that’s “as I wish”; I’m a listening first guy who then seeks to understand the physics/science which might explain what I’m hearing but the SR stuff is from a different planet. What the heck are “contouring” and “tuning” actually supposed to be doing to a digital signal? Modifying the 1s and 0s which amounts to corrupting the data? Changing the timing? Or modifying the way in which RFI noise accompanying the digital signal is handled? This sounds like leading edge witchcraft…

Many aspects of music perception are not measurable. But when it comes to altering electrical properties in any way, there should be something the designer used to decide how to alter the electrons that is subject to measurements. If claims are made based on electrical engineering, the engineer should be able to describe the electrical changes and why it improves sound quality, even in a theoretical way. I can decide for myself, by listening, whether I like the change but I don't accept that something meaningful is happening without a reasonable scientific explanation. I believe in the mysteries of music perception but not electrical magic. Give me some kind of science.

@8th-note I am with you buddy. A decent streamer (say, $2-3K) is fine, after all, that is what decent custom PC costs - nice box. no fans, screen - it all costs company to make. $20K? No, thanks.

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. 

 

Digital transmission is analog, the interpretation is digital. How can voltage or current be digital, digital does not exist in the physical world.

Everyone keeps talking about noise.  I guess this is natural.  but that isn't the main problem.  The problem is dropped bits.  If a bit is missing, a streamer has to improvise.  guess.  fill it in, often with an interpolation.  So there is no noise generated by that, just an inaccuracy.  I think of it as rounded edges and thinned out middles.

The error correction people keep mentioning is generally not the correct term.  For file transfer, there is data correction available.  It will go back to the source and get the correct data.  For streaming, there is not data correction, there is just "data error handling", perhaps "data error mitigation".

Jerry

 

@jaytor 

respectfully disagree. maybe i’m not following, but not sure your objection is any different for measuring dacs.  regardless, others have done it; for example, you can measure at several different dacs with a control source (e.g., a computer) showing jitter and signal to noise ratios - at the dacs - for both the computer and the streamer, and then do same for other streamers against same control (computer).  that’s just one way, which is how paul miller (hifi news) has done it.  if you look  at his measurements, it shows that dac performance on jitter and noise dominates. that outcome is consistent with what the folks at Benchmark have said - that their dac’s performance is agnostic as to the streamer.  

@invalid technically true, but it is like AM-FM. Both transmit analog but FM is more advanced that AM. Digital is ultimately beams of light in a fiber or modulated currents in a twisted pair or coax cable, or radio waves of a satellite link. but it is also designed to be error-free, otherwise that Word doc you are opening from a server half a globe away would be garbled.

Since when has man ever created something error free or perfect?

Even the gods man has made are full of errors and faults. 
(that's snark, folks)

i’ve met a bunch of folks over the years who think they’re perfect….including my father-in-law, my oldest sister, the list goes on.

@nonoise technology and AI will only make us less perfect. But the sum is.... somewhere still... not great 😎

@grislybutter How does that old saying go?
Something like, "parts is parts." 😄

 

carlsbad2

The error correction people keep mentioning is generally not the correct term. For file transfer, there is data correction available. It will go back to the source and get the correct data. For streaming, there is not data correction, there is just "data error handling", perhaps "data error mitigation".

That is not true. Services such as Qobuz and Tidal use TCP/IP, which is a bit perfect protocol. Data arrive in packets and faulty packets are resent. The streamer assembles the files and sends them to the cache, which then sends the files to the DAC.

@carlsbad2 Seriously, I'd suggest you read up on ethernet. The built in error-checking, retransmission etc will ensure no bits are dropped. The primary concern about ethernet data transmission from an audio perspective should be minimising noise accompanying the perfect digital signal which reaches your streamer.

@invalid It's true that a purely digital doesn't exist as such, it's an electrical waveform. What happens from the streamer output side onwards is subject to different constraints, factors etc from what happens in the ethernet domain ie everything up to and including the input side of the streamer. In this ethernet space, all devices translate the electrical signals into 1s and 0s. If folk talk about the angle of the wave, the timing of the wave etc then they don't understand how ethernet works.

SO while you're technically 100% correct, talking of waves can get people musing on all sorts of stuff about cutoffs and curve sharpness etc which are totally irrelevant in ethernet.

@jaytor Agreed re how much measurements can tell us and how they may or may not correlate with what we hear

@nigeltheflash either you didn't read my first post in this thread or your read it and didn't believe it.  After all, I'm just a rando on the internet.   

The difference you, and others in this thread are missing, is that 99% of all data trasfer in the world is done for business and is indeed bit perfect.  Business, govt, and individuals need their files to be perfect.  You'd hate it if you bank dropped a zero when it downloaded your account data.  

Streaming can't use the error checking protocols that achieve bitperfect file transfer. Thus, dropped bits and the streamer's attempts to deal with it. Otherwise, there would be no market for high end streamers, silver digitlal cables, or anything high-end digital audio.  We could use all the same equipment that you use at work to achieve bitperfect file transfer inclding generic cables in plastic wrappers.

I've spoken to many IT professionals who don't know the dirrerence because they spend their entire career in business where bitperfect is an non-negotiable requirement.  

So I'm not interested in arguing and this is the second time I've explained the difference in this thread.  So I'm done (unless someone shows up who really understands streaming and can add to my understanding.)   I did some googling before I responded here, knowing people will be more likely to believe it if they can google it,  and google doesn't get any answers.  Google explains bitperfect well but discusses streaming in general terms.  

I do acknowledge that I could be wrong.  I'm no a streaming expert.  I'm a physicist who had to dig really deeply to understand this and of course my sources could have been wrong.  but I'm usually pretty good at sorting the wheat from the chaff.

Hope you system sounds great,

Jerry

“Streaming can’t use the error checking protocols that achieve bitperfect file transfer. Thus, dropped bits and the streamer’s attempts to deal with it. Otherwise, there would be no market for high end streamers, silver digitlal cables, or anything high-end digital audio.”

Jerry, apologies, I do recall your first related post but didn’t realise you were the same author. For a self-professed non-expert on streaming, they’re quite some assertions!

Perhaps you should forget the network tech googling thing and find somewhere where a streamer manufacturer says something about why they can’t use the same error correction techniques/technologies as other ethernet-capable devices. I don’t recall having read anything from Antipodes or Innuos or dCS or similar where they talk about how they’re much cleverer at working out how to fill in the dropped bit “gaps” than their competitors. I suspect you won’t find anything as it’s not a problem they’ll recognise but, hey, what do I know, I’m just another internet rando like you!

Until I see anything from a streamer manufacturer/designer which corroborates your suggested explanation of the differences in sound quality amongst streamers, I’m going to stick with my own assertions that ethernet data transfer IS ethernet data transfer full stop (US period) and that streamers differentiate based on noise and clocking (possibly amongst other factors).

If file transfer is perfect and done until it's right, reassembling the former exactly into the later, and when someone comes up with a teleporter based on this "exacting" tech, who will be the first to volunteer to go into the descrambler chamber knowing they'll come out "bit perfect" in the reassembler chamber just ten feet away?

Any volunteers?

No,I didn't think so. Like that fly in the movie, The Fly, noise is the culprit that gets into the mix, messing with the reassembling. It's what Antipodes cleaned up long ago, as best they could, by writing reams of code to combat it. Competitors could build the hardware side good enough to look as good as what Antipodes did but they just didn't sound as good (from what I remember from reviews in the early days). Antipodes is just one example.

Some listeners just didn't want to spend that extra to get it and that's around the time things got really heated in regards to what's good enough, that meeting the protocols was all that's needed. 

But as has been succinctly pointed out, that's all that's needed for bank transfers, general data, guidance systems, properly sized fonts, etc. Music is so complicated and fragile that simple noise can corrupt the intended results. I think it's wrong to relegate music to the same terms as the aforementioned, for it has deeper connections to us that general data just can't match.

There are levels of  gradations that show this. We can be deeply moved by a photo of a beautiful event or something as simple as some old calligraphy recreated exactingly from some subject we're familiar with. That definitely lies between a bank transfer from our Social Security account and the music we listen to. It's still nowhere near the level of seizing and moving us like music does, and we can tell when we're being deceived when it's on that deep a level of appreciation.

They've got it pretty well sorted with CDPs nowadays. People talk of flavors, see through ability, tone, timber, pacing, dark and light, etc. when comparing them. With streaming, it's a different kettle of fish, if anyone bothered to notice. What they talk about is emotion, soul, and what seems to be lacking in a more corporeal manner. 

I've always found that interesting. 

All the best,
Nonoise

carlsbad2

... Streaming can't use the error checking protocols that achieve bitperfect file transfer. Thus, dropped bits and the streamer's attempts to deal with it ...

That is not true. Services such as Qobuz and Tidal use TCP/IP, which is a bit perfect protocol. Data arrive in packets and faulty packets are resent.

so, to be potentially off topic, from a software point of view, streaming is a method. It has nothing to do with data loss, error handling, the quality of the data, etc. The content (5 seconds of a cat video, pdf file or song) is converted into bytes and sent from one endpoint to another. The client endpoint will receive it and convert it back to "content". In between there is "networking stuff" that I know little about and won’t google it (so that e.g. I still don’t say stuff that would embarrass my offspring who spent 4 years in College to understand the "networking stuff".)

If you want to play 5 frames of the cat video, 5 seconds of a song, you will need to receive the data that comes in a form of a stream. It has the beginning and end, x amount of bytes. The programmer writing the software that handles the data assumes it is 100% the same data  the server sent.

What we also call streaming is the concept that we don’t need to receive the 6th seconds of a song to play the first 5. We just assume that we will have it in time, before the 5th seconds of the song has played. We can add business rules to our playing procedures such as we won’t play the song unless the entire song has completed streaming (in which case, it’s not really streaming but downloading.)

I feel these concepts are easily confused - as shown in this thread. I would go on about lossless and lossy formats and compressions and how Spotify changed business rules to get around receiving all the data that was sent and "just move on and play something" and never wait for the lost pockets - if I had know more than I can google. But I don’t, music streaming is a different animal than streaming data for maps and location data that I work on.

Still, this is a very educational thread despite our different understanding/ misunderstandings of various issues around streaming...

 

 

 

@nonoise 

Streaming is not a new technology.  I for one have been streaming since about 2004 (starting with the original Yamaha Musiccast system).  Moreover, the fundamental job of the streamer, moving a data stream from server to dac, is rather simple.  And sorry to be a skipping record, but even most high $ streamer proponents agree it’s just about jitter and other noise.  So measure it!

Btw, I volunteer for the reassembler chamber…

@mdalton I wasn't talking about losing or dropping packets and the tech used to ensure it all gets there. I was talking about noise creeping into the many places it can from sender to receiver and that it can corrupt what can be heard. The analogy of the CDP should have made that clear, having such short distances being all handled internally. Apologies if I wasn't clear on that.

On another note, please check for those errant flies before volunteering.

All the best,
Nonoise

 

@nonoise 

sorry, noise in the digital domain is not mystical, it’s easily measured. now in the analog realm, I sing a very different song.  Measurements are very limiting there.  

@nonoise 

noise creeping into the many places it can from sender to receiver 

what/who do you mean by sender and receiver?

@grislybutter What I meant was from the source (Spotify, Quoboz, Tidal, Apple, etc.) to the endpoint: you and your system. Those here who have/use local files on their own storage they stream from have commented on how much better it sounds compared to some online sources, going even further to say it sounds even better on their CDPs but it's getting really close to practically indistinguishable nowadays. 

All the best,
Nonoise

Those here who have/use local files on their own storage they stream from have commented on how much better it sounds compared to some online sources

that's because of the business rules. Playing via streaming (putting packages together as they come in vs having it all at the door) is different because of their algorithms for how to cut corners - to deal with missing/delayed packets. It's not because noise creeps in along the way. That's my understanding

grislybutter

Playing via streaming (putting packages together as they come in vs having it all at the door) is different because of their algorithms for how to cut corners - to deal with missing/delayed packets ..

What algorithms do you imagine exist? Services such as Qobuz and Tidal use TCP/IP protocol to send bit perfect copies of files provided to them by the record companies. It's as simple as that.

I don’t imagine anything. Here is the spotify algorithm. I don’t know about every streaming services algorithm.

If it's bit perfect, and no cutting corners, then great, I am happy to be wrong.