[Welwynnick]

I've had a big downer on HDMI (and V1.3 in particular) for as long as I can remember. TrueHD & DTS-HD compatibility made me think twice, though, but something happened today that got me really hopeful for audiophile standard interfacing in the near future. Really not sure where to put this thread, as it's about HD audio quality. HiFi? Receivers? Audio processors? HD DVD? Blu-ray? Cables? Dunno, I guessed it was most appropriate here, going by the usual audience. Well, I was browsing the latest HDMI V1.3a specification today.... What? What 's so funny? Doesn't everyone?
Anyway, I stumbled across a small new section that I hadn't seen or heard of before. This described, in not very much detail, a new and optional facility for the audio clock in the processor / amplifier to control the clock in the source using a CEC Set Audio Rate command back the source. Here's what the spec says:

7.11 Audio Rate Control Overview
The Audio Rate Control feature allows a Sink to slightly and continuously adjust the audio clock rate of the Source in order to match the Sink’s crystal-based audio clock. The Sink controls the Source’s audio clock rate with the CEC <Set Audio Rate> command. See CEC Supplement section CEC 13.16 for details. Source ACR behavior is not affected by Audio Rate Control. When Audio Rate Control is enabled the Source shall continue to generate correct ACR packets that accurately reflect the current (possibly adjusted) audio clock rate.

So what does this mean for us? I'm not entirely sure, as the new capabilty doesn't look closely defined, but to me it reads very much like Sony and Pioneers' descriptions of iLink operation. That's a rate adaptive connection, where the sink (amp) has the master audio clock, rather than the other way round.

It's not a synchronous connection, but I think it's a good thing because the timing information doesn't have to come from the player. That means it's less susceptible to the jitter from (usually) a video clock, a less-than-stellar connection, and an audio clock regenerator in the amp that is slaved to the player. In this configuration, the timing information is generated in the amp, leaving the source to supply only the digital amplitude information. So bits really will be bits for once. Timing info is sent back to the source to maintain flow control.

I don't know where this came from, and I don't know why I never noticed it before. Maybe the audiophile manufacturers, so dismayed by the disappointing jitter performance of HDMI, have been lobbying HDMI for something better. If this is it, then I think we have a great deal to look forwards to. Note that this facility was not incorporated in HDMI V1.3, though, only 1.3A.
Well chuffed, Nick

[ianh64]

Its the reason why no decent audio manufacturer has bought out an HDMI 1.3 solution yet.

Their view is to do HDMI once and get it right. Not come up with some compromise solution.

[peterweg]

Is this the lip-sync functionality described here?
http://www.hdmi.org/pdf/HDMI_Insert_FINAL_8-30-06.pdf

If so, its not new its dated 30th August 2006. I remember reading it about that time.

[Welwynnick]

Originally Posted by peterweg

Is this the lip-sync functionality described here?
http://www.hdmi.org/pdf/HDMI_Insert_FINAL_8-30-06.pdf

If so, its not new its dated 30th August 2006. I remember reading it about that time.

That's time control, not frequency control. Lip sync functionality was one of the headline features added in V1.3. Audio Rate Control was quietly added with other tidy-up / bug-fix actions in V1.3a. Here's a summary of the additions for both:

1.3a 2006/11/10 Cable and Sink modifications for Type C (Table 4-20, 4.2.6)
Source termination recommendation (after Table 4-15)
Removed undershoot and max rise/fall time limits (4.2.4).
Modified slope of TP1 and TP2 eye diagrams (4.2.4, 4.2.5)
HDMI cable assembly AC-coupling support required (4.2.6)
CEC capacitance limits changed (4.2.10)
Valid range for RGB video quantization added (6.6)
Added audio sample rate exceptions for ARC (7.3, 7.3.1, 7.3.2)
Added Audio Rate Control Overview (7.11)

1.3 2006/06/22 Significant new features:
- Type C “Mini-Connector” (4.1.9.5, 4.1.9.6)
- Cable Categories 1 and 2 (4.2.6)
- Deep Color [4:4:4] (6.5, 8.3.2)
- Reference Cable Equalizer (4.2.3.2, 4.2.5, 4.2.6)
- Higher-speed single-link (4.1.2, 4.2.3,through 4.2.6, 8.3.2)
- xvYCC Enhanced Colorimetry (6.7.2.3)
- Gamut Metadata transmission (5.3.12, 6.7.3, Appendix E))
- DST audio format (5.3.10, 7.6.3)
- High-bitrate compressed audio formats (5.3.11, 7.2.4, 7.3.3, 7.6.2)
- Auto-Lipsync Correction feature (8.3.2, 8.9)
Updated normative reference from CEA-861-B to –D (1.2, throughout).
Updated Overview for new features (3)
Several minor editorial (throughout)

