Servers, deconstructed

Jukeboxes were probably the first music servers to take a form we would recognize: a music-playing device that allows you to choose from several, or many, songs. The first commercial jukebox, Wikipedia says, was introduced in 1927 by the Automatic Musical Instrument Company, which came to be known as AMI.

For most of their history, audio servers were public things, providing entertainment in bars, diners, and pubs. Fast-forward decades to not long after the CD's introduction when CD servers appeared that could hold three, five, or 100 Compact Discs. They quickly became cheap and plasticky, or maybe they were always that way, but anyway people bought them, and that was the music server's first serious inroad into the home. CD servers were clunky nightmares: It was hard to find the tune you wanted to listen to, and if a disc got stuck, you were in trouble. I preferred the superior fidelity (and frankly ease of use) of a single-disc player combined with storage shelves and my own feet and hands.

The prototype modern-day music server, I would argue, was the '90s-era hard disc holding thousands of low-rez MP3 files downloaded from illegal sharing sites. Even today, the multipurpose computer remains an excellent, practical server choice, and it can sound very good if perhaps not optimal. A multipurpose computer is especially attractive when streaming is involved, since it's a cheap and convenient way to get music from streaming services into your DAC. It seems certain that the multipurpose computer is the most common species of music server in current use.

Not too many years ago, something interesting happened: DACs got an Ethernet port. One reason this was important was the advent of high-quality online music streaming. It was a turning point for audio servers: Now, with appropriate protocols and software, it was possible to send music directly to a DAC from anywhere.

This was the moment when the audio server exploded—conceptually, I mean, not physically. Now it no longer mattered where the music was stored; Qobuz files, I recently learned, are hosted at Amazon server farms all over the world. Our own audio files can be uploaded to the cloud and played from there, stored on a network-attached storage (NAS) drive elsewhere on our network or even in another state; all you need is an Ethernet cable on both ends and a big enough pipe.

Another crucial part of an audio server is a computer that runs the software that keeps track of your music and makes it available when you want to listen to it. A big step forward came recently when that software started presenting the music in a single, vast library, not caring where it was stored or whether it was owned or rented.

Thanks to that RJ45 jack—the standard Ethernet connector—the music computer, too, can be located elsewhere, in an office or spare bedroom far from your audio system.

Getting powerful computers and storage (especially spinning discs) out of the music room is important, because they generate noise, both the sonic kind (fans and spinning discs, although SSDs are silent) and the RFI kind. Well-designed servers can mitigate sonic damage electronic noise can do, but only with careful, meticulous design. It's not a total solution, but putting those parts far from your audio system makes sense.

My files—some downloaded, most ripped from CDs—live on a NAS device in the tiny room where my TV is located. Four 4TB hard disc drives are configured as a RAID array so that if a single drive fails, I can replace it without losing data. The NAS backs itself up to the cloud on a regular basis. My audio computer—an Intel NUC running Roon in Roon Optimized Core Kit, the DIY version of Roon's music-optimized Linux—is in the same room as my NAS. Both are connected to my router, which sends another line out that terminates at the rear of my network-enabled DAC 75 feet away.

This is all basic, standard-issue stuff, but it has the excellent consequence (combined with Roon 1.8) that all my files plus all the files on Tidal and Qobuz are available to search, browse, and play as if they were in my library.

There's one thing that the best hi-fi servers do that my distributed setup doesn't do: condition and reclock the digital data. Data sent by Ethernet are delivered in packets, which must then be unpacked and reconstructed and, for audio data, reclocked. Right now, that's all happening inside my network-enabled DAC. But how good a job does it do? Good enough to ensure optimal DAC performance? Would I be better off with a separate device that accepts Ethernet data, conditions and reclocks it, and sends it to my server over an audio interface such as AES/EBU? Would that give me better sound?

I asked some digital-audio experts; the prevailing view is that it depends on the DAC—how well it clocks incoming Ethernet data and how well it deals with jitter.

So that's my exploded audio server, with pieces located all over my house—or, counting the streaming services, all over the world.

I'll end with this: When something explodes, whether a white dwarf star or the concept of hi-fi servers, it tends to recombine eventually in ways not seen before. Next up: streaming (Ethernet) DACs that run Roon or other server software. Bluesound, Grimm, and Mola Mola are ahead of the curve. Expect more to appear in the coming months and years.

COMMENTS
Archimago's picture

