Jitter? Non Issue or have we just given in?

[CopperTop]

That's not the same thing as perfectly matching the source clock rate, however.

... nor "eliminating" jitter.

 

[ThorstenL]

Hi,

Could you explain how that works?

I did, above.

There will always be a mismatch between source and playback sample rate and the Big Idea seems to be to estimate and set the playback frequency as accurately as possible so that adjustments are not necessary, possibly for several minutes. That's not the same thing as perfectly matching the source clock rate, however.

I agree, it is not the same as matching the two IF you make a sufficiently long measurement, several minutes, HOWEVER, as remarked, the smallest step is merely a few pS equivalent time step (or jitter) and it happens very infrequently, so we are talking at worst about a few pS Jitter from the flowrate control with a frequency well under 0.01Hz.

In absolute terms it is not the same as an absolute perfect match, however it is a match to such small difference that it becomes hard to measure accurately using conventional instrumentation (we have to reverse infer it from the time taken between two clock change events).

Ciao T

 

[ThorstenL]

Hi,

... nor "eliminating" jitter.

Which was never claimed, incidentally. What was claimed was eliminating source jitter.

The flow control will add cyclic jitter of a few pS Peak-Peak with a frequency of a less than 10milliHertz, care to calculate the jitter this actually produces for a given measurement set?

