DCAudioDIY.com

PC based digital playback has been discussed quite a bit on the forum lately, but it occurs to me that a lot of the buzzwords that have been used in those threads may not be clearly understood by everyone here, so I thought I'd put together a little clarification. I'm by no means the group expert on this subject, so if I screw something up, or leave something out, please feel free to chime in. Once we've beaten this to death, I plan to put a few different options for different build levels in threads in the Projects forum...

This is NOT the place to discuss whether PC based playback is better or worse than playing from a CD/DVD/SACD transport straight into a DAC. If you want to open that can of worms, start a thread for that.

For starters, let's define some of the buzzwords we'll need to discuss this. There is often some confusion with the usage of these terms, a big part of this is because a single PC often does more than on thing....

1. Storage. If you're going to use a PC for music playback, you're going to need to have music stored somewhere. This can be on a local hard drive, a NAS, in the cloud, or a streaming service such as Tidal or Qobuz.

2. Server software. This is the piece that allows you to tell the system what music on the storage to play, and, if you have more than one destination, where to play it. This is also where the metadata (artist, track, album, artwork etc.) is collected and presented when you browse or something to play.

3. Renderer. This is where any de-compression, resampling, and format conversion (DSD->PCM for example) is done. This is generally the most CPU intensive part of the process.

4. Bridge. This is where the decompressed/resampled/converted audio gets from inside the PC(s) to an outside link that the DAC can take as an input.

5. Control point. You've got to control it all from somewhere. Many of the options can be controlled directly on the machine that's running the server software, but some can't. Also, having a monitor/keyboard/mouse hooked up to a PC in the listening room can be problematic. Most of the solutions can be remote controlled via either an IOS/Andriod app, or through a web interface.

5. DAC. This one is fairly obvious

There are some commercial offerings where all five of the pieces are in a single box. I'm not going to discuss that option here, I'm going to assume we'll always be using a separate DAC, or a DAC that has built-in Bridge or Renderer/Bridge. So, from simplest to most complex, here are a few ways to put this together....

A. A single PC that does 1-4 (or 5) above. This is an easy solution to start with, and there are quite a few options. The PC can be running MacOS, Windows or Linux, with several options for software, such as Jriver, HQPlayer, Audirvana, daphile, ap-linux, roon. If you don't start with the very cheapest PC you can find, if/when you move to one of the more complicated solutions that follow, you should be able to re-use the PC as you move on. This is the only solution where having the PC on WiFi rather than Ethernet is acceptable, and then only if you're not streaming from the Internet.

A.5 Same as A, except the you've moved any local storage to a NAS. Having local storage on a NAS is recommended for all the following options.

B. Splitting the functions in 1-4 into multiple PCs. There are, of course, a bunch of different ways to make the split. Many consumer NAS products can have a server app installed on the NAS, but I question whether or not most dedicated NAS products have enough processing power to make effective renderers. In my system at this point, I'm running a separate NAS (FreeNAS) and two PCs, one functioning as a server/renderer, and the second one as a bridge. The engineer in me (for those who don't know, I do have a BS in computer engineering) says that's a better split than having a server only PC and a renderer/bridge PC, especially since the server PC can be outside the listening room where a small amount of fan noise is more likely to be acceptable. If your DAC is network connected, it can serve the role of the bridge PC. Network connected DACs generally CAN perform the renderer functions as well, but that's probably better performed on a more powerful PC. If you send your DAC stuff that's already been rendered, and is always in a format the DAC can handle natively, it won't have to do any rendering.

C. This is where we start getting into the esoteric, and are rapidly reaching the point of diminishing returns. Basically we're starting with B above, but building the PCs with hardware (Ethernet cards, USB cards, linear power supplies etc.) that's been specifically designed to optimize audio playback performance. The sky's the limit here, but I'll let some of the others fill in the details here as I haven't gotten this far yet

Roscoe

_________________
I can explain it to you, but I can’t understand it for you.