"Data sent by Ethernet are delivered in packets, which must then be unpacked and reconstructed and, for audio data, reclocked. Right now, that's all happening inside my network-enabled DAC. But how good a job does it do? Good enough to ensure optimal DAC performance? Would I be better off with a separate device that accepts Ethernet data, conditions and reclocks it, and sends it to my server over an audio interface such as AES/EBU? Would that give me better sound?"

Not sure why the worry about this. Modern streaming devices, even a simple Raspberry Pi streamer would be able to handle the relatively low bitrates for lossless audio-only streaming, even for stereo "hi-res" (or multichannel for that matter).

Unless there is some evidence that there's an issues, you're more likely to see worse performance such as with jitter by introducing the AES/EBU route.

Anton's picture

I love this old LP cartoon...

https://pbs.twimg.com/media/DosOK_4W0AURKA2.jpg

Digital has hit me the same way.

From some recent reviews...

"The s88 supports lossless streaming (wired or wireless) via Roon RAAT, Signalyst (HQPlayer) NAA, and OpenHome/UPnP as well as hard-wired inputs via TosLink, S/PDIF, and USB. In addition to its familiar (and superb) Windows ASIO driver (footnote 2), exaSound provides a MacOS "High-Performance" driver for Mac's Core Audio that supports PCM up to 32/384 and DSD over PCM (DoP) up to DSD256. Alternatively, their proprietary Mac ASIO driver (for the moment, only for Roon) bypasses Core Audio and supports native DSD up to DSD512."

What?

"...a plethora of inputs: one AES/EBU (XLR); four S/PDIF (two coaxial RCA, two TosLink optical); USB Type B; two USB Type A; and Ethernet (RJ45). When the dac8 Stereo is ordered with the streaming module, a supplied Wi-Fi–capable jumper connects one of the USB Type A ports to one of the USB Type B ports. The Raspberry Pi accepts a MicroSD card on which the user loads software for the preferred streaming app."

Uh, good, I guess?

"The processor's D/A circuitry is based on one of the popular ESS Sabre DAC chips, which offers a choice of seven FIR (finite impulse response) reconstruction filters for PCM data. These are cryptically labeled: FRLP (fast rolloff, linear phase); SRLP (slow rolloff, linear phase); FRMP (fast rolloff, minimum phase); SRMP (slow rolloff, minimum phase); AFRLP (apodizing, fast rolloff, linear phase); HFRMP (hybrid, fast rolloff, minimum phase); and BW (brickwall). There is also a choice of low-pass filters for DSD data with cutoff frequencies of 50kHz, 60kHz, and 70kHz."

"A generic ASIO driver allows it to work well in Windows world. I've used it with Roon, JRiver Media Center, Qobuz, and system-default output. It handles PCM up to 32/192 and DSD up to DSD128."

"But in the Métronomes' case, the t|AQWO transport and c|AQWO DAC rightfully belong in the same review because the transport only outputs DSD and the highest resolutions of PCM via HDMI I2S (sometimes called IIS), and the c|AQWO has an I2S (footnote 1) over HDMI input. The t|AQWO also has AES/EBU, S/PDIF (RCA), and TosLink outputs, but they are limited to 24/192 PCM and do not carry DSD. If you want to play the hi-rez layer of an SACD, upsample/resample an SACD (DSD64) up to DSD 256 or PCM 24/384, or upsample/resample a Red Book CD (16/44.1 PCM) to either 24/384 PCM or DSD128, you must use the transport's HDMI output.

"Neither of my reference DACs—the dCS Rossini or the EMM Labs DV2—has an HDMI port. Nor do DACs from CH Precision, T+A, MSB, Esoteric, and, in very different price categories, Mytek and Benchmark."

OK.

So, how many boxes/pieces/wires does it take to play a song in audiophile quality digital sound now?

___

I am an audiophile and, even as a gear lover, the jargon and added boxes are starting to make the vinyl resurgence make sense as a way to escape jargon and incompatible devices.

I read science papers that use less jargon than the average digital review!

There is an old saying: people who love working with computers should not be allowed to design them. I am feeling that way about digital.

(Old guy rant stops as old guy goes to yell at a cloud - not the digital kind.)

Jack L's picture

......... to design them." quoted Anton.

Hi

So likewise, vinyl lovers should not be allowed to design tube amps then ?!

I wonder how many brandname tube amp designers out there are vinyl lovers as well.

Jack L

Anton's picture

It means that people who love complexity should leave the user interface to people who don't love it.

Has nothing to do with someone not being allowed to design more than one thing.

tonykaz's picture

I've traveled the World with a Digital Music Library, enjoying the endless variety of my Shirt Pocket Music system that easily holds every piece of music that I've ever been interested in.

