[Nic Miller]

Have heard a lot of discussion about the 800AP and it's huge jitter readings and this is putting people off buying it, but what about people who actually own it or have heard one - is this actually an audible problem or just a meaningless statistic? I am not interested in the fact that it has high jitter or not, what I am interested in is whether this makes a difference to the sound! Obviously at some point I will have to let my own ears decide, but what do you guys think?

I just can't seem to understand how such a highly praised amp is only £800 !!! Seems like a steal! Too good to be true?

ps I'll be running 7.1 LPCM over HDMI from probably an Oppo 83. Used 20% BD, 79% DVD, 1% CD - obviously BD percentage will grow and DVD fall.

Plus SKy+ / HD

Am aware there is an 8000AP thread, but come on, it's 140 odd pages long and there's no way I am trawling through all of that to see what's been said!

Many thanks

Nic

[stevefish69]

What does this Jitter actually suppost to sound like

I've never heard anything from my Audiolab apart from pristine sound with a very low noisefloor. It's hard to describe how much difference the blackness of the background makes, apart from making me jump due to increased dynamics (also helped greatly by the Cinepro though )

I use mine along with a XE1 and PS3 both feeding it with LPCM over HDMI. For CD's i use the Digital Coax from my old CD52 and the DAC's were that good in the Audiolab that it enabled me to flog my old Beresford 6/3

It beats my old Denon A11SR hands down as a processor / Pre amp when coupled with my two old Parasound Power amps. The Denon was no slouch and was pretty high up the food chain and IMO the Audiolab is a steal at £800

Oh - and it's sexy, slim and matches my SVS-EQ1 nicely when stacked together

[lbstyling]

jitter is a timing error.

it seams a common misconception that it just raises the noise floor- in the case of the audiolab -thats already extremely low in the analogue stage.

you can create a kind of timing error by placing a reflective serface next to you speaker mid driver very closely (nearly touching) flat the the baffle with the farest edge liften off the baffle a cm or so- (a piece of blu tack helps)- whats that sound like on voices?

[ralphmalph]

I own one and I bought it after auditioning a few processors at the time and it replaced a TAG AV32r in my rack.

one thing that has puzzled me is that the jitter figures given are for SPDIF and HDMI and the HDMI figure is 10x the size of the SPDIF figure. So if theory the same signal from the same transport should sound noticably different when played over the HDMI connection as opposed to the SPDIF connection.

So I tried this with various sources from a Skybox, a MB200 media player and PS3. In every case to my ears the AP sounds better with the HDMI signal. Of course I could not test HD signals.

I am starting to think that there is something that has not been explained or understood about jitter and HDMI.

[eaglemmoomin]

Originally Posted by ralphmalph

I own one and I bought it after auditioning a few processors at the time and it replaced a TAG AV32r in my rack.

one thing that has puzzled me is that the jitter figures given are for SPDIF and HDMI and the HDMI figure is 10x the size of the SPDIF figure. So if theory the same signal from the same transport should sound noticably different when played over the HDMI connection as opposed to the SPDIF connection.

So I tried this with various sources from a Skybox, a MB200 media player and PS3. In every case to my ears the AP sounds better with the HDMI signal. Of course I could not test HD signals.

I am starting to think that there is something that has not been explained or understood about jitter and HDMI.

I personally think its dependent on the band width of the frequency that any jitter might occur in. If its in a range thats imperceptable especially with lots of other frequencies layered on top of it then I don't think its anything to worry about. Its like being concerned that the Sun will explode its gonna happen but its on a scale that you can't experience. I also don't thing jitter is the big bad bogey man that its made out to be either. Not after a certain point. In the early days of transister electronics and older board manufacturing processes I could see how it could happen but this technology has been around for decades now and has been refined. I'd love to see an AVforums back to back double blind test of some of the worst and best jitter offenders, just to settle this matter and get some empirical proof.

[lbstyling]