So again, we have not eliminated all jitter (moreover, we cannot eliminate that which is added after the clock by reclocking IC's and the DAC IC itself), but we have eliminated source jitter. Minimising internal jitter is a job for the designer.

Ciao T

 

[CopperTop]

I did, above.

Obviously not quite (see below!).

I agree, it is not the same as matching the two IF you make a sufficiently long measurement, several minutes, HOWEVER, as remarked, the smallest step is merely a few pS equivalent time step (or jitter) and it happens very infrequently, so we are talking at worst about a few pS Jitter from the flowrate control with a frequency well under 0.01Hz.

In absolute terms it is not the same as an absolute perfect match, however it is a match to such small difference that it becomes hard to measure accurately using conventional instrumentation (we have to reverse infer it from the time taken between two clock change events).

I think my "paradoxical" point still stands. Paradoxical because the idea of the 'audiophile' outboard DAC was to get away from the supposedly terrible sound-mutilating effects of housing the DAC in the same box as the CD transport, yet resulted in the problem described above.

And the truth is that you can't eliminate jitter and perfectly match the playback and source clock rates, just as I said. You can get so close it doesn't matter, but the designers of the $2 PCM2702 could also claim the same thing. It's just a question of how far you want to take it. Surely, Thorsten, you don't really think you can hear the difference between a device that changes its playback rate by a tiny fraction every 10 seconds compared to one that does it by a slightly tinier fraction every minute. Its only benefit is a theoretical one, and it's a lovely engineering challenge whose appeal I can see perfectly. But if you're in the business of theoretical perfection then the only way to do it for real is to build a closed system with the source slaved to the DAC's clock.

While we're discussing it, I'm extremely interested in the claims in the ESS DAC literature about their "Time Domain Jitter Eliminator" whereby the audio stream is resampled at some arbitrary higher clock frequency, and samples across transitions are inferred using linear interpolation.

ESS Products - DAC

Here's the patent:

espacenet - Bibliographic data

My first reaction was that this can't be jitter elimination, but is the implication that the errors it produces are so small that they are much less than a LSB at 24 bits..? I was assuming that they were then somehow downsampling back to 44.1 kHz or whatever, but I think they are feeding the high frequency sample stream directly into their DAC (if that is a genuine distinction?). Have they discovered the holy grail? (If, indeed, I understand what the system is trying to achieve...)

 

[abraxalito]

samples across transitions are inferred using linear interpolation.

Are they really doing linear interpolation? If they are that's guaranteed distortion being introduced because linear interpolation violates Nyquist. Nyquist only allows us to 'join up' the samples with fully bandlimited signals.

 

[jkeny]

Here's something Dustin mentions about it but it doesn't explain anything about how it's done:

http://www.diyaudio.com/forums/digi...e-reference-dac-8-channel-50.html#post1490639

"disable jitter rejection" will simply shut the correction engine off and therefore should ONLY ever be used with a synchronous (phase aligned, not just the same frequency derived from another source) mclk. So basically, it will revert to the same way every other DAC out there does it if you don't like the asynchronous way Martin/I proposed. If you still want to try the Sabre but already feel you have a extremely well done transport with low phase noise clock then this option might be for you. I would be very interested to see someone do this and compare the sound. ie, compare the sound of

1. Sabre in synchronous mode, with very high end transport with low jitter mclk.

2. Crappy transport full of jitter, then let the Sabre do its thing.


From a mathematical point of view, the Sabre will start to attenuate the jitter at around 0.1Hz or so, so I would like to see this comparison done.


Thanks

Dustin

 

[CopperTop]

Are they really doing linear interpolation? If they are that's guaranteed distortion being introduced because linear interpolation violates Nyquist. Nyquist only allows us to 'join up' the samples with fully bandlimited signals.

That's what I thought, but the patent seems to describe a mechanism for linear interpolation.

At first I thought they were slightly refining the (bonkers?) idea of duplicating or omitting samples when playing back at a slightly different frequency from the source, but I'm no longer so arrogant as to think I understand it!

This may mean something to somebody:

From http://www.esstech.com/PDF/sabrewp.pdf

Rather than trying to lock a PLL to the data rate of this
interface signal, the Sabre DSP uses the arrival time of the
data as a gating signal for the first part of the processing.
Specifically, we now need to apply a filter to the digital data –
we must remove the image that will be created when we up-
sample the data to our much higher clock rate. This filter
involves a number of cycles of the DSP. One desirable
consequence of this method is that the over-sampling filter
time constant tracks the data rate. The data we have after this
process is, of course, mathematically correct, but if we use this
data in the higher clock domain we will have a great deal of
noise, since as soon as we try to sample the data we must
decide at which edge of our high speed clock this data is to be
used. That choice is never correct – this sample delivered from
the interface is supposed to be at some point between our high
speed clock edges. The problem then is this: we have the data
stripped off the transport medium – the data is mathematically
correct but we don’t know where in time this data is supposed
to be, and even if we did we cannot snap it to our high speed
clock because that represents a quantization in time and hence
noise. The conventional solution is well known: first a digital
PLL is used to remove the jitter of the incoming data (since it
will suffer from jitter in the transport clock) and then a poly-
phase filter is employed to rate-convert the signal8 into the
new clock domain. These kinds of sample rate converters
work well but they are limited to certain ranges of operation
(they have a limited ratio of rate conversion – typically about
8:1) and a DNR less than that in the digital data itself. The
Sabre DAC rate converter has two advantages compared to the
poly-phase filter approach and is described in great detail in
the pending patent. Firstly the rate conversion is unlimited –
allowing the Sabre to always achieve a conversion into its
exceptionally high clock rate (as much as 40Mhz) from as
little as 4Khz in one step; and secondly, the process is
essentially perfect to the bit level – the output DNR exceeds
175dB and the THD is correspondingly high.
As well as sample rate conversion the Sabre has a
proprietary jitter reduction circuit that operates with the rate
converter and is able to achieve a 100% jitter rejection. These
two steps: jitter rejection and rate conversion; are able to take
the “burst” mode over-sampled filter output into the precisely
correct clock edge of the high speed clock. Audio data from
all sources is now in the high speed clock domain and sent to
the modulator.

 

[abraxalito]

This may mean something to somebody

Same old impenetrable gobbledygook which nobody came up to explain when I asked about the marketing blurb on the Anedio website. Any takers this time around?😀 If they are really doing linear interpolation and the sample rate's 40MHz then perhaps the aliasing does turn out to be below the 24th bit but I couldn't be sure.

Dare I ask - is the patent any clearer?

 

[jez]

Hope this isn't getting too off topic but what about internal PCI soundcards such as the Audiophile 2496? Would they still be prone to the same jitter problems as USB DAC's?
Obviously there is the extra problems in the form of a noisy electrical environment etc for the internal card.... but does the way it receives data sans a USB link and via a shorter path still give it a better chance of doing the job right than an external USB box?

 

[CopperTop]

Dare I ask - is the patent any clearer?

The patent I have been looking at seems to be for a mechanism to efficiently perform the interpolation, rather than an explanation for the 'holistic concept'. Even then, I'm not sure I understand it all.

In the product description below, a conventional PLL-based system is used to reduce jitter to about 50ps. It then describes re-sampling it to a high clock rate as per the ESS patent using interpolation as necessary:

Anedio Affordable High-End Audio : Multi-stage jitter reduction circuits that virtually eliminate jitter in the DAC output

At first glance, the 50ps jitter has been re-sampled as well. How does the final stage achieve jitter reduction? Intuitively, re-sampling a sampled waveform at 80MHz introduces a jitter error itself? Linear interpolation greatly reduces the size of that error I would guess. But you would imagine that the original 50ps of jitter is still there in addition to this new jitter.

However, ESS themselves don't mention a PLL-based jitter reduction stage in their DAC sales brochure, but suggest that the DAC just removes jitter itself. The blurb says "Time Domain Jitter Eliminator" and the block diagram shows "Jitter Reduction". The diagram does show an "Oversampling filter" prior to the Jitter Reduction block which suggests that the samples are being changed prior to the resampler? (The ESS document I linked to earlier also mentions a filter that tracks the data rate).

...we now need to apply a filter to the digital data –
we must remove the image that will be created when we up-
sample the data to our much higher clock rate. This filter
involves a number of cycles of the DSP. One desirable
consequence of this method is that the over-sampling filter
time constant tracks the data rate. The data we have after this
process is, of course, mathematically correct, but if we use this
data in the higher clock domain we will have a great deal of
noise, since as soon as we try to sample the data we must
decide at which edge of our high speed clock this data is to be
used.

So maybe the PLL-based stage is not strictly necessary?

Reading about them, ESS are serious players aren't they? When they say this system achieves 100% jitter removal they must mean it, surely. Maybe the "oversampling filter" in conjunction with the resampler does, indeed, achieve perfect resampling of any incoming data stream and jitter removal.

 

[ThorstenL]

Hi,

Hope this isn't getting too off topic but what about internal PCI soundcards such as the Audiophile 2496? Would they still be prone to the same jitter problems as USB DAC's?

Possibly much worse. PC PSU's are very noisy (any decent 'scope will attest) and this is what powers the Soundcard. USB devices MAY at least be self powered...