If I understand the significance of this, there is the opportunity for HDMI to provide an entirely jitterless connection between compatible players and amplifiers. It's all about jitter, and this is my attempt to explain it's significance. HDMI appear to recognise that some manufacturers will prefer have the audio master clock in the processor or receiver, and have the player slaved to that.

Synchronous links between equipment are ultimately preferred (where the phase is controlled directly). Here, the digital audio link seems to be isochronous instead, where the frequency is controlled instead. Similar, but not quite the same. Still, that's a pretty advanced implementation, but the HDMI feature does look very simple to incorporate.

Given that the potential of even 16/44.1 audio is usually limited by jitter (not resolution), the opportunities to make the most of 24/96 audio with this sort of jitter control are very attractive to audiophiles. Otherwise TrueHD would be little better than CD.

Nick

[Avi]

Originally Posted by welwynnick

That's time control, not frequency control. Lip sync functionality was one of the headline features added in V1.3. Audio Rate Control was quietly added with other tidy-up / bug-fix actions in V1.3a. Here's a summary of the additions for both:
If I understand the significance of this, there is the opportunity for HDMI to provide an entirely jitterless connection between compatible players and amplifiers. It's all about jitter, and this is my attempt to explain it's significance. HDMI appear to recognise that some manufacturers will prefer have the audio master clock in the processor or receiver, and have the player slaved to that.

Synchronous links between equipment are ultimately preferred (where the phase is controlled directly). Here, the digital audio link seems to be isochronous instead, where the frequency is controlled instead. Similar, but not quite the same. Still, that's a pretty advanced implementation, but the HDMI feature does look very simple to incorporate.

Given that the potential of even 16/44.1 audio is usually limited by jitter (not resolution), the opportunities to make the most of 24/96 audio with this sort of jitter control are very attractive to audiophiles. Otherwise TrueHD would be little better than CD.

Nick

Nick


Does this mean all HDMI "1.3" devices meet the minimum mandatory spec of "1.3a" or not ?

AVI

[Ian_S]

HDMI has no mandatory spec unfortunately.

Just a variety of versions and a whole set of optional functions. So, you can have an HDMI 1.3a chip fitted and still only use functionality that was available in HDMI 1.1.

Personally I expect to see a lot of this as I'm sure it will make sense to use one chipset/version on everything.

People will need to understand that having HDMI 1.3 does not mean deep colour, HD audio bitstream etc. It just means the HDMI chipset can transmit those things *IF* the rest of the electronics implement that capability.

You need to look at the functionality of the device, NOT the HDMI revision level.

[Timbo21]

Originally Posted by Ian_S

HDMI has no mandatory spec unfortunately.

But at least if it has the ability, then manufacturers are able to implement it, which is what companies like Meridian and Arcam will do, and I dare say Denon and others as well.

T.

[Avi]

Originally Posted by Ian_S

HDMI has no mandatory spec unfortunately.

Just a variety of versions and a whole set of optional functions. So, you can have an HDMI 1.3a chip fitted and still only use functionality that was available in HDMI 1.1.

Personally I expect to see a lot of this as I'm sure it will make sense to use one chipset/version on everything.

People will need to understand that having HDMI 1.3 does not mean deep colour, HD audio bitstream etc. It just means the HDMI chipset can transmit those things *IF* the rest of the electronics implement that capability.

You need to look at the functionality of the device, NOT the HDMI revision level.

I understand that the "implentation" may be optional but my point is that you can't "optionally" provide some features unless the version of HDMI supports it. So my question is do all HDMI "1.3" products have the "option" if implmented to offer all features supported by 1.3a or are there different "HDMI versions" chipsets for 1.3a and 1.3.

AVI

[Ian_S]

Originally Posted by Avi

I understand that the "implentation" may be optional but my point is that you can't "optionally" provide some features unless the version of HDMI supports it. So my question is do all HDMI "1.3" products have the "option" if implmented to offer all features supported by 1.3a or are there different "HDMI versions" chipsets for 1.3a and 1.3.

Different chipsets.

[Welwynnick]