i would be surprised if the unit wasnt optimised for use with the hdmi- so because of this -its likely that the other factors in sound reproduction (thd+n, s/n, IM) have been catered for better through the hdmi signal path.
- i do wish to add that im in no way suggesting that just because the 8000ap has higher jitter figures, that it doesnt sound quite possibly better than anything currently available -regardless of price.

i suppose to put it in context, the majority of my experence is in stereo reproduction- and ive never heard a stereo system that i would say has a top class sound that didnt have a low jitter source.

-but then ive never heard a surround system that sounded even close to the quality thats possible in stereo.

but i have heard many stereo systems without pll's and special transports that sound better than the best surround system ive ever heard.

so i would presume from this that (as i said above) its more than likely that the current best processor in the world could have a high jitter digital system- if its improved the common drawbacks of its format.

ive done several 'experiments' over the past couple of years-

ive mounted reciever transformers externaly, changed power supplies, changed capacitors, sheilded power supplies, sheilded channels from each other......

the only thing ive been able to do so far that gave me even a taste of somthing truly 'special' through surround was to run mono amplifiers -reducing crosstalk, noise floor and most importantly the the biggest problem with hifi in general- IM distortion caused by back emf from each driver in a speaker affecting others in the speaker- particularly the bass driver)

[Welwynnick]

Originally Posted by Nic Miller

Have heard a lot of discussion about the 800AP and it's huge jitter readings and this is putting people off buying it, but what about people who actually own it or have heard one - is this actually an audible problem or just a meaningless statistic? I am not interested in the fact that it has high jitter or not, what I am interested in is whether this makes a difference to the sound! Obviously at some point I will have to let my own ears decide, but what do you guys think?

Audio processors and jitter? OK, you asked for it... Jitter is responsible for making digital audio sound artificial. The "sound" is still all there, dynamic and frequency ranges etc, but it's clearly not the real thing. Jitter has many different manifestations, because it has many different charateristics itself. It's not just a simple, single attribute. It's a function of amplitude and frequency, and different equipment has different characteristics, or colours if you like. They impose their own fingerprint on the sound, even when the frequency response appears flat. Jitter is variation in timing in digital audio, and this manifests itself as something that looks like phase noise, once the analogue audio pops out the other side of the DACs.

The subjective effect is simply to "defocus" everything. Removing jitter is not so much like lifting a veil, as removing frosted glass. Without jitter, even CDs can sound wonderful, with seemingly unlimited dynamic range and stereo to die for. The information that is captured on good recordings beggars belief, and I sometimes think a good soundtrack gives a better illusion of "being there" than video itself. Imaging can be at the same time enormous in scale, pin-point precise in detail, and completely detached from the speakers. There is precision, but the big picture can be better, too. As well as hearing each instrument or voice more clearly, either in isolation or when burried under many other layers, you also appreciate how they were supposed to interact. You hear everything, but not like the reproduction is disecting the recording - it manages to put it back together properly, so the interplay is preserved. Music can be relaxed and fast-paced at the same time, such that it makes you want to listen more and more. With jitter addd to the mix, you just think, yeah - so what - lets go and do something else.

I've been banging about this for ages, so I hope that helps to explain why I think jitter is so important. I've been chasing it's causes, effects and solutions for years, and think I have a good handle on it now. There's a simple way to consider the causes of jitter that may be very relevant to the discussion on TrueHD etc.

Digital audio consists of two information streams, not one. There is amplitude information, represented by the digital pulse codes, and the timing information, which is the carrier of the jitter. Timing info is also analogue, not digital, and so-called digital audio is really a hybrid. Both digital amplitude info and analogue timing info have to be carried without corruption to preserve fidelity. Amplitude info usually IS, and timing info usually ISN'T. Timing info is usually generated by the master clock in the transport, which is a disaster. It should be generated in the DAC or amp, and fed BACK to the transport (as in the very best systems), rather than the other way round.

