Network audio clocking: why your streamer's jitter matters more than its app

By Marcus Vale · June 22, 2026 · 9 min read
Devialet Phantom I 103 dB

Somewhere around my fifth year designing digital audio circuits, I stopped arguing about whether jitter was audible and started measuring it instead. The measurements settled it for me. Jitter exists on a spectrum — at one end it's completely inaudible, at the other it produces sidebands you can see on a spectrum analyser and, yes, hear as a kind of HF grain or smearing. The uncomfortable truth for the streaming world is that the source of that jitter has shifted. It's no longer primarily your DAC chip. It's your network streamer, and more specifically, what happens to the audio clock between the packet arriving over Ethernet and the data reaching your DAC's conversion stage.

This piece is for people who already have a decent streaming setup and want to understand why two streamers feeding the same DAC can sound different — and whether any of the fixes you'll read about on forums actually hold up to scrutiny.

What jitter actually is in a streaming context

Jitter is timing uncertainty on a digital audio clock. In a CD transport, the laser assembly's mechanical wobble was the classic culprit. In a network streamer, the picture is more complicated.

Audio data arrives over Ethernet in packets. Packets are not time-stamped with audio precision — they're stamped with network-layer timestamps accurate to the millisecond range at best, not the nanosecond range that audio clocking requires. The streamer's onboard processor reassembles those packets into a continuous audio stream and then hands that stream to a clock, which gates the data into the DAC at the correct sample rate. The question is: how stable is that clock, and how much of the network's timing chaos bleeds into it?

Two mechanisms cause problems. The first is buffer underrun/overrun variation — if the buffer feeding the DAC fluctuates in depth, the read clock can be modulated at low frequencies, producing what measurements show as low-frequency jitter sidebands, typically below 100 Hz offset from the carrier. The second is power supply noise coupling into the oscillator circuit. Every time the network interface chip fires an interrupt, it draws a spike of current. If that spike reaches the clock circuit's supply rail, you get correlated jitter at whatever rate those interrupts fire — often 1 kHz or multiples of it.

Neither of these is hypothetical. I've measured both on commercial streamers that retail for several hundred dollars, using an Audio Precision APx555 and a high-resolution oscilloscope. The good news is that well-engineered products at the $2,000-plus tier largely eliminate both problems, and the fixes are understood.

The buffer is your first line of defence

Every competent streaming designer uses an asynchronous FIFO (first-in, first-out) buffer between the network stack and the audio output stage. Data comes in from the network at whatever chaotic pace the packets arrive, gets written into the FIFO, and is then read out by a completely independent, locally generated clock that has no knowledge of, or coupling to, the network layer.

Done properly, this should make the output clock's jitter independent of network timing entirely. In practice, it depends on the FIFO depth, how tightly controlled the local oscillator is, and whether the board layout and power distribution actually isolate the two domains.

Cheap streamers often use shallow FIFOs with a shared clock that also handles USB or HDMI peripherals. That shared clock is a compromise — you can measure it and you'll see jitter that reflects the interrupt activity of every other peripheral on the board. Better units use a dedicated, temperature-compensated crystal oscillator (TCXO) or even an oven-controlled oscillator (OCXO) running exclusively for the audio output stage. The Cambridge Audio CXN100 is a reasonable example of a mid-market unit that takes this seriously; when I reviewed it, the J-test result was clean enough that I'd struggle to argue the clock was a weak link. You can read the full test in our Cambridge Audio CXN100 review (check price).

Asynchronous USB and the reclocking question

A lot of network streamers output via USB to an outboard DAC, and this is where the asynchronous USB spec matters. Under USB Audio Class 2.0 async mode, the DAC's own clock controls the data rate — it sends feedback to the host telling it how fast to deliver data, rather than accepting whatever the host clock dictates. This shifts jitter responsibility to the DAC's internal clock, which in a good DAC is very good indeed.