I think HDMI may have made a big mistake in not making every piece of functionality compulsory at each version. Allowing manufacturers to pick and chose what they want to implement has caused a great deal of confusion and mistrust. For all the fine talk and the good intentions, I think it's been an example of how not to implement a new standard. I can understand the commercial attraction of drip feeding new capabilty every year of so to generate more hardware sales, but the benefit of a new HDMI version is undermined if what it delivers in practice isn't clear. It doesn't necessarily do what it says on the packet.

V1.3a does look like rather an afterthough, tying up lose ends from the problems with 1.3. Just as it seemded to be with 1.2. No great surprise, though; that's how it happens with complex systems technology.

With regard to Audio Rate Control, although this may be simple to implement at the interface level through the addition of some simple CEC messages, the playback system itself may have some significant changes. It looks to me like a HATS / PQLS (?) type of implementation - i-Link over HDMI if you like. if that is the case, then the whole digital audio playback architecture would have to change. Which is the real objective, to my mind. The audio master clock will be in the DAC / processor / amp, rather than in the transport, and this is just a control interface to support that architecture. So I'd pretty sure that any V1.3 equipment will not support audio rate control.

Nick

[Rasczak]

Originally Posted by welwynnick

I think HDMI may have made a big mistake in not making every piece of functionality compulsory at each version.

To be fair though most normal consumers aren't really going to be that bothered about jitter. And, if the revision works as you have outlined (which I certainly hope it does), then the high end brands will use it on their kit anyway.

[Welwynnick]

Originally Posted by Rasczak

To be fair though most normal consumers aren't really going to be that bothered about jitter.

Oh, I dunno - my wife has as much interest in hifi as I do in needlepoint, but when I plugged the i-Link in, even she was drawn to say "that sounds much clearer".

And that was only with CD. With 24 bit audio, there is even more to be gained or lost.

Nick

[Nic Rhodes]

Originally Posted by welwynnick

I think HDMI may have made a big mistake in not making every piece of functionality compulsory at each version. Allowing manufacturers to pick and chose what they want to implement has caused a great deal of confusion and mistrust.

If they had done this it would have saved my afternoon!! I think all these new technologies are making 'mistakes' about making stuff optional, whether HDMI, HD DVD or Blu-ray. Make it all compulsory.

[Welwynnick]

I had a few more ideas about digital audiophile sound over HDMI.

Firstly, I had been thinking that HDMI V1.3 might allow improved audio, because, with THD or DTSMA being compressed audio, the timing info (audio clock) would have to come from the DAC / processor / amp. That means that the connection wouldn’t contribute to the overall jitter. On reflection, I doubt this would be realised, because the audio clock would probably still be derived from the HDMI video clock in the same way that PCM audio is. That suggests bit-stream may indeed sound the same as LPCM, so we may as well use the latter over V1.1.

However, use of the Audio Rate Control with V1.3a might still be an advantage. I think the HDMI clock might be going in the wrong direction, though. It’s the sink that needs the clock, not the source. So why not have the clock run back to the source – the line is already there? If rate control can be implemented in CEC protocol from the sink, then why can’t the direction of the clock? The source will be slaved to the sink, and it won’t matter that it’s the video clock – all the source has to do is provide the digital data, not the clock.

This could work with either a disc player or a media player (from a hard drive). But of course, this wouldn’t work with any sort of broadcast source, where the sink would have no control over delivery. However, if Audio Rate Control can work backwards with a clock in the sink, then perhaps it could work forwards with a source clock. This time, the source clock would be responsible only for flow control, but the timing info would still come from clock in the sink, just slaved to the source clock by forward running Audio Rate Control commands. That would be rate control, not phase control, as it’s not synchronous. It wouldn’t be the same as we have now, where the audio clock is decimated directly from the video clock in the source.

Still not sure about all this; just thinking out loud. Maybe all the clever HDMI committees (what am I saying?) have discussed and rejected this years ago.

Regards, Nick

[Rasczak]

Originally Posted by welwynnick

Still not sure about all this; just thinking out loud.

Please keep doing so - it's very interesting to hear your take on this. HDMI is certainly far from the perfect interface. However from an audiophiles perspective won't we just be better off staying with full analogue audio decoding in our players rather than looking to pass decoding to the receiver? I can certainly see the benefits for the budget market to adopt a 'transport only' strategy for their players though.

[Welwynnick]

Well, actually, I had this other idea as well.......