I-Link, PQLS, HATS and Denon Link help to resolve this problem. They don't carry timing info from the transport to the amp; just amplitude info. Hence they don't carry any jitter. NONE. That's a big concept to grasp. Jitter exists downstream of the master clock, wherever that is; even if it's in a different box to the transport. An I-Link source is not a synchronous transport. The timing info is generated in the amp, and rate control info is fed back to the transport to control it's own clock. You then have the preferred DAC master configuration, where the amp or DAC has the master clock. This doesn't eliminate jitter - you can never do that, but it stops it getting worse in the link from the player, and spdif and hdmi links are both bad at this.

I believe that TrueHD over HDMI also does this. Since TrueHD is compressed, it cannot carry real-time timing info when it is read off the disc and output over bitstream. That timing info is only created when the digital audio stream is de-compressed into a real-time stream in the amp. At least, I hope so. It could be that the audio timing info is actually carried in the video clock in the HDMI link from the the player. In which case we are doomed! But I'm not sure. If that's not the case, then the timing info will come from the master clock in the amp, and all will be lightness and joy. Of course, good implementation in the amps will be essential - use a bad clock and that will wipe out all the potential gains.

By the way, PCM over HDMI is generally full of jitter because it doesn't support a DAC master configuration, and it doesn't have an audio clock line that is separate to both the video clock and the data lines. (If you have a separate audio clock line you can still have a transport master configuration that worls well, because the timing info is preserved correctly.)

Thanks for your perseverence and best regards,

Nick

[ralphmalph]

So we send a compressed audio soundtrack like DD or TrueHD, it is buffered in the processor then de compressed including the timing and then processed.

If you buffer the compressed digital stream before decompressing why does the jitter matter.

As you state "Jitter is a difference in the digital timing" does not matter if you buffer the digital stream. You buffer it decomepress and recreate the digital timing in the processor so there is no jitter in the final decompressed stream.

Think computer networking it gets sent all oober the place arrives at different times but because it is buffered it is recreated as it was sent meaning you get 100% of the data that was sent.

[Mark.Yudkin]

I believe that TrueHD over HDMI also does this. Since TrueHD is compressed, it cannot carry real-time timing info when it is read off the disc and output over bitstream. That timing info is only created when the digital audio stream is de-compressed into a real-time stream in the amp. At least, I hope so. It could be that the audio timing info is actually carried in the video clock in the HDMI link from the the player. In which case we are doomed! But I'm not sure. If that's not the case, then the timing info will come from the master clock in the amp, and all will be lightness and joy. Of course, good implementation in the amps will be essential - use a bad clock and that will wipe out all the potential gains.

Your belief is incorrect, your "since" does not imply the consequences you so ardently desire, and your hopes misplaced. The "could be" is in fact closer to the reality of the HDMI 1.3 specification. In fact there is no audio clock, but it is compeletely defined by the TDMS clock which corresponds to the video pixel rate. The audio clock must be regenerated and the definitional source of that regeneration is the TDMS clock (of course, no implementation is defined).

There appears to be a common misconception that the audio clock is functionally dependent on whether the audio stream is LPCM or IEC 61937 compressed audio. The HDMI 1.3 specification categorically states the opposite.

The details are given in chapter 7 of the HDMI 1.3 Specification.

[Welwynnick]

Originally Posted by ralphmalph

So we send a compressed audio soundtrack like DD or TrueHD, it is buffered in the processor then de compressed including the timing and then processed.

If you buffer the compressed digital stream before decompressing why does the jitter matter.

As you state "Jitter is a difference in the digital timing" does not matter if you buffer the digital stream. You buffer it decomepress and recreate the digital timing in the processor so there is no jitter in the final decompressed stream.

Think computer networking it gets sent all oober the place arrives at different times but because it is buffered it is recreated as it was sent meaning you get 100% of the data that was sent.

