4 ms·
The issue with jitter is about timing. Remember the endpoint of all of this is a DAC which isn't generally a buffered component - so it needs to process sample
by marstall 5y ago
The issue with jitter is about timing.
Remember the endpoint of all of this is a DAC which isn't generally a buffered component - so it needs to process samples in real time.
If a packet arrives from the switch a bit late, the DAC doesn't have any leeway to catch up.
Jitter makes a measurable difference, even with Ethernet switches - and you'll see those numbers touted by manufacturers (ex: https://nuprimeaudio.com/product/omnia-sw-8/?v=7516fd43adaa https://nuprimeaudio.com/product/omnia-sw-8/?v=7516fd43adaa)
- klodolph 5y agoDACs are often buffered. If you're transporting audio over Ethernet, the packet will contain some number of samples. Those samples have to be buffered. (For example, you might send 128 or 256 samples over Ethernet... obviously, the samples inside the packet are actually getting transmitted as a whole packet, buffered, and then sent to the DAC afterwards.) On top of that, you can synchronize the DAC clock to the clock recovered from the digital signal. For example, I routinely record data (and monitor) from an S/PDIF link. The standard way this works involves clock recovery with a PLL. That way, you only need a stable clock on the DAC--as long as the digital source remains within tolerances, it's fine. Even though S/PDIF transmits digital audio one sample at a time at a fixed rate, you don't need to worry much about jitter. We know it works this way because you can configure the gear to use internal or external synchronization. If you try recording S/PDIF with an internal clock, you get clicks and pops.