I've heard varying reports on how well audio sounds over HDMI. Part of the answer may be that it does indeed vary. The first variable may be the quality of the amplifier input, and in particular, how well the audio clock recovery circuit works.

What may complicate things is that the video clock that the audio is derived from, is a moveable feast itself. The video clock is simply the video pixel clock, which includes the blanking periods that are part and parcel of de-compressed video (and which contain audio BTW). That pixel clock is therefore a function of the video format - it's resolution, repetition and refresh rate. And it also happens to be a limitation on the data rate avaialble for audio. Perversely, the lower the video bandwidth, the less bandwidth is available for audio. Sounds counter-intuitive, but that's the way it works.

Anyhow, that made think about how audio is carried. Where the video BW is high, as with 1080p60 for example, not only are the video bits carried vary fast, but so are the audio bits. I thought that must have some impact on SQ, but I don't know what.

Could it be that the video clock is more accurate when all those bits are coming through thick and fast? When there is that much less time available for each bit, perhaps each start and stop time is more accurate? In other words, has less jitter. And that will be reflected in less jitter in the audio clock that is decimated down from the video clock?

The impact of this might be that Dolby TrueHD soundtracks carried over HDMI alongside high rate video like 1080p could actually sound different to, say, DD audio travelling in company with SD video. Therefore, whenever someone says that HDMI "sounds rubbish" or "sounds great", it may help to qualify that view the type of video being carried as well.

I'm thinking out loud again, sorry for all the rambling, but as you can tell, this audio-over-HDMI thing is bothering me. I suppose I should just plug in all the i-link, hdmi, spdif, toslink and analogue connections from my new player to my new amp and just see what it sounds like!

Nick

[Welwynnick]

Dutch has spotted that the forthcoming Pioneer SC-LX71 & 81 will have PQLS on their HDMI interfaces. That was what they used on i-Link on their earlier amplifiers to such great effect. This sounds like it might be an HDMI implementation of adaptive flow rate control. Ands about time, too!

Pioneer LX90 is nearly here!

http://www.pioneer.eu/eur/content/pr...Receivers.html

Pioneer audio synergy
We have created jitter-free playback and dynamic sound quality for music CDs.

When connected to a new Blu-ray Disc player via HDMI, the SC‑LX71 and SC-LX81 receivers playback CDs perfectly with the proprietary Precision Quartz Locking System (PQLS). The advanced feature synchronizes data coming from the Blu-ray Disc player to the receiver, providing you with a feeling of being in an auditorium enjoying your favourite band.

ICE power amplifiers as well. Can't wait to hear this!

Nick

[Krobar]

Originally Posted by welwynnick

Dutch has spotted that the forthcoming Pioneer SC-LX71 & 81 will have PQLS on their HDMI interfaces. That was what they used on i-Link on their earlier amplifiers to such great effect. This sounds like it might be an HDMI implementation of adaptive flow rate control. Ands about time, too!

Pioneer LX90 is nearly here!

http://www.pioneer.eu/eur/content/pr...Receivers.html
ICE power amplifiers as well. Can't wait to hear this!

Nick

Apparently Pioneers reps at the Bristol show said the SC-LX90 is capable of PQLS too.

Am I right in thinking the Pioneers are capable of reclocking all audio data that does not come with video to the amplifier's native rate using a small buffer and CEC commands which essentially destroys ALL jitter from the source and leaves you only with the internal jitter in the receivers design.

[charliecossie]

Nic and Nick:-
Why would Pioneer specifically state "playback CDs", excluding all other formats? Thoughts?

[Nic Rhodes]

Probably as it is an audio only format that is 'simple' to do.

[Welwynnick]

Originally Posted by Krobar

Apparently Pioneers reps at the Bristol show said the SC-LX90 is capable of PQLS too.

Am I right in thinking the Pioneers are capable of reclocking all audio data that does not come with video to the amplifier's native rate using a small buffer and CEC commands which essentially destroys ALL jitter from the source and leaves you only with the internal jitter in the receivers design.

Hi Krobar, thought you might not be too far away. Did they mean that the LX90 uses PQLS on HDMI, and not just on i-Link?

Do you have a link for what they are doing with re-clocking? Lots of jitter solutions claim to eliminate jitter, none more so than Benchmark for example, but I get the clear impression that they are all only partial solutions. As long as the clock is in the source, there is a limitation. As GaryB said recently, talking about the SB+, the solution is to have the clock next to the DAC.

