Hmmm, where to start?
Originally Posted by FilmMixer
While I think your post contains some good information, I think there are some basic inaccuracies.
FilmMixer, I think it was your posts more than anything that convinced me that I should get an SC-05, and my understanding of PQLS that I should pair it with a BDP-51. I was trying to explain why, but the post was long enough for most folks, and I missed out quite a bit of information. Let me explain...
How can you say it's not proprietary? It's a two way HDMI communication that only works with four products in the Pioneer line up. PQLS is a proprietary Pioneer trade name for it's tech, and doesn't describe any kind of industry standard.
You can't use the PQLS feature with non-Pioneer equipment... which makes it proprietary. It's not a standard like 1394.
The idea isn't unique (like Denon's D-Link, which was one of the first to market) but other manufacturers aren't just name branding it.. these are unique variants to get the same job done (eliminating jitter) using proprietary tech to accomplish it.
I repeat, PQLS is not proprietary, its not restricted to Pioneer, and it's not even limited to HDMI. Its just Pioneers name for an industry-standard digital audio interface protocol that has actually been in use for several years.
For those with short memories, PQLS was Pioneers name for the Audio & Music protocol on firewire that was called i-link. To their credit, Pioneer was first out the blocks with i-link, but all the other majors followed soon after. They could only do this because it was
an industry standard. It was called IEC 61883-6 IIRC.
Sony produced players and amps with i-link, but they called it HATS. They didn't guarantee interoperability with other makers i-links, but everyone quickly found that they all worked together. I have a Pio DV79 with PQLS and a Sony AVR with HATS, and they work perfectly.
Denon did support i-link, but went their own way with Denon Link. There's less information about that, and I understand it works in the same way as i-link, but using ethernet instead of firewire as the physical bearer channel. There were
some audio advantages with this, but denon link WAS a proprietary interface, and nobody else used it.
PQLS is now being used on HDMI, and its defined in the HDMI V1.3a spec. See p111 section 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 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.
This is the same way that PQLS and HATS etc worked on i-link, only now its applied to HDMI and its called Audio Rate Control. Pioneer actually mentions ARC in some of its promotional literature. I was the person that first flagged up the opportunities for ARC back in July last year, and predicted that manaufacturers could use it to minimise jitter in the same way that i-link did.
Well, now Pioneer and Sony are doing this, and others like Marantz, Yamaha, Onkyo and Integra etc are bound to follow. ARC has a better chance of becoming well established as HDMI is the way forwards (for better or for worse) in a way that i-link would never be. Coincidentally, Sony are calling their ARC implemention HATS, just as they did with i-link. As before, no-one will say they are compatible as they weren't developed side by side, but any day now someone will connect a Sony player with HATS to a Pioneer amp with PQLS, and my money says it will work because they are working to the same standard. maybe its not been done yet, but remember where you heard it first!
With the Denon and Pioneer implimentation, you sure are.
There are very few pieces of gear that allow for external clock inputs, which surprises me. That is the true audiophile solution.
Thats a very effective solution, but it seems to be confined to high end stuff like dCs. Although a synchronous digital audio architecture is probably the ideal, its not an external clock in itself that is desirable, simply that the clock should be close to the DAC, and that it should avoid a compromised interface like spdif or hdmi. External clocks aren't mainstream though, and i-link, denon-link and PQLS are pragmatic solutions that everyone can use.
I've never heard that the data is what is the cause of jitter... it is the lack of a common clock, not the audio.
And SPDIF has no clock. Biphase mark code is not a clock.
Jitter is a temporal error, not data degradation.
Most high end processors (Denon AVP and Anthem D2, for example) reclock digital inputs anyways.
Jitter is caused by everything as far as I can tell, and audio data is just one thing. There's an important thing to explain. Digital audio has two information streams - ampitude info (data) and timing info (clock). Both these streams are necessary to reproduce the audio. The amplitude info comes from the disc (or whatever) and the timing info comes from the master audio clock. Jitter is indeed a temporal error, but it only affects the tiing info. Jitter is not carried by the data at all. Its the quality of the chain from the clock to the DAC that affects jitter, the data is generally robust and doesn't enter into it. Stereo and MC equipment can re-clock digital audio, so there is a slave audio clock as well as the master, but these don't work as well in practice as they do in theory (or in marketing stuff). The real solution is to keep the clock next to the DAC and keep everything else out of the way.
The clock signal doesn't travel between the transport and and AVR/SSP in most cases... it is PCM, and that is what is susceptable to jitter, not a "clock signal."
In general it does. Spdif, toslink, I2S and HDMI can all carry a clock, though they do it in different ways. Sure, compressed audio can't carry a clock, but where there's LPCM theres a clock, even if it doesn't have it's own channel. In spdif the clock is embedded into the data, and travels from the player to the AVR. With DD or DTS, the clock is only generated by the decoder in the AVR, and doesn't travel over the link. HDMI is different, as the audio timing info is carried over the video clock and CEC channels, but thats another matter.
It really isn't important where the clock is.. what is important is that all digital pieces of gear in a chain share the same clock...
The whole point of i-link or PQLS is that the clock is indeed where the DAC is - otherwise there would be no point or benefit. Yes, you have to share the clock , but the quality of the clock must be preserved or proritised for the DAC, and can be relaxed for the transport. It really doesn't matter if the clock suffers degradation going from the AVR to the player - the data will still come out just fine.
It's not as important that it works for BR and DVD if you are bitstreaming (although PCM is susceptible to it)..
Jitter has nothing to do with AV syncronization... a frame of video contains 48,000 24 bit audio words per channel... jitter occurs at the thousands of a second level.
Bitstream codecs are immune to jitter...
This is a huge subject, and probably beyond this thread. It depends on the architecture of the AVR, and how it regenerates the audio clock. When HDMI is used to carry DTHD & DTS MA to the AVR, the audio clock may be generated from the video clock, so it will still be prone to jitter, but the HDMI spec doesn't lay down the law here, and receivers may do things differently.
Originally Posted by catapult
Yeah, what FilmMixer said about PQLS.
All these HDMI receivers buffer and reclock the PCM. As long as the buffer is big enough, PQLS isn't needed. In dr1394's testing, he played a whole CD with the older firewire Pioneer combo and never saw a single 'speed up' or 'slow down' command meaning the buffer never overflowed or underflowed and PQLS wasn't required with that combo. Until I see some actual jitter measurements, I'll remain skeptical that the 'improved sound' with PQLS is anything more than the placebo effect.
All this is irrelevant. 1394 i-link doesn't carry jitter from a player to the AVR, because it doesn't carry the timing info in that direction. Its a simple as that. The data can have pretty much all the jitter it likes, but the clock won't suffer from ANY of it.
Pioneer didn't think it was big enough a deal to include it on the flagship 09.
Yes they did - that has i-link inputs!