Meridian Unplugged - Powered by MrTechGuy.co.uk Forums Discussion Meridian - Systems The Quasi-Official Meridian CEDIA Q+A Topic.

Non-techies - skip to the bold bit for the point.

Normal DD/DTS is frame based, much like SPDIF. The output data rate is constant wrt the clock (48kHz samples, 64 SPDIF bits per sample (or 128 cells)). The recovered clock from the SPDIF input has to be cleaned up and used for the DACs (constant x clocks per sample - probably 64). This sort of fixed relationship can mean a critically optimised filter.

My opinion (and it's just that - there could be something I've missed) about why HDMI is poor for jitter is because the interface clock is the video clock. The audio clock doesn't have to have a fixed relationship to it, although the video clock is always the source of it. They can vary the ratio, but it's always based on the video clock. This means that you can't optimise the clock clean up (PLL bandwidth) as much because you don't know how fast it's being manipulated (I didn't see this in the spec - might have missed it), and how much drift is tolerable at any moment. This would be a great place to put some Meridian special stuff. The chain is Video Clock -> Variable ratio PLL -> DAC.

It's the clocking tree that matters for jitter. For a true packet source (like a squeezebox) you have flow control - you can throttle or speed up the input data rate under the control of the DAC system. This implies that you can create your own clock. Same idea applies for a CD-ROM style transport - you can vary the input data rate. HDMI is sort of packet based, in the sense that it would require a FIFO and has a variable input rate for audio - but it's not in the control of the DAC (or processor).

For a frame based transmission (like SPDIF), you can't insert or drop samples (upsampling is a special case), so you have to use the recovered clock. Of course you can clean it up (like in FIFO/PLL jitter filter), but after averaging over time, you must have 0ppm difference in frequency.

HDMI has all the issues that SPDIF has wrt not being able to control the data rate and use a local clock source. But with the added complication of a variable relationship, making cleanup more difficult.

Footnote: The problem with a truly packet based audio transmission from a video disc is that it would allow the audio to get out of sync with the video. That's why HDMI allows a variable rate audio clock. Your squeezebox has no latency requirement wrt to the NAS, which is why packet based transmission is ok. This may also be the issue with precisely synchronising multiple squeezeboxes, which I believe has been a problem until recently.

I doubt very much that bitstream or PCM would make any difference to clocking structure. I haven't read any of the new CODEC specs, though. (I have read the AC3 spec (it's publicly available) - it wouldn't have affected that).