Originally Posted by charliecossie

Nic and Nick:-
Why would Pioneer specifically state "playback CDs", excluding all other formats? Thoughts?

Originally Posted by Nic Rhodes

Probably as it is an audio only format that is 'simple' to do.

I quizzed a few clever types at AVS about this a while ago. Apparently i-Link only works in isochronous mode with CDs, and not with DVDs, as the digital audio is always compressed. PQLS doesn't appear to work with audio tracks on video material, because the video/display can't be sync'd to the amplifier. How i-link works with DVD-A and SACD I'm not sure, but having HDMI PQLS just for CDs over is a great step forwards to my mind. The combination of quality and catalogue adds up to a lot of value.

Nick

[charliecossie]

Oh well, another plan in tatters.
Want Blu HD sound, want iLink, can't afford the Pio monster.
Wanting, wanting, wanting, never getting.....

[Nic Rhodes]

Nick

I remember pointing out the different modes that ILink works under a year or two ago here when people were discussing Ilink. Their assumption was it was all good, I think I took a more pragmatic view that it 'could be' good. It is great to see these things on kit, it is certainly a step in the right direction and great for 'minimising' jitter associated with the interfaces. Welcomed if not currently affordable! This was always Pioneer at it's best, let's hope they make the best use of this.

[JohnWH]

As I've commented elsewhere, I think the use of PQLS for AV is largely redundundant due to the nature of how the data is deleivered, with LF jitter not existing and HF jitter really only being a problem resulting for poor implementation of clock extraction. Further to this there are DAC's available these days that have sufficient HF jitter rejection to make it largely a non problem, or at least that should be the case in higher end systems imo.

John.

[Krobar]

Originally Posted by welwynnick

Hi Krobar, thought you might not be too far away. Did they mean that the LX90 uses PQLS on HDMI, and not just on i-Link?

Do you have a link for what they are doing with re-clocking? Lots of jitter solutions claim to eliminate jitter, none more so than Benchmark for example, but I get the clear impression that they are all only partial solutions. As long as the clock is in the source, there is a limitation. As GaryB said recently, talking about the SB+, the solution is to have the clock next to the DAC. I quizzed a few clever types at AVS about this a while ago. Apparently i-Link only works in isochronous mode with CDs, and not with DVDs, as the digital audio is always compressed. PQLS doesn't appear to work with audio tracks on video material, because the video/display can't be sync'd to the amplifier. How i-link works with DVD-A and SACD I'm not sure, but having HDMI PQLS just for CDs over is a great step forwards to my mind. The combination of quality and catalogue adds up to a lot of value.

Nick

Hi Nick,

Yep I cant resist this subject.

I used to have a have a DV-868/VSX-A10I combo and PQLS only works for CD, DVD-A and SACD. The reason is synching with video is impossible.

Second hand comment I heard from the bristol show said there would be a high end Pioneer Blu player with "Clock Synch" to partner the SC-LX90 released at the end of the year. There is no doubt that this is the BDP-LX91 (Talked about at Munich High End this week) but whether this is done over ILink or HDMI is unknown. If Pio can set the player to output over ILink for CD/DVD-A/SACD and HDMI for the rest then that would probably be the best performing solution.

I really want the LX91 to offer ILink but the USA rep says it is not currently planned. He was surprised at the size of the backlash he got from owners of $/£4000+ Ilink only receiver owners. They'd do well to include it because it would net a good number of customers who are otherwise happy to buy from Denon or even Panasonic.

[Ian_S]

Originally Posted by JohnWH

As I've commented elsewhere, I think the use of PQLS for AV is largely redundundant due to the nature of how the data is deleivered, with LF jitter not existing and HF jitter really only being a problem resulting for poor implementation of clock extraction. Further to this there are DAC's available these days that have sufficient HF jitter rejection to make it largely a non problem, or at least that should be the case in higher end systems imo.

Maybe here is a better place to continue that discussion from elsewhere...

Whilst I understand your point about how data comes of disc, and the fact that the video for example is vbr... what I was talking about there, and what people are talking about here, is how that data gets moved AFTER the obligatory player decoding. At this point neither the video or audio is variable, video is fixed into full frames and audio (if decoded in player) is full bitrate PCM. The jitter I am concerned with is not from the transport, but from whatever clock is being used to create the HDMI TDMS clock signal. It would seem at present that PCM over HDMI signals are processed using that TDMS clock and NOT re-clocked in the amplifier. At this point I believe that the audio and video are intrinsically linked as one would hope a player exits audio and video in the best sync it can manage. If an amp is purely an intermediate device, then my assumption is that it too must pass on video still in sync with audio over it's HDMI out...

