Skip to content

Solution Architecture

We are often asked about what the best connection is to use between a music server and a DAC – Ethernet, USB, S/PDIF, AES3 or I2S. But this is not a question about different connection types. It is about different solution architectures. This is because Ethernet, USB and the synchronous interfaces (S/PDIF, AES3 and I2S) occur at quite different stages of a computer audio solution, and so are not direct alternatives.

The image below illustrates how delivering the ultimate computer audio solution requires a multi-stage approach. The purpose of the stages is to take a stream that has poor clock timing accuracy, and progressively improve the timing before the data enters the DAC stage, where the digital signal is converted into an analog signal. You can certainly make the music play with a simple one or two stage process, but to get a high-end audio result, more stages are necessary.

Multi-Stage Computer Audio Solution

Remote Server – An internet streaming service like TIDAL or QOBUZ performs a Server role, but its delivery is compromised by the chaotic nature of internet delivery, and so sound quality is enhanced by re-serving the stream with a powerful local server. The remote server sends the music file to the local server using a streaming protocol, which means that the file packets are sent in the sequence that they are to be played, but they are not sent with the precise timing that a DAC chip requires.

Local Server – A Local Server organises your music sources, whether they be internet streams or locally stored files, and this role is performed using server apps like Roon Server, Squeeze Server, HQPlayer Server, Minimserver, PLEX, etc. The local server takes music files into its RAM and uses a streaming protocol to send files in the correct sequence to the player. These server apps offer the user a lot of features, but by their nature require a powerful server to deliver these features at the same time as creating a good quality stream. A local server has a lot of functions to perform, and more power means it is more able to perform all of its functions, plus send the file packets to the player with some degree of timing accuracy.

Player – The Player runs Player apps that are compatible with your chosen Server app, such as Roon Player, Squeeze Player, MPD, HQPlayer NAA, etc. The Player performs a similar role as the local server in that it writes the music file into RAM and then clocks it out of RAM. But without the server duties the device can be lower-power, and therefore lower-noise. Additionally the player app turns the file into a digital audio signal. Whereas a file has no timing data, a digital audio file now includes timing data. The better the quality of the stream from the server (in terms of timing and low noise), the easier it is for the player to do its job and output a quality signal. Typically the transport to the next stage is still asynchronous, using USB, but in this case the receiver is adaptive, so the timing accuracy is more important than in the server stream.

Re-Clocker – The Re-clocker provides the last step in the computer audio chain, converting the asynchronous signals in the previous steps to the synchronous signal that the DAC chip requires. The sound quality of what is output by this stage is very much affected by the quality of the incoming signal from the player. Isolation from noise generated by the previous stages is also important, and this is more effective when the previous stages are designed to add very little noise to the system and to the signal. Noise can enter not only on the signal but also on earth paths and power supply paths, or from nearby components, so galvanic isolation has benefits. At this stage the quality of the clock is crucial, because for the first time in the process, the output signal is synchronous.

As you go from left to right in the diagram, the timing gets better, and the transmission method goes from asynchronous (eg. using a streaming protocol over a packet-switched network, or block-mode transfer from a local disk, to RAM), then through a less asynchronous USB connection (where the input is adaptive), and finally to an entirely synchronous feed to the DAC chip. Asynchronous transmission between the stages is necessary early on because with less than perfect timing accuracy the receiver needs some level of control of the arrival of data to avoid its memory buffer filling up or emptying out, to allow the buffer and re-clock stages to perform their roles without drop-outs or skips.

Therefore, on the left of the diagram, the clock used is less important than on the right where it is crucial.

On the left the greater priority is powerful processors, but higher power comes with higher levels of electronic noise. As we move to the right, we need progressively less powerful processors. Each stage requires a different, but equally smart design: to provide the right level of uncluttered processor power to improve the signal timing; to reject as much of the noise on the incoming signal as possible; and to add as little of its own noise as possible, while maintaining very high bandwidth signal transmission.