Obviously there is the extra problems in the form of a noisy electrical environment etc for the internal card.... but does the way it receives data sans a USB link and via a shorter path still give it a better chance of doing the job right than an external USB box?

If we use an "asynchronous" USB Box and an internal card with it's own on board clock, in the end, the cleaner the clock the cleaner the output. The powersupplies in PC's, wait, I already said that above....

Ciao T

 

[ThorstenL]

Hi,

I think my "paradoxical" point still stands. Paradoxical because the idea of the 'audiophile' outboard DAC was to get away from the supposedly terrible sound-mutilating effects of housing the DAC in the same box as the CD transport, yet resulted in the problem described above.

Sorry, I have no idea what you are talking about. I was behind the Iron Curtain till early 89 so I may have missed this. But the very premise of this makes zero sense, unless someone did some seriously bad design in the first place (like feeding clock, transport and dac from the same single 5V rail).

And the truth is that you can't eliminate jitter and perfectly match the playback and source clock rates, just as I said. You can get so close it doesn't matter, but the designers of the $2 PCM2702 could also claim the same thing.

Actually, their efforts where very good and if you applied a minimal amount of effort to system design they had any SPDIF chip extant at the time solidly beat. However, while no source jitter rejects plots are posted, it is not that good, unless all you need is 16/44.1.

Surely, Thorsten, you don't really think you can hear the difference between a device that changes its playback rate by a tiny fraction every 10 seconds compared to one that does it by a slightly tinier fraction every minute.

If the ratio of time/timestep is kept the same, no. Otherwise, possibly. I have found some weired s.h.i.t. causing positives in blind listening tests.

While we're discussing it, I'm extremely interested in the claims in the ESS DAC literature about their "Time Domain Jitter Eliminator" whereby the audio stream is resampled at some arbitrary higher clock frequency, and samples across transitions are inferred using linear interpolation.

It is an ASRC, based on what Dustin commented on in public (he may or may not have told the truth). FWIW, TI has several ASRC chips that can be programmed to not apply digital filtering when the ratio between input sample rate and output sample rate is at least unity (read upsampling or 1:1 resampling only).

My first reaction was that this can't be jitter elimination