The practical implication: if you're running a capable outboard DAC via async USB, the streamer's internal clock quality matters less than its ability to sustain a stable data rate without buffer starvation. A Raspberry Pi running Volumio into a well-implemented async USB DAC can measure very well here, because the DAC is doing the heavy lifting. I've run this test myself with a Pi 4 and a Chord Mojo 2 — the APx555 J-test looked respectable, which is a credit to Chord's FPGA-based reclocking more than to the Pi.

If you're interested in that Chord implementation, our Chord Electronics Mojo 2 review (check price) covers the FPGA approach in detail.

S/PDIF (coaxial or optical) is a different situation. It's an inherently synchronous interface — the clock is embedded in the signal, and the receiving DAC has to extract it. This makes S/PDIF output quality directly dependent on the streamer's clock. A jittery S/PDIF source is a jittery source, full stop, regardless of how good the DAC's PLL is. Good DACs have very tight PLLs that reject most of it; mediocre ones amplify the problem. If you're running S/PDIF from your streamer to an older or budget DAC, this is worth measuring rather than assuming.

Network switches and the "audiophile switch" debate

I might as well address this directly, because it comes up constantly: do audiophile Ethernet switches reduce jitter?

My honest answer is: in a properly designed streamer with a deep FIFO and an isolated clock, no. Ethernet is a packet protocol. The switch's job is to deliver packets reliably and without corruption, not to deliver them with audio-grade timing precision. A correctly engineered FIFO eliminates network timing variation before it can reach the audio clock. You cannot measure a difference in output jitter between a $20 unmanaged switch and a $1,000 "audiophile" switch feeding a properly designed streamer, because by the time the data reaches the audio clock, the network's timing is irrelevant.

Where network switches can matter is noise coupling via the Ethernet transformer on the streamer's board. Some switches — particularly cheap ones with noisy switching power supplies — inject common-mode noise onto the cable that can appear on the streamer's supply rail if the board's filtering is inadequate. This is a real, measurable phenomenon. The fix, though, isn't a $1,000 switch. It's a linear PSU on the streamer itself, or a better-filtered Ethernet input on the streamer's board. Spending on the switch is working around a design deficiency, and you'd be better off directing that money at a streamer with competent internal engineering.

I realise that's not what some people want to hear. But I have the measurements, and the measurements don't support the switch mythology.

Power supplies: where the real gains are

If I had a hundred dollars to spend improving a mid-market streaming setup, I'd spend it on the power supply before anything else — including the network switch, the cable, or the "reclocker" box sitting between the streamer and the DAC.

Switching power supplies generate noise at their switching frequency and harmonics. That noise rides on the DC rail. If it reaches the oscillator circuit, you get jitter correlated with the switching frequency. A linear regulated supply eliminates the switching noise entirely. The improvement in J-test measurements when swapping a typical wall-wart for a decent linear supply on a mid-market streamer can be dramatic — I've seen jitter sidebands drop by 15–20 dB in the 1–10 kHz region just from a PSU swap.

Several manufacturers now offer aftermarket linear supplies for popular streamers. Some higher-end units ship with linear supplies as standard. If you're evaluating streamers and care about this, it's worth checking the spec sheet — or asking whether the designer has published measurements.

For a sense of what separates good streaming hardware from great, our best DACs and network streamers guide covers the market from budget to reference, and you'll notice the better-measuring units tend to have linear supplies or tightly filtered switching designs.

Reclockers: genuine tool or expensive placebo?

External reclockers — devices that sit between your streamer's S/PDIF output and your DAC, accepting the incoming stream, reclocking it to a local oscillator, and re-transmitting it — are a genuine engineering tool when used correctly. In my lab, a good reclocker on a jittery S/PDIF source measurably reduces output jitter, sometimes by 30 dB or more, depending on the quality of its oscillator and PLL design.

The problem is they're not always the right solution. If your DAC has good async USB input, bypass the reclocker entirely and run USB. If your streamer already has a clean clock (easy to find out — ask the manufacturer for a J-test result, or look at independent measurements from labs like Audio Science Review), a reclocker adds cost and another signal path without adding measurable benefit.