Now, in my Autumn Years, I'm surrounded by Sarasota Florida's Classical Music Station 89.1 FM WSMR presenting endless beauty with Real people being the 'Human-Music-Servers'.

I'd thought that Classical FM was pretty much dead & gone, its not. There are still a handful of maned Classical Radio Stations operating, not including the 50,000 Internet Stations.

So, I recently purchased a Mint Vintage Yamaha Natural Sound, Full Feature, 2 Channel, AM-FM Stereo Receiver RX500U from RE Habitat store ( $60 ) & another pair of ( mint ) Sennheiser RS120 Wireless Headphones. I'm looking for an acceptable pair of Klipsch Horns to bring in an effortless Horn-Concerto, etc. whilst I practice making Garlic Sauces in my Tropical Kitchen.

Human Servers are Wonderful & delightful. I pledge & support.

Nowadays, we all seem to enjoy a great range of options for outstanding music. I only need a couple.

Thanks for reporting on these ever more complex developments: MQA and the Servers, etc. We need your insights.

I love the magic of this recorded musical world

Best Regards,

Tony in Sub-Tropical Florida

ps. Looks like Schiit is discontinuing the SOL record player. It is probably on permenant BO ( it's gonna be a strong Collector's Item someday )

ddps's picture

Jim,

Clocking does not play a role on the Ethernet side of things (i.e., getting things to the streamer, prior to the DAC).

https://en.wikipedia.org/wiki/OSI_model

The clocking that matters to audiophiles only matters within (arguably, after!) layer 7 of the OSI model. Clocking only plays a role once (i.e., after) the data has been streamed to the streamer and is being sent on to the DAC, whether or not the DAC is in the same box as the streamer. In a discrete component world, this would involve the USB connection (or S/PDIF or TOSLINK or coax) between the streamer and the DAC.

But everything between your NAS and the streamer, involving the Ethernet portion of the journey, is easily and reliably dealt with via buffering, where clocking is irrelevant.

As a computer scientist & software engineer, I sometimes sigh at how much further we have to go in the audiophile world for people to appreciate how all of this works!

Jim Austin's picture

ddips,

I thought I made it clear in the essay that the clocking that matters is in the reconstructed datastream sent to the DAC. I'm quite aware that Ethernet packets do not require clocking.

Data sent by Ethernet are delivered in packets, which must then be unpacked and reconstructed and, for audio data, reclocked.

Jim Austin, Editor
Stereophile

ddps's picture

Jim,

You do refer to “how well it clocks incoming Ethernet data.” That is what I was focused on.

I was also reflecting on your statement, “There's one thing that the best hi-fi servers do that my distributed setup doesn't do: condition and reclock the digital data.”

Your setup that you describe handles all of that perfectly. It really does.

Pittiplatsch's picture

Thank you very much for insightful essay, describing your home-made server design. I am (personally) not really convinced that the PC layouts are representing the future of digital streaming, however, I appreciate your remarks quite well. My questions concerns interconnectors on RJ45 standard: Is there evidence (empirical) that simple cables (class 5) work sufficiently in terms of final sound quality or do higher class cables (6 or 7) the job better, may be also in shielded versions?

adamdea's picture

I'm afraid that this superficially unobjectionable musing is, on closer inspection, full of misdirections and suggestiones falsi. There is nothing in Grimm's, Bluesound's or Mola Mola's products which takes anything useful beyond what Sean Adams did with a squeezebox in the late 90s. What curve (other than a marketing one) can they be ahead of?
So then the box running LMS roon or whatever can either be in the same case as the dac or not. The further away it is the greater the risk that some issue will arise between it and the dac array. Fortunately this should not really be an issue either way. But going out of your way to buy a fancy external box to "reclock" doesn't make much sense. But of course we've been here before with external clocks which any fule no are a dumb idea unless you need to synchronise lots of separate boxes.

"I asked some digital-audio experts; the prevailing view is that it depends on the DAC—how well it clocks incoming Ethernet data and how well it deals with jitter."
Well yes that's sort of true, but it's wholly misleading as well: there has been no excuse for decades for a device not to receive incoming data an output its so that it can be received with arbitrary accuracy by a dac; nor for any dac not to be able to receive a usb (or S/PDIF) stream and recover all the data perfectly.
I remember people showing this using DTS files on the squeezebox forum in 2004.
The only engineering problem being solved here is the problem of how to sell expensive stuff to people whose hobby is buying expensive stuff.

X