Like any ASRC, it will remove jitter on the clocks (which can be still removed by re-clocking) and instead embeds the jitter in the signal, attenuated by a degree that depends on the design and representing a trade-off between silicone complexity, ASRC Algorithm and other lesser factors.

Ciao T

 

[SY]

Possibly much worse. PC PSU's are very noisy (any decent 'scope will attest) and this is what powers the Soundcard. USB devices MAY at least be self powered...

Indeed. Here's my PCI card's output, mounted in a cheap-and-cheerful old HP, open circuited and shorted inputs, no signal averaging, scale is dBFS. How could anyone stand that noise?

 

[ThorstenL]

Hi,

In the product description below, a conventional PLL-based system is used to reduce jitter to about 50ps.

How does it do that and at what frequency?

It then describes re-sampling it to a high clock rate as per the ESS patent using interpolation as necessary

So any remaining jitter is re-sampled into the interpolation and now forms part of the signal and shows up in a FFT.

At first glance, the 50ps jitter has been re-sampled as well. How does the final stage achieve jitter reduction? Intuitively, re-sampling a sampled waveform at 80MHz introduces a jitter error itself? Linear interpolation greatly reduces the size of that error I would guess. But you would imagine that the original 50ps of jitter is still there in addition to this new jitter.

At second or third glance the situation seems not have changed.

Let me say that I have been looking at "open loop" mechanisms for suppressing source jitter since long before AMR and up this point the only solution that actually works really well involves FIFO's with a fixed (or semi-fixed) output clock.

Reading about them, ESS are serious players aren't they?

Well, they certainly write draconian NDA's. So even if I had possibly had had such a DAC in my possession and actually measured it's jitter resistance I would not be allowed to tell you that I did have such or what it measured like.

From what people say that have not signed such an NDA it is a darn nice sounding DAC.

When they say this system achieves 100% jitter removal they must mean it, surely.

Well, certainly if they say such a thing they are saying it.

And if Tony Blair says that that Iraq possesses Weapons of Mass Destructions that are ready for delivery against the UK within 20 minutes, he is saying that.

Maybe the "oversampling filter" in conjunction with the resampler does, indeed, achieve perfect resampling of any incoming data stream and jitter removal.

Maybe it does so indeed.

As we are speculating, maybe animals of the genus sus scrofa are known for their aerobatic abilities?

I do remember Dustin saying that he developed an ASRC algorithm that was better than what is out there prior to the "Sabre" DAC, the ASCR itself was shelves, but he used it in the "Sabre" DAC.

BTW, Sabre, nice name for a DAC, if I ever get around to get my own DAC concept off the drawing board into reality, I should call it Claymore, or perhaps better Bidenhaender...

A Bidenhaender tops any Sabre I know of...

Ciao T

 

[CopperTop]

Let me say that I have been looking at "open loop" mechanisms for suppressing source jitter since long before AMR and up this point the only solution that actually works really well involves FIFO's with a fixed (or semi-fixed) output clock.

But for such stellar performance that would involve high (and variable) latency would it not? I would guess that would limit the possible applications for such a device.

 

[ThorstenL]

Hi,

Indeed. Here's my PCI card's output, mounted in a cheap-and-cheerful old HP, open circuited and shorted inputs, no signal averaging, scale is dBFS. How could anyone stand that noise?

Looks like -105dBfs noise.

Hard to be sure or precise, due to the deliberate use of a linear frequency scale (compared to the log one commonly used in audio) to visually hide it (it seems mostly LF).

So it is maybe 17.5 Bit equivalent.

Ciao T

 

[ThorstenL]

Hi,

But for such stellar performance that would involve high (and variable) latency would it not? I would guess that would limit the possible applications for such a device.

The latency is easy to work out from the period of adjustment and the minimal frequency step available.

I find most PC based systems have more latency in their software, but sure, there are limits. Clearly, such a system is not "real-time".

Ciao T

 

[SY]

So it is maybe 17.5 Bit equivalent.

Are you sure you're using the correct equations for that?

 

[ThorstenL]

Hi,

Are you sure you're using the correct equations for that?

Why don't you show a log frequency scale result so we can have a good look, instead of having to guess.

What is the output noise (unweighted) you measure on the card in microvolt?

Ciao T

 

[SY]

The equations?