They're most justified in one specific scenario: a genuinely high-quality older DAC with only S/PDIF inputs and no async USB, being fed by a mid-market streamer. In that case, an outboard reclocker can be the path of least resistance compared to replacing the DAC. But you should verify the improvement with measurements, not assume it.

Putting it together for a real system

If you're building or upgrading a streaming system and want to minimise jitter as an audible or measurable factor, here's how I'd think about it in priority order.

First, use async USB to your DAC wherever possible. Let the DAC's clock run the show. Second, if you're stuck on S/PDIF, choose a streamer with a published J-test result that shows clean sidebands — or buy from manufacturers who clearly explain their clocking architecture. Third, consider a linear PSU if your streamer ships with a switching wall-wart. Fourth, don't spend money on network switches or cables until you've addressed the first three. And fifth, only add a reclocker if you have a specific S/PDIF-only legacy DAC situation that warrants it.

The integrated streaming amplifiers — units where the network streamer, DAC, and amplifier share a chassis — can be a pragmatic solution here, because the best of them are engineered as a coherent whole with the clocking architecture designed in from the start rather than bolted on. Our streaming amplifiers guide covers the market across a range of budgets.

I've heard the argument that "it all sounds the same at a certain quality level" and I've also heard the argument that jitter is completely inaudible at any real-world level. Both are wrong. What the measurements tell me is that jitter varies significantly across real products, that some of that variation falls within audibility thresholds under controlled listening, and that the engineering solutions are known and achievable at reasonable price points. That's worth understanding before you spend money on the wrong link in the chain.

Marcus Vale, Editor

Tagged

Common questions

Does the Ethernet cable between my router and streamer affect jitter?
In a properly designed streamer with a deep FIFO buffer and an isolated audio clock, Ethernet cable quality has no measurable effect on output jitter. The FIFO decouples network timing from audio timing entirely. Where cable quality can matter is in common-mode noise rejection — a shielded Cat 6 or Cat 7 cable reduces noise injection via the Ethernet transformer, but the audible impact depends on how well-filtered the streamer's input stage is. Replacing the streamer's switching wall-wart with a linear supply will typically provide a larger measurable improvement than upgrading the cable.
Is S/PDIF or USB better for connecting a streamer to a DAC?
Async USB Audio Class 2.0 is generally superior because the DAC's own clock controls the data rate, making output jitter a function of the DAC's internal oscillator rather than the streamer's. S/PDIF is a synchronous interface with the clock embedded in the signal, so the DAC must extract and lock to the incoming clock — a process that passes some of the streamer's jitter through to the conversion stage. If your DAC has a well-implemented async USB input, use it. If it only has S/PDIF inputs and your streamer's clock is mediocre, an external reclocker can help.
Can I measure jitter at home without lab equipment?
Not with high precision. The standard J-test (a 1 kHz tone at -3 dBFS with a low-level 24 kHz square wave added) reveals jitter sidebands when analysed on a spectrum analyser, but you need a high-resolution audio interface with very low self-noise to resolve the fine detail. Software like Room EQ Wizard (REW) combined with a capable USB audio interface can give you a useful indication — you'll see gross jitter problems fairly clearly — but you won't reach the measurement floor of professional lab equipment. For most people, looking at published measurements from labs that use calibrated hardware is the practical approach.
About the author
Marcus Vale
Marcus Vale
Editor · Electronics & Measurement · Sydney, NSW

I'm Marcus, and I'll be honest up front: I trust a measurement before I trust my own ears, because my ears lie to me daily. I spent fifteen years designing audio electronics before I started writing about them, so when a brand tells me a number, I want to see the graph. That doesn't make me cold about this hobby — I love a system that disappears as much as anyone — it just means I'll tell you when an expensive box is selling you confidence rather than performance.

Former audio electronics engineer; objectivist; runs the test bench

More from Marcus Vale