If I understand the reasoning correctly, it doesn’t work like that, despite the many marketing men who would like everyone to believe it. DACs and processors DO have buffering, but results very and its never a complete solution. You can never eliminate jitter with buffering, just try to reduce it as much as possible, and hopefully not make it any worse. The common problem is that people usually think in terms of the data when considering jitter, whereas jitter is only an artifact of the timing information, which is a separate information stream to the data (amplitude info).

Buffering does not apply a process to the data so much as process the clock. Its effectively a low-pass filter that reduces the magnitude of the high-frequency jitter, but lets through low-frequency jitter. Re-clocking technology generally concentrates on getting the filter corner frequency as low as possible, but this tends to conflict with the need to quickly and reliably achieve and maintain a receiver lock on the incoming data stream, which needs a quick and dynamic PLL – otherwise you get drop-outs. The better PLL solutions use more than one PLL with staggered roll-offs – higher-frequency first for good lock acquisition performance, then a lower-frequency filter to remove more jitter. Ultimately though, you can’t remove all the jitter as the clock itself would never get through, and as long as the master clock is (conventionally) in the transport, it still has to make its way forwards to the DAC, wherever that is.

Decoding DD or DTS MA is a different matter, as the clock is not created in the player – it is generated in the DAC or processor itself, and doesn’t have to survive a tortuous connection by spdif or HDMI at all. The audio clock is co-located with the audio DAC, which is ideal, and isn’t corrupted by multiplexing with audio data or video clock. There IS buffering of the data, but its not like re-clocking, as the data is controlled by flow-control, not phase-control. The timing info travels backwards from DAC to transport, rather than forwards through the buffer. I don’t believe that it has to be done this way, there don’t seem to be any regulations or standards that impose this, but to the best of my knowledge this is how most manufacturers implement it, and I don’t know of any exceptions.

Regards, Nick

[Welwynnick]

Originally Posted by Mark.Yudkin

Your belief is incorrect, your "since" does not imply the consequences you so ardently desire, and your hopes misplaced. The "could be" is in fact closer to the reality of the HDMI 1.3 specification. In fact there is no audio clock, but it is compeletely defined by the TDMS clock which corresponds to the video pixel rate. The audio clock must be regenerated and the definitional source of that regeneration is the TDMS clock (of course, no implementation is defined).

There appears to be a common misconception that the audio clock is functionally dependent on whether the audio stream is LPCM or IEC 61937 compressed audio. The HDMI 1.3 specification categorically states the opposite.

The details are given in chapter 7 of the HDMI 1.3 Specification.

No, I believe that I am correct, because while processor manufacturers are presumably at complete liberty to implement one of the recommended HDMI schemes to regenerate the audio clock by decimation of the video clock from the player, there is no evidence to show that they chose to do so, even though player manufacturers are obliged to support their side of the clock recovery protocol between player and processor/amp.

Nick

[Avi]

Originally Posted by welwynnick

No, I believe that I am correct, because while processor manufacturers are presumably at complete liberty to implement one of the recommended HDMI schemes to regenerate the audio clock by decimation of the video clock from the player, there is no evidence to show that they chose to do so, even though player manufacturers are obliged to support their side of the clock recovery protocol between player and processor/amp.

Nick

It would be interesting to have some definitive answers on this from people with real expertise in this field rather than the constant debate based on limited objective info and few general facts or evidence either way.

AVI

[eaglemmoomin]

Originally Posted by Avi

It would be interesting to have some definitive answers on this from people with real expertise in this field rather than the constant debate based on limited objective info and few general facts or evidence either way.

AVI

[NaTT]

absalutely
this not knowing is ruining my movie watching experience

[Nic Rhodes]

I tried an 8000 and it wasn't for me. I believe processors are capable of much more as well as the limitation the unit I tried had with firmware and lack of facilities like HDMI / decoding. The form factor is great however. I think the unit would have sold very well with HD decoding on board. Without it......well it is 2 years old now and hasn't sold in huge numbers.

