5 ms·

Digital "jitter" is actually a thing that can measurably degrade quality. The DAC clock and the source clock need to be in perfect sync or else the quality of

Digital "jitter" is actually a thing that can measurably degrade quality. The DAC clock and the source clock need to be in perfect sync or else the quality of each sample will effectively degrade. Higher end CD transports have a "clock link" that lets you sync their data stream with an outboard DAC. Gets harder with audiophile-level sample rates (24 bit, 192Khz). https://www.thewelltemperedcomputer.com/KB/BitPerfectJitter.htm https://www.thewelltemperedcomputer.com/KB/BitPerfectJitter.... https://blog.teufelaudio.com/jitter/ https://blog.teufelaudio.com/jitter/

olyjohn 5y ago
And so what's this have to do with the Ethernet switch? Surely that's the last place you'll encounter errors, is in your own house, on your own hardware that's barely got any traffic running through it. After the audio file has been transmitted through loads of Ethernet switches, routers, fiber, over the public internet, into your shitty ISP, over some old crappy copper lines into your cheap-ass modem... some how the switch in your house is going to make corrections to the data packets and ensure they all get there... give me a break.
- deleted 5y ago
  [deleted]
- 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 ago
    DACs 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.

olyjohn 5y ago

And so what's this have to do with the Ethernet switch? Surely that's the last place you'll encounter errors, is in your own house, on your own hardware that's barely got any traffic running through it. After the audio file has been transmitted through loads of Ethernet switches, routers, fiber, over the public internet, into your shitty ISP, over some old crappy copper lines into your cheap-ass modem... some how the switch in your house is going to make corrections to the data packets and ensure they all get there... give me a break.

deleted 5y ago
[deleted]
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 ago
  DACs 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.