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

John, my definition of jitter: what happens when I look at the stock market lately.

If the source has HDMI audio output passing DD or DTS, why not just use one cable?

The crux is the quality of the decoding. Meridian would have us believe that its own proprietry decoding of DD and DTS is superior than non-Meridian solutions. Assuming the stock solutions don't have errors such as bit truncation in non-trivial DSP operations, I'm not sure why the Meridian solution is "better". Certainly, I have always been impressed with the detail and ambiance that Meridian's decoding is able to extract, but without a 598 or G98 and a 3x SPDIF modified player, I can't perform comparisons. Special sauce anyone? With hindsight, this would have been a great question for Bob at CEDIA.
Frank, I have been considering source -> 568 -> G68 for some time. Current prices make this extremely viable. My investigations into the Cinema/Discrete/-10dB are driven by this idea. I would use such a 568 (or even a 561) for DVD and for satellite.
Because, the decoding in the source + upsampling *may* be inferior to decoding in the G68 and no upsampling.

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).

I have always felt it was better to decode with Meridian because they could better "tap into" the critical points for fine tuning (most critically bass management and timing). There may be better points internally to derive 7.1 from 5.1 one as well. Data may get lost or munged if they have do it after it's fully decoded by a chip. But technically I think to be licensed they have to decode to the exact same bits (or be CAPABLE of it). Decoder chips might have jitter issues but I suspect that, that has more to do with the environment the decoder chip is placed in than the chip itself.

If these are the reasons it's better to decode with a "soft" decoder I think it still applies the HDMI/LPCM/Decode in player debate.

Also if all these arguments are to minmize jitter, I believe the later you decode (i.e. the longer you leave it as a packet based bitstream) the better.

So the decoding in M Player vs Non M Player vs Preamp seems to be conflicting information as time moves on to fit the solutions.

However what ever Meridian does in the end we KNOW will sound great.

Decoding in M player has a potential advantage over non-M players as MHR transfer is a low jitter solution. This might be testable with a Shawn Fogg modded Oppo, for instance. However, that's on the assumption that all other things, including the decoding, are equal. I'm sure they are not.

Good point.

I wonder what/how MHR reduces jitter. I wonder if it's a pseudo packet based scheme and has to buffered, decoded and reclocked. I also don't understand why a FIFO dejitter isn't just as good (or 99.99% as good).

Transmitting any of this stuff is fairly easy with out dropping bits. A FIFO (bitstream or PCM) takes care of Peak to Peak jitter.

Beyond that there is drift. with the FIFO I don't fully understand but they do tricks that are inaudable to fix that (I think it's discussed in the wiki). With packeted stuff I'm not sure what they do if one packeted stream drifts from another (similar discussion JK and I had around multi channel ethernet). Perhaps MultiChannel MHR sends out synchronization clocks to each pair. That is, you should all BE HERE NOW. And each receiver can speed up or slow down slightly to get back in sync.

I don't think MHR is packeted but does probably have extra meta data. I don't see how MHR could do any better on peak to peak jitter than a FIFO does with PCM. But with extra metadata they could better control drift from ONE PAIR TO ANOTHER.

Note this all guessing based on the behavior of a blackbox.

Note: I left Lexicon partly because of ridiculous claims. I have always liked Meridian's honesty. I'd rather have them say nothing and let us speculate than make unbelievable claims. When they start making unbelievable claims then you start to doubt everything they say. So I'm trying to keep them honest.

It is apparently "against the law" to output unencrypted audio from an encrypted HDMI source. M is trying to get around this by using MHR.

Does this mean that anyone with non-M digital speakers or outboard DACs is not going to be able to transmit high rez digital audio? If the signal is down rez to 24/48k can it be transmitted? [Second thought: I think nearly all high rez movie tracks are still at 24/48k].

The Tact TCS3 shows 8 channels of AES/EBU or SPDIF outputs. Theta says that they will also output digital audio. But both products are unreleased. What are they thinking?

With the increasing popularity of digital speakers has HDMI boxed itself into a corner with this issue?

Thanks,
George

Ooooh. I must admit that this use scenario is not something I had considered. The HDMI copy protection rules are very clear: Encrypted in = analogue or encrypted digital out. I do think that "increasing popularity of digital speakers" might be overstating things somewhat at this point, but having said that anyone with a Tact system is unlikely to be able to use their system with an HDMI source. It will be interesting if it transpires that Tact is working with Theta on encryption.

There is certainly going to be an increased market for 3x SPDIF mods.

Exactly.

Yes, down-rezzed two channel is available at the digital bypass jack

I am not familiar with Tact's and Theta's architectures, but they cannot output unencrypted hi-rez digital audio.

The digital speakers would need to accept an HDMI input. Decryption inside the box is what matters.

"Ooooh. I must admit that this use scenario is not something I had considered. "

I am very curious what Theta ends up doing about this. I mentioned this problem to them 3 or 4 years ago when they first 'announced' the Valis/Virtu combo which of course still isn't shipping.

Shawn

Joel, TacT's HDMI solution has been imminent for some time now... no idea what it entails.

Mark