It is the complete end to end process that matters and so you cannot skip, or short-change, any individual stage, without compromising the total result. It is true that DACs with ethernet inputs can take chaotic streams and play music, but a high-end audio result requires a more complete solution.

In the early years of computer audio, people used basic computers for the earlier stages. This placed a heavy burden on DACs to do the rest, so DACs sprouted Asynchronous Ethernet and USB inputs. In the absence of quality music servers, DACs had to include more of the computer functions in order to improve signal timing before the DAC chip.

A DAC With Ethernet Input Includes Player & Re-Clocked Async to Sync Processing
A DAC With USB Input Includes Re-Clocked Async to Sync Processing

Over the years audiophile music servers emerged, they got progressively better at the job, and audiophiles began to realise that using a standard computer did not get the job done nearly as well as using a good music server to feed the DAC, regardless of the quality of the DAC.

For even better sound, The Antipodes Oladra and K50 models take the additional step of performing the asynchronous-to-synchronous Re-clock stage before the DAC. A Re-clock stage performed outside the DAC can employ much higher processing power. Placing a high-power Re-clock stage inside the DAC creates unwanted interference. This means that DAC design has to trade off processor power to keep noise very low. By placing the Re-clock stage in the music server we can give it all the power and parts quality required to do the job to the highest possible level of accuracy. Your DAC will also complete a synchronous to synchronous Re-clock stage before the DAC chip, but feeding this with a high-precision signal from an Oladra or K50 will dramatically improve the sound quality achieved.

The Oladra and K50 Perform The Local Server, Player & Re-clock Async to Sync Processing

Some of the top DAC manufacturers clearly agree with us, producing multi-box solutions where the first Re-clock stage and sometimes also the Player stage are in a separate case or cases from the DAC stage. In this way, they can apply high processing power and avoid generating noise interference inside the DAC.

Of the synchronous connections, I2S is better than AES3, and AES3 is better than S/PDIF. But the differences are not so large that S/PDIF, using a high-quality S/PDIF cable, cannot out-perform I2S using a basic cable. But I2S has the advantage of being able to handle much higher bit-rate transmission, and a clear channel for transmitting the clock data.

An ideal cost-no-object design would place each stage in its own separate case. When price is a consideration, this ideal can be traded-off by placing some stages together in the same case. Which ones you put together determines the type of connection you use between the music server and the DAC.

For example, with an Oladra or K50, we recommend you use a synchronous connection rather than USB or Ethernet. This is mainly because you get the added benefit of the high processing power Re-clock stage in the Oladra and K50. But you also avoid using the inherently noisy Ethernet and USB stages inside your DAC.

In the same way, a DAC manufacturer perceiving that most of its customers are still using basic computers as their servers, will tell their customers that the DAC’s Ethernet connection is best.

Which one of us is right depends entirely on the music server and DAC that you use.

We hope this explains that your choice of connection between your music server and DAC is not so much about differences between the connection types, but is a decision you should consider about the ideal composition and architecture of your computer audio solution.

Therefore:

  • If you want to keep the high processing power needed by Server, Player and Re-clock stages away from your DAC, to avoid noise interference with the DAC and analog stages, then connect your music server to your DAC with a synchronous connection, S/PDIF, AES3 or I2S.
  • If you want to only keep the Server and Player stages away from your DAC environment, and have the DAC perform the Re-clock and DAC stages, then connect your music server to your DAC with a USB cable.
  • If you want the Music Server to only do the Server stage, and leave the rest to your DAC, then connect your Music Server to your DAC with an Ethernet cable.

If you have an Oladra or K50, then the first option above will give you the best sound quality. The other two options mean you can use a simpler music server product, and this may make sense depending on the design and capabilities of your DAC. There is only a handful of two-box DACs that can perform the Player and/or Re-clock stages with the power and isolation required to compete with the Oladra and K50.