[lbstyling]

Originally Posted by welwynnick

If I understand the reasoning correctly, it doesn’t work like that, despite the many marketing men who would like everyone to believe it. DACs and processors DO have buffering, but results very and its never a complete solution. You can never eliminate jitter with buffering, just try to reduce it as much as possible, and hopefully not make it any worse. The common problem is that people usually think in terms of the data when considering jitter, whereas jitter is only an artifact of the timing information, which is a separate information stream to the data (amplitude info).

Buffering does not apply a process to the data so much as process the clock. Its effectively a low-pass filter that reduces the magnitude of the high-frequency jitter, but lets through low-frequency jitter. Re-clocking technology generally concentrates on getting the filter corner frequency as low as possible, but this tends to conflict with the need to quickly and reliably achieve and maintain a receiver lock on the incoming data stream, which needs a quick and dynamic PLL – otherwise you get drop-outs. The better PLL solutions use more than one PLL with staggered roll-offs – higher-frequency first for good lock acquisition performance, then a lower-frequency filter to remove more jitter. Ultimately though, you can’t remove all the jitter as the clock itself would never get through, and as long as the master clock is (conventionally) in the transport, it still has to make its way forwards to the DAC, wherever that is.

Decoding DD or DTS MA is a different matter, as the clock is not created in the player – it is generated in the DAC or processor itself, and doesn’t have to survive a tortuous connection by spdif or HDMI at all. The audio clock is co-located with the audio DAC, which is ideal, and isn’t corrupted by multiplexing with audio data or video clock. There IS buffering of the data, but its not like re-clocking, as the data is controlled by flow-control, not phase-control. The timing info travels backwards from DAC to transport, rather than forwards through the buffer. I don’t believe that it has to be done this way, there don’t seem to be any regulations or standards that impose this, but to the best of my knowledge this is how most manufacturers implement it, and I don’t know of any exceptions.

Regards, Nick

long story shortened/laymans terms- bitstream=. pcm=

your information here agrees with my findings- to you get a thumbs up from me.

the question is now though- assuming bitstream is the best choice, does the independantly measured jitter levels for processors matter much if bitstream is used??
making the special measures used by pioneer and classe ect, rather limited in real improvement.

- i was under the impression that they measure jitter between the player and processor.
and with the hdmi interface jitter (and presumably the transport input)issue removed- how much is left??

does this then make upgrading the clock+digital power supply worth it?

[JohnWH]

Recommended reading...

Stereophile: The Jitter Game

John.

[Avi]

Originally Posted by JohnWH

Recommended reading...

Stereophile: The Jitter Game

John.

Also "On Jitter, the S/PDIF Standard, and Audio DACs

Note the above relates to SPDIF not HDMI.

AVI

[Avi]

Originally Posted by JohnWH

Recommended reading...

Stereophile: The Jitter Game

John.

Thanks.

How does this relate to the way HDMI functions with regard to audio data/audio clock ?

"Where does clock jitter originate? The primary source is the interface between a CD transport and a digital processor. The S/PDIF (Sony/Philips Digital Interface Format) signal that connects the two has the master clock signal embedded in it (it is more accurate to say the audio data are embedded in the clock). The digital processor recovers this clock signal at the input receiver chip (usually the Yamaha YM3623B, Philips SAA7274, or the new Crystal CS8412).

The typical method of separating the clock from the data and creating a new clock with a phase-locked loop (PLL) produces lots of jitter. In a standard implementation, the Yamaha chip produces a clock with 3-5 nanoseconds of jitter, about 30 to 50 times the 100ps requirement for accurate 16-bit conversion (the new Crystal CS8412 input receiver in its "C" incarnation reportedly has 150ps of clock jitter). Even if the clock is recovered with low jitter, just about everything inside a digital processor introduces clock jitter: noise from digital circuitry, processing by integrated circuits—even the inductance and capacitance of a printed circuit board trace will lead to jitter.

