We Need To Talk About Ones And Zeroes


Several well-respected audiophiles in this forum have stated that the sound quality of hi-res streamed audio equals or betters the sound quality of traditional digital sources.

These are folks who have spent decades assembling highly desirable systems and whose listening skills are beyond reproach. I for one tend to respect their opinions.

Tidal is headquartered in NYC, NY from Norwegian origins. Qobuz is headquartered in Paris, France. Both services are hosted on Amazon Web Services (AWS), the cloud infrastructure services giant that commands roughly one third of the world's entire cloud services market.

AWS server farms are any audiophile's nightmare. Tens of thousands of multi-CPU servers and industrial-grade switches crammed in crowded racks, miles of ordinary cabling coursing among tens of thousands of buzzing switched-mode power supplies and noisy cooling fans. Industrial HVAC plants humming 24/7.

This, I think, demonstrates without a doubt that audio files digitally converted to packets of ones and zeroes successfully travel thousands of miles through AWS' digital sewer, only to arrive in our homes completely unscathed and ready to deliver sound quality that, by many prominent audiophiles' account, rivals or exceeds that of $5,000 CD transports. 

This also demonstrates that digital transmission protocols just work flawlessly over noise-saturated industrial-grade lines and equipment chosen for raw performance and cost-effectiveness.

This also puts in perspective the importance of improvements deployed in the home, which is to say in the last ten feet of our streamed music's multi-thousand mile journey.


No worries, I am not about to argue that a $100 streamer has to sound the same as a $30,000 one because "it's all ones and zeroes".

But it would be nice to agree on a shared-understanding baseline, because without it intelligent discourse becomes difficult. The sooner everyone gets on the same page, which is to say that our systems' digital chains process nothing less and nothing more than packets of ones and zeroes, the sooner we can move on to genuinely thought-provoking stuff like, why don't all streamers sound the same? Why do cables make a difference? Wouldn't that be more interesting?

devinplombier

Showing 3 responses by mswale

So much misunderstanding on how networking and computing work. 

AWS/Cloud = some one else computer

All cloud platforms are just server farms that you pay to use. There are several tiers and quality. You can even pay AWS for a specific server that is all yours not shared. 

Networking can be very complex, go through several conversions. Anything sent from the East coast to the West coast is converted to optical, will stay that way till the last couple hops. Sadly it will go through the optical/coax conversion a few times before getting to your house. 

There is network jitter that gets sorted through packet headers. Each packet has a lot of info in it that is not the music 1/0's. Packets come out of time, sequence, in short burst. You do not get a dedicated stream of a song, you get a lot of small burst of data, that the DAC will piece into a song. There is built in error correction, and it's a send/receive/send service. Google TCP/IP packet protocols. 

Never in my engineering life, has any networking "noise" caused any computing issue. Servers all use clean power, and they try to separate the power from the data, but it's not always possible. They always use the provided power cords that go into rack long power strips. 

Think years of analog audio with all the rules has bleed over to digital, some of is the same, but a lot of it is garbage. Packets do not contain any noise, cat cables do not carry noise. Think most of the issues is poor consumer network components, poor component placement, DAC's that introduce noise in the D/A conversion. 

Just a warning, before everyone goes out and purchases enterprise networking gear. DON'T! Not unless you fully understand networking, layering, NAT, porting, etc.. Most of all know CLI commands. These switches are super hard to setup and maintain. They also make a TON of noise, and use a lot of power. 

Some like Cisco will not work unless you purchase a license. That can cost thousands. You will also not be able to get any support on these without a contract. 

Yes, you can get them dirt cheap! Used to have a fiber switch that was almost $30k in my house. Now I just have some Cisco mid-range stuff that is far cheaper/eaiser to live with.

"@sns Still, one can benefit from a 'clean' home network."

This needs to be clearly defined. Are we talking about a clean network, or clean components from an audiophile stance? Sadly, us audio guys try to treat networking like our stereo systems. They are not even close to being the same. 

Have had several people say they have a "clean" network for streaming. Sadly, you do not. You have a network segment, separate from your home network. This does not give you any benefits to steaming. If you want a "clean" network, it takes a ton of work to keep all traffic off the network except for streaming traffic. In networking we call this "air-gaped" You have a network bridge, and firewall, sometimes a dedicated point to point VPN, or packet encapsulations. Then you do some port forwarding, QoS, segmentation, setup the firewall to only allow the ports needed on the streamer, along with closing off all other traffic, etc... 

I can put a packet sniffer on any of these clean networks, and in about 10 sec of sampling tell you all the "noise" on your network. This all means nothing. If you have a 100g network, a few thousand bits of network traffic will have 0 affect on your streaming. 

My point is, having a streaming network is mostly pointless unless your main subnet is full, and/or is having any kind of packet collision issues. 

Now if we are talking about WiFi, that is an entirely different issue. No enterprise gear will have networking and WiFi in the same package. Wifi is also "air-gaped" while being radio, it will not contain anything ridding on the original packet from the source to the destination. 

FWIW, I used to work for the company that supplies the full racks to AWS that AWS runs on. Was an engineer then architect, dealing with server farms over a thousand racks. Being on-call to AWS, and working 80hs a week was not for me.