_________________
Walt

It seems to me that any processing done to a digital audio signal while still in the PC, or anywhere before it hits a DAC and is converted to analog, is signal processing, not rendering. At least based on my understanding signal processing and the term rendering. It's the point where digital becomes analog that the signal is rendered, as I said, based on my understanding of the term.

_________________
I have too much stuff - https://www.pleasebuymystuff.com

While I think that may square more with the dictionary definition of rendering, I think in the PC based digital audio playback arena it is more commonly used to describe the point where the digital data is rendered into it's final digital form.... Using your definition, rendering is only done in DACs, which are out of the PC audio stream, which means there's no real point to the term renderer when talking about PC audio. Of course, I could be wrong, and I haven't been able to find a site online that actually defines these terms..

Roscoe

_________________
I can explain it to you, but I can’t understand it for you.

Roscoe,

That is an excellent description of the architecture of a streaming digital playback system, and for what it is worth, is pretty consistent with my understanding. Also agree with your definition of a renderer, though I think a bridge also serves some of that low level functionality of converting from ethernet-based TCP or UDP data packets and re-assembling and decompressing (if needed) to a clocked digital bitstream via a USB, SPDIF, AES, I2S, etc. interface to feed the input of a DAC at a specified bitrate and width. Since I am most familiar with Linux, you are relying on ALSA (Linux) on the bridge as the layer that performs this function (basically a driver for the audio interface, which is capable of performing DSP at this point as well).

David

USB is not clocked at a specific bit rate in any way related to audio.

_________________
I have too much stuff - https://www.pleasebuymystuff.com

Consider Kodi as a music server -

https://kodi.tv/

I use it for both audio and video. Currently for my htpc's I have all Ryzen cpu's and am running Ubuntu 20.04. and a OpenDRC-DA8 (coaxial spdif input) for a DAC dsp crossover. Eventually I will use an ASUS Xonar Essence STX II 7.1 with appropriate software for the dsp crossover dac.

Kudos Roscoe!

Thank you for this. Many of the digital discussions go right over my head since the authors rarely post the meaning of acronyms prior to using them, and because of my lack of familiarity with a particular product (i.e. Roon). While I'm familiar with the basics, using much of the described gear and software as listed in B. and C., I'm still a bit confused by many aspects of digital playback.

Thank you for starting a thread where, hopefully, questions on a basic level can be answered with a minimal level of derision, condescension and outright insult. I've had questions before, but have been loathe to ask them for dread of the replies.

Stuart

Thanks Roscoe, I know I throw what is probably the wrong terminology around.


When I started out, I had music stored on my NAS along with a "Server" program designed for the Linux OS on the NAS. I called the NAS my "Server". It was controlled by a different company's software from an app via the Upnp protocol.



Music was sent to what I called the "Renderer" or Endpoint, which was a Ethernet to S/PDIF converter which fed the dac.

Now, running Roon I would still call the Endpoint (Ethernet to usb, or I²S, or S/PDIF converter) the Renderer, but would now call the NUC running the Roon Server software and controller software the Server/Bridge as it's doing those functions. Now the NAS is just storage.

Don't know if any of this is right or really matters?

Jim,

The endpoint=bridge if running Roon on another computer. The reason it is called a bridge is that it "bridges" via ethernet the output from the computer running Roon to another ethernet device that has the interface with the DAC. This is a pretty "dumb" device, which is why a low end computer (Atom based) can work pretty well. If the computer running Roon is connected to the DAC directly, there is no bridge, and the Roon computer is both server and endpoint (single server). Storage on Roon is either local (internal or USB), or via CIFS from a NAS, so is actually filesystem based, and the NAS is not involved in the audio chain (just doing what it is designed to do...network storage).

What you had before Roon was using the NAS running a OpenHome/DLNA media server, that serves requests via UPnP and hands it off to MPD running on the endpoint via UPmpdcli.

David