To that end, I don't understand why you feel the jitter issue is not relevant for the sound when it's transferred from a player to an amplifier as digital PCM. Especially when Pioneer's own definition of their PQLS system is:

Pioneer PQLS (Precision Quartz Lock System) enables the amplifier/receiver to conform the speed of the DVD player's signal transfer to its own crystal clock speed. The original digital bit stream will be regenerated in the amplifier/receiver using its own clock. Hence, jitter resulting from the signal transmission is reduced to an absolute minimum, and SACD and DVD-Audio sound reproduction is as true to the original source as possible.

This seems to imply that even over iLink jitter is introduced via transmission, so I'm not sure why HDMI would not suffer similarly. Certainly for DVD-Audio at this point we have PCM coming over iLink and I'm not sure I see the difference between DVD-Audio PCM and Blu-ray PCM other than Blu-ray over HDMI has a video component.

What Pioneer seem to be saying for PQLS over iLink was that they simply(!) re-clocked the audio using an in-amplifier clock instead.

Now Krobar and others think their new HDMI verison may make use of HDMI 1.3a's new audio rate control to somehow control HDMI transmission jitter, I wouldn't even know where to start...

The reason I'm assuming that this HDMI transmission jitter is a problem is because ultimately with lossless audio codecs, the only difference between the amp decoding to PCM and then out through DACs and it receiving PCM to push out through it's DACs is the 'clocking'. The fact that people are hearing better audio performance via the same amp, and same speakers with the same player when they switch between player decoding and amp decoding must mean there's a reasonable difference between how the amp is handling the clock or timing element between bitstream and PCM.

Further, over HDMI, even PCM is effectively packetised like bitstream, as there is no continuous PCM stream over HDMI. All audio is just segments between much larger bits of video. So drawing on your description of the transport not mattering for audio/video because it's vbr and has to be buffered for decoding, likewise a similar process has to be occurring to get the audio out of the HDMI signal even for PCM, and this buffering that must be being done inside the HDMI chipset does not seem to be eliminating the problem, else there really would be no difference between in-player decoding and outboard decoding of lossless audio...

All this is why, still, I don't see how you can separate audio and video in an HDMI connected amplifier. Pioneer's iLink PQLS seems to rely on buffering, which seems like a logical reason why the HDMI implementation only deals with CD because there is no accompanying video. For Blu-ray you have approx 2MB of video data per frame + whatever audio plays whilst that frame is displayed.