It's important to note that the only point where jitter matters is at the DAC's word-clock input. A clock that is recovered perfectly and degraded before it gets to the DAC is no better than a high-jitter recovery circuit that is protected from additional jitter on its way to the DAC. Conversely, a highly jittered clock can be cleaned up just before the DAC with no penalty (footnote 3). "

AVI

[Mark.Yudkin]

It would be interesting to have some definitive answers on this from people with real expertise in this field rather than the constant debate based on limited objective info and few general facts or evidence either way.

For this reason, I hyperlinked to the definitive source with definitive answers from those responsible - there are no more accurate sources than the original specification, by definition. If you choose not to believe the master source, that's a different issue, but it's one that's unrelated to the veracity and expertise of the formal specification.

while processor manufacturers are presumably at complete liberty to implement one of the recommended HDMI schemes to regenerate the audio clock by decimation of the video clock from the player ...

The specification does not define any mandatory technique for the decimation of the video clock to regenerate an audio clock. It's a specification and a specification is a definition, not a prescription. It defines how the audio clock is related to the TDMS clock (section 7.2).

I wonder where the erroneous assumption that bitstream has inhererently less jitter than LPCM arose, given that the specification categorically refutes it? Implementations are another issue - a manufacturer is of course at liberty to provide multiple implements with the aim of obtaining differing performance characteristics, which of couse can just as easily mean that LPCM has less jitter than IEC 61937 compressed audio. However, there is no compulsion to do so, nor does it really make much sense for a manfacturer to expend the effort.

[Welwynnick]

Originally Posted by Avi

How does this relate to the way HDMI functions with regard to audio data/audio clock ?

This is the beginning of what I think about HDMI and jitter, but its really a moveable feast, and I don't think we're being adequately served by the media. There are lots of different elements to the end result, and these aren't being captured. It seems to be enough for some people to ascribe a single number to jitter, but thats not enough for an adequate understanding.

There's a fundamental difference in the way that spdif and HDMI handle digital audio, and unfortunately it seems to cause more of a problem with HDMI. Most audio systems screw up digital audio in one way or another, but HDMI adds a new way to do it - plus a possible way out. Digital audio carries not one, but two, information streams - amplitude information and timing information. The amplitude info is the data in the ones and zeros, and the timing info is the synchronisation between the sampling (ADC) and the reconstruction (DAC) of the analogue output stream.

SPDIF carries both streams on the same channel - the timing info is embedded into the data stream, which are recovered and separated by the receiver for sending to the DACs. Sources and sinks have gotten better over the years, but as you might expect, this is a compromise, and the data tends to corrupt the timing.

HDMI does it quite differently, and carries data (amplitude info) and clock (timing info) on physically separate channels. Although the audio data is embedded into the video data on HDMI, this is still a good thing in principle, as it should help to maintain the integrity of the clock. Unfortunately (and this is why audiophile manufacturers criticise audio on HDMI) the HDMI clock is a video clock, not an audio clock. The receiver has to reconstruct an audio clock out of the video clock by down-sampling it internally under continuously varying decimation commands sent over the CEC by the transport. This DOES work (well... function) but nothing like as well as a dedicated audio clock.

Hence the problem with HDMI audio, and it is a real problem, nomatter what some manufacturers may say. Its not a simple matter though. HDMI seems to perform much worse when there is no video being carried. Playing a CD over an HDMI connection can be very poor, and spdif can sound significantly better. The difference can only be attributed to jitter on HDMI - either because of the link, or because of the receiver processing. LPCM with video on HDMI seems to be a different matter though, and can sound very good. I have a good understanding of the causes and effects of jitter, but things start to get difficult here. I think that audio jitter may be related to the video clock that is used for each signal transmission format. HDMI has a very wide range of transmission formats, which have to cover everything from NTSC to 1200p video. There is a correspondingly very wide range of video clock frequencies to cover these, and some of them don't seem to work well with audio.

Nick

[Welwynnick]

Also "On Jitter, the S/PDIF Standard, and Audio DACs
Note the above relates to SPDIF not HDMI.
AVI

Thanks, that's one of the best discussions on jitter that I've read.

Originally Posted by JohnWH

Recommended reading...
Stereophile: The Jitter Game
John.

For the record, Stereophile is full of interesting articles in its Reference and Features sections. Here are a few more:

Stereophile: A Case of the Jitters
Stereophile: CD: Jitter, Errors & Magic
Stereophile: Jitter, Bits, & Sound Quality
Stereophile: A Transport of Delight: CD Transport Jitter
http://www.www.stereophile.com/reference/1093jitter
Stereophile: Bits is Bits?

And here is one of the best from TNT Audio:

Digital Interfaces - An Introduction - Part 1.1 [English]

These generally relate to SPDIF rather than HDMI, though I think some of the principles do cross over. An interesting output of this is that jitter is reduced with a high-bandwidth spdif connection such as glass toslink. HDMI audio is an altogether more prickly rose, and I don't think anyone has really gotten hold of it. I'm sure the better manufacturers know what they're doing, but the HDMI spec doesn't help and there's really not much proper understanding in the public domain, and I doubt that's an accident.

Nick

[JohnWH]

Originally Posted by Avi

Also "On Jitter, the S/PDIF Standard, and Audio DACs

Note the above relates to SPDIF not HDMI.

AVI

I know these articals relate to jitter on spdif, however the articals go a little way to explaining what jitter actually means to SQ, which is what the op was asking....

John.

[Avi]

Originally Posted by JohnWH

I know these articals relate to jitter on spdif, however the articals go a little way to explaining what jitter actually means to SQ, which is what the op was asking....

John.

I wasn't suggesting you didn't just that the article I included in my link was based on SPDIF not HDMI.

AVI

[JohnWH]

Originally Posted by Mark.Yudkin

For this reason, I hyperlinked to the definitive source with definitive answers from those responsible - there are no more accurate sources than the original specification, by definition. If you choose not to believe the master source, that's a different issue, but it's one that's unrelated to the veracity and expertise of the formal specification.


The specification does not define any mandatory technique for the decimation of the video clock to regenerate an audio clock. It's a specification and a specification is a definition, not a prescription. It defines how the audio clock is related to the TDMS clock (section 7.2).

I wonder where the erroneous assumption that bitstream has inhererently less jitter than LPCM arose, given that the specification categorically refutes it? Implementations are another issue - a manufacturer is of course at liberty to provide multiple implements with the aim of obtaining differing performance characteristics, which of couse can just as easily mean that LPCM has less jitter than IEC 61937 compressed audio. However, there is no compulsion to do so, nor does it really make much sense for a manfacturer to expend the effort.

Mark, there is a subtle difference between LPCM and compressed audio, specifically that the recovered clock repreasents the audio frame rate not the sample rate. Admittedly the audio sample rate can be directly derived from this clock however it does imply that additional processing is required.

John.

[Nic Miller]

I'm almost certain my original question was whether users of the audiolab could detect any jitter as evidenced by 'does it sound good' rather than a general discussion of the causes of jitter etc etc all of which is irrelevant. If x sounds better than y it doesn't matter if x has a jitter of 6,789,643 and y has a jitter of 2.

Peole seem to be worrying about jitter purely because we have a name for it and can measure something. If we could measure other things like noise from various other components or something and gave that a name peole would rant on about that. What happened to using ones ears and decided what is best?

Even if jitter is bad and can affect sound, just because a bad sounding amp has a high jitter doesn't indicate this is the cause due to all the other variables and other sources of errors. The quality of an amp is an amalgamation of all the errors and the impact on sound quality surely? Who cares about one factor on it's own? Amp x may have low jitter but high something else, but people seem so fixated with jitter at the expense of the big picture - how does it sound.......

My thoughts anyway

[Nic Rhodes]

Originally Posted by Nic Miller

What happened to using ones ears and decided what is best?

I thought that is what I did

[Welwynnick]

Sorry about that. You're quite right, its the end result that matters, not the reason for the result.

However, I was very slowly coming round to a point about the Audiolab which I think is useful, so I'll cut to the chase. I also have a processor that is also susceptible to jitter, but I found a few clear conclusions.

• Bitstream audio on HDMI generally sounds the same.
• Its LPCM audio on HDMI that is susceptible to jitter.
• LPCM audio from CD is more susceptible to jitter than LPCM audio from blu-ray.
• Jitter measurements are often taken with a CD source.
• The 8000AP can use spdif for CD sources, which has lower jitter.
• The Audiolab has poor jitter, but this may simply indicate a susceptibility to high-jitter sources.
• With LPCM audio, the processor SQ reflects the quality of the source, even over HDMI.
• The Audiolab may have good SQ if you use a good player.

So what to do about it?

1. Use SPDIF when playing CDs, even if you're using a BD player.
2. Use a good BD player, such as the high-end Sony, Denon, marantz or Pioneer models.

BR, Nick

[lbstyling]

nicks comment sounds logical, but even the better players are likely to produce high jitter levels- many realy top end cd players produce over 200ps of jitter and in my experience the dcs's and cambridge audio's of this world blow most of them out of the water when you listen to them. and funny enough-they happen to have put a huge amount of work in to get very low jitter.

now -were looking at a tested processor here with 8000ps!

in this area this is a big step back- a VERY big step back.

a poor cd player jitter level is around 600ps.

ive never heard a cd player that sounded good to me-that didnt have a low jitter system in place.

you can see my problem

- im frustrated with the industry on this point- and im personaly tempted to buy a pioneer lx71 (or 51 if it also has the jitter re-clocking tech) reciever to use as a processor -instead of the dedicated processors on offer-even with its likely high noise floor ect.

if i got a audiolab-i appreciate he noise floor is low -and the analogue circuitry sounds well designed.
but the first thing i would be listening to is large scale orchestra and complicated rock music to see is the instruments are separating and the spacial info is there- if the jitter problems show themselves in the same way cd does, it wont be.


i would still like to have it comfirmed if the figures given for bitstream jitter are relevent, as the test is done at the hdmi interface- but its clocked/buffered after.

[JohnWH]

Originally Posted by Nic Miller

I'm almost certain my original question was whether users of the audiolab could detect any jitter as evidenced by 'does it sound good' rather than a general discussion of the causes of jitter etc etc all of which is irrelevant. If x sounds better than y it doesn't matter if x has a jitter of 6,789,643 and y has a jitter of 2.

Peole seem to be worrying about jitter purely because we have a name for it and can measure something. If we could measure other things like noise from various other components or something and gave that a name peole would rant on about that. What happened to using ones ears and decided what is best?

Even if jitter is bad and can affect sound, just because a bad sounding amp has a high jitter doesn't indicate this is the cause due to all the other variables and other sources of errors. The quality of an amp is an amalgamation of all the errors and the impact on sound quality surely? Who cares about one factor on it's own? Amp x may have low jitter but high something else, but people seem so fixated with jitter at the expense of the big picture - how does it sound.......

My thoughts anyway

You're quite right that it's overall SQ that matters and that it is wrong to get hung up on one thing.

The reality is that I doubt if 90% of people could tell he deifference between good vs bad jitter performance even with all else being equal due to masking effects.

>'What happened to using ones ears and deciding what is best'
Nothing, however there is also nothing wrong with having a good set of technical measurements help you form a short list of what is worth listening to. This is particularly important if you can't get a home demo of kit.

John.