Now surely (and we've long left the player, so please, can we agree that we have decoded audio+video) if you are buffering PCM audio in the amp to re-clock it more accurately, you also have to buffer video with that audio so that when it gets passed on it is not ahead of the audio?? This to me seems like quite a difficult task when frame rates are in Hz and audio sample rates are in KHz.

This is also why I'm not so sure PQLS on the upcoming Pioneer is using HDMI 1.3a ARC, as if it was, would that not also work for any HDMI stream, not just CD??

[Krobar]

Now surely (and we've long left the player, so please, can we agree that we have decoded audio+video) if you are buffering PCM audio in the amp to re-clock it more accurately, you also have to buffer video with that audio so that when it gets passed on it is not ahead of the audio?? This to me seems like quite a difficult task when frame rates are in Hz and audio sample rates are in KHz.

This is also why I'm not so sure PQLS on the upcoming Pioneer is using HDMI 1.3a ARC, as if it was, would that not also work for any HDMI stream, not just CD??

HDMI's flow control will not allow buffering with Video because the video display would have to drops frames or audio drop outages would have to occur as you purge a full buffer periodically.

IF HDMI had seperate Audio and Video clocks maybe PQLS could work with video (Assuming Video Display is also aware) but current HDMI implementations always derive the audio clock from the Video clock.

The beauty of PQLS is that for Audio sources you only need a small buffer that the receiver monitors and then issue slow down or speed up clock commands to the source in order to keep the buffer from over or underflow.

[Ian_S]

Originally Posted by Krobar

HDMI's flow control will not allow buffering with Video because the video display would have to drops frames or audio drop outages would have to occur as you purge a full buffer periodically.

IF HDMI had seperate Audio and Video clocks maybe PQLS could work with video (Assuming Video Display is also aware) but current HDMI implementations always derive the audio clock from the Video clock.

The beauty of PQLS is that for Audio sources you only need a small buffer that the receiver monitors and then issue slow down or speed up clock commands to the source in order to keep the buffer from over or underflow.

OK, so what I think you're saying here is that PQLS is Pioneer's way of using HDMI 1.3a audio rate comtrol, which is effectively HDMI CEC commands telling the player to slow down or speed up data delivery to the buffer in the receiver. The receiver is using the buffer to then effectively regenerate the clock signal more accurately.

I don't see why this wouldn't work with ANY audio, as this is not changing the HDMI signal clock at any point, just the audio signal in the player being fed to the HDMI transmitter...

There is a big but to that though. That being to achieve the buffering, the audio may no longer be perfectly in sync with video when it exits the player. However, this may not be the end of the world, as I strongly suspect the receiver is using it's own clock rather than one originated in the player when it decodes bitstream. As John has described elsewhere, a lossless bitstream is variable in rate, so some buffering must be occurring as part of the decode process and a clock applied. So pragmatically is there any difference between the player varying the audio signal and a receiver decoding bitstream?

The purist in me says that the best way to do this would be to take BOTH audio and video from HDMI in the receiver and buffer BOTH, and send on the video with perhaps an amp generated basic stereo stream (which is allowed to be sent over HDMI even to devices that advertise no audio support) still in sync, re-clocking the audio in the process. I imagine though this would be horribly expensive.

The key for me is realising that the HDMI clock is almost irrelevant as the amp can't see it or do anything with it. It simply gets given one video feed and one audio feed simultaneously from the HDMI reciever... see attachment.

[Ian_S]

Just so you don't think I'm completely barking with the very high level diagram, look at the circuit diagram on page 2 of this...

http://www.siliconimage.com/docs/sii...nal_1-9-07.pdf

The Sil9135 does the extraction of the audio signal and audio clock recovery as well as separating out the video signal. This doesn't appear to leave much scope for audiophile tweaking at the HDMI signal level. So, you're left with either using the audio signal and recovered clock which is what I think amps are defaulting to with straight PCM signals, or performing some kind of buffered clock regeneration which is sort of what they do out of necessity with TrueHD/DTS-HD MA bitstream.

If they sort out audio, will we then be looking at endless lip-sync issues?

[Krobar]

Originally Posted by Ian_S

OK, so what I think you're saying here is that PQLS is Pioneer's way of using HDMI 1.3a audio rate comtrol, which is effectively HDMI CEC commands telling the player to slow down or speed up data delivery to the buffer in the receiver. The receiver is using the buffer to then effectively regenerate the clock signal more accurately.

I don't see why this wouldn't work with ANY audio, as this is not changing the HDMI signal clock at any point, just the audio signal in the player being fed to the HDMI transmitter...

There is a big but to that though. That being to achieve the buffering, the audio may no longer be perfectly in sync with video when it exits the player. However, this may not be the end of the world, as I strongly suspect the receiver is using it's own clock rather than one originated in the player when it decodes bitstream. As John has described elsewhere, a lossless bitstream is variable in rate, so some buffering must be occurring as part of the decode process and a clock applied. So pragmatically is there any difference between the player varying the audio signal and a receiver decoding bitstream?

The purist in me says that the best way to do this would be to take BOTH audio and video from HDMI in the receiver and buffer BOTH, and send on the video with perhaps an amp generated basic stereo stream (which is allowed to be sent over HDMI even to devices that advertise no audio support) still in sync, re-clocking the audio in the process. I imagine though this would be horribly expensive.

The key for me is realising that the HDMI clock is almost irrelevant as the amp can't see it or do anything with it. It simply gets given one video feed and one audio feed simultaneously from the HDMI reciever... see attachment.

It IS changing the HDMI clock and this means the video AND audio clock in the case of HDMI.

You can try to buffer the audio and video but lip synch would be a big issue as would the potential sizes of buffers needed to avoid overflows and hence AV droputs.

The receiver does use its own clock to decode bitstreams but AFAIK pays very careful attention to the timestamps. The packetised nature and time stamps ensure that VBR compressed audio does not effect decoding output timing at all. The decoder in the amp will stick to the timecodes regardless of the size of the packet; a VBR stream is no less accurate with regards to lip synch than a CBR one.