Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Duardo]

Quote:

Or, if a signal coming from an AD converter is sent into the BB, and the BB is used to clean up that signal, so BB functions as a reclock generator, again it would be possible that the end result is sounding better.

That wouldn't really make a difference, would it?  Once a signal's been converted, there's not really anything you can do to "clean up" the signal, is there?  This would make the signal sound better if the clock was less jittery than the DA's clock, but it wouldn't do anything about "cleaning up" the signal coming out of the A/D.  Only way to do that would be to clock the A/D to the BB, right?

-Duardo

[Schallfeldnebel]

What I mean is as follows, and I will illustrate this with a  situation in my work.

When I am recording, my control room can be more than 300ft away from stage. I have AD converters on stage. At the end of the AES cables the jitter gets much higher. Although this is not a problem for my recorders, I usually place a Weiss Clockwork in the middle of the cable at 150ft to clean up. If I would hang a DA converter at the end of the cable at 300ft and switch the Clockwork off, it sounds worse than switched on.

If the BB can be used to clean up the signal path between AD and DA, you might think your AD is sounding better, the cause for the better sound is the DA gets a less jittery signal.

Erik Sikkema

[Max]

Duardo wrote on Tue, 09 November 2004 20:04

Quote: Or, if a signal coming from an AD converter is sent into the BB, and the BB is used to clean up that signal, so BB functions as a reclock generator, again it would be possible that the end result is sounding better. That wouldn't really make a difference, would it?  Once a signal's been converted, there's not really anything you can do to "clean up" the signal, is there?  This would make the signal sound better if the clock was less jittery than the DA's clock, but it wouldn't do anything about "cleaning up" the signal coming out of the A/D.  Only way to do that would be to clock the A/D to the BB, right? -Duardo

Correct. Once the signal has been converted, there is nothing you can do to clean up the jitter during the A/D conversion. In the above scenario where you are using a CD transport digitally out to a D/A, inserting Big Ben in the path would reduce the jitter created by the transport before it gets to the D/A, therefore making the D/A converter perform and sound better. Any artifacts due to jitter that have already been recorded during the A/D conversion is of course not being corrected by Big Ben (it's too late once it is recorded).

[Max]

Quote:

So we should not make the mistake when concluding external clocking of AD converter gives a better sound, that we clock all other equipment after the AD also directly out of the BB, because then you clean up the signal of the whole system, which can have a large effect on the DA converter, so it is the DA converter making us believe our AD sounds better. Erik Sikkema

In some cases this is true as I described above. This is also what I was referring to in my first post when I said that all things are never equal when it comes to clocking. Anyone who is using a separate D/A converter of any kind is re-clocking, for example.

On the other hand it is important to note that there are many devices nowadays such as the Digidesign 192 and Rosetta 800 for example, that have A/D and D/A in the same box. Typically, these types of units are are designed to clock from a crystal for both A/D and D/A conversion when set on internal mode. When not being clocked internally, the A/D and D/A converters switch over to the PLL. Again, the interesting thing here is is that we have experienced improvements in sound quality when units such as these are clocked externally to Big Ben.

[Schallfeldnebel]

Max wrote:

"Correct. Once the signal has been converted, there is nothing you can do to clean up the jitter during the A/D conversion. In the above scenario where you are using a CD transport digitally out to a D/A, inserting Big Ben in the path would reduce the jitter created by the transport before it gets to the D/A, therefore making the D/A converter perform and sound better. Any artifacts due to jitter that have already been recorded during the A/D conversion is of course not being corrected by Big Ben (it's too late once it is recorded). "


Max, you are right. You know this, I know this. But it is not what I mean. Those engineers who have found out that their AD conversion sounds better when a BB is used, since it is not clear from the Apogee homepage how they use the BB, it is for me unclear if they are only cleaning up the path in between their converter or cleaning up the converter itself.

Again, there is often a lot inbetween AD conversion and DA, workstation, EQ, cabling, name it, all places where jitter can added to the process, and if the BB is cleaning that path up, you might think it has cleaned up the AD, and it has not.
I would only believe in one test situation, wordclock out BB to Wordclock in converter, AES converter out directly in DA, and listen.

As long as the BB can be used as inbetween reclocker, it can clean up jitter anywhwere in the chain, not only in the AD converter.  

Erik Sikkema

[danlavry]

“What I mean is as follows, and I will illustrate this with a situation in my work.

When I am recording, my control room can be more than 300ft away from stage. I have AD converters on stage. At the end of the AES cables the jitter gets much higher. Although this is not a problem for my recorders, I usually place a Weiss Clockwork in the middle of the cable at 150ft to clean up. If I would hang a DA converter at the end of the cable at 300ft and switch the Clockwork off, it sounds worse than switched on.

If the BB can be used to clean up the signal path between AD and DA, you might think your AD is sounding better, the cause for the better sound is the DA gets a less jittery signal.

Erik Sikkema”

Erik, your comment regarding the confusion between AD and DA is technically valid. Here is my reply:

If  that “jitter cleaning device” which is a PLL box  (phase lock loop circuits) is 50ft from the DA  OK. How about at 10 feet? WHAT ABOUT INSIDE the DA? That is what I do. –A good PLL based circuit (or better) is inside my DA! And my final re-clocking circuit IS based on the MUCH SUPERIOR VCXO crystal technology.

I am willing to accept that external re clocking box for a DA can improve jitter when the DA PLL is poor. But this is not the best solution. Internal jitter removing is better. Just get a good DA with good jitter handling capabilities.

Why?

Say you removed “all” the jitter and you have the perfect AES signal (or SPDIF). It is going to get pretty jittery as soon as you enter the DA.

Hawksford in his AES paper (about 10 years ago) “Is the AES/EBU Digital Audio Standard Flawed?” sheds light on the jitter problem .The AC coupling of a transformer (or capacitor) sets a limit on the capability of the digital audio link. That limitation makes the whole AES (or spdif) waveform wobble up and down. That wobble is DATA DEPENDENT and causes DATA MODULATED JITTER. The conclusion is to do the jitter removal AFTER the AC coupling at the DA input..

True, every little bit helps. I have nothing against getting into the DA with zero jitter but that help will prove minimal. The lion share of the jitter removal task needs to take place after the AC coupling – inside the DA.

At the risk of repeating myself lets get back to AD clocking:

1. It is best to use internal crystal when possible  

2. Even when using external or internal master clock, crystal technology is superior. It is true that DDS provides lower cost and more flexibility, but it is at the expense of more jitter. That is true for AD and DA.

3. Regarding “cleaning jitter” at all sorts of places in the chain: It matters most at the AD. It matters at the DA. It matters where there is an SRC. The rest is just about data transfer. The jitter requirements for data transfer are a lot less stringent – the idea is to make sure you don’t drop bits.

Max, it is technically impossible for your FUNDAMENTALLY FLAWED CONCEPT of external clocking an AD, to improve A/D performance and your statement about D/A is marginal.  Also, the Apogee Big Ben clock cannot outperform other clocks that do have fixed crystal and VCXO based designs. Jitter removal inside a box for DA is FAR BETTER to jitter removal externally. Jitter reduction of AD with external clock is an imposible task, as I explained in my previous post.

Also, External jitter removal leave open a path, (between the external clock and the AD or DA) where more jitter is accumulated and/or generated. The internal jitter removal circuit approach eliminates that very serious fact of life (I explained it above for the DA case).  

I have previously mentioned that this forum is the wrong place for you to make appearances.  I have no more time to spend responding to sales talk. Your company engineer already said that your advertisements incorrectly state his product design’s capabilities. There are many chat rooms entirely devoted to listening. Please find one.

Regards
Dan Lavry

[bobkatz]

ErikS wrote on Tue, 09 November 2004 15:32

If the BB can be used to clean up the signal path between AD and DA, you might think your AD is sounding better, the cause for the better sound is the DA gets a less jittery signal. Erik Sikkema

How about using a D/A converter that is immune to jitter in the first place? That kind of functionality should be built into converters. There should be no need for a $1500 add-on. And as Dan Lavry points out, the dejittering really MUST be inside the converter. Because any external dejittering box has to face the reality that the following box DOES NOT SEE ITS clock directly; there is interface jitter and the jitter gain of the PLL within the following device.

I'll say no more, because I don't want to prejudice my listening tests any more than they already are. They will have to be blind in order to convince anyone.

[Terry Demol]

bobkatz wrote on Wed, 10 November 2004 00:59

ErikS wrote on Tue, 09 November 2004 15:32 If the BB can be used to clean up the signal path between AD and DA, you might think your AD is sounding better, the cause for the better sound is the DA gets a less jittery signal. Erik Sikkema How about using a D/A converter that is immune to jitter in the first place? That kind of functionality should be built into converters. There should be no need for a $1500 add-on. And as Dan Lavry points out, the dejittering really MUST be inside the converter. Because any external dejittering box has to face the reality that the following box DOES NOT SEE ITS clock directly; there is interface jitter and the jitter gain of the PLL within the following device. I'll say no more, because I don't want to prejudice my listening tests any more than they already are. They will have to be blind in order to convince anyone.

Bob,

What dacs are you going to use for evaluation? Benchmark
is out as Apogee has clearly stated that the effect of BB
does not apply to ASRC based dacs.

Cheers,

Terry

[danlavry]

I agreed to moderate this forum for the sake of communicating TECHNICAL knowledge. There are many other forums for discussing listening tests, psychoacoustics and the ear.
I am going to use my discretion to remove and block massages that go against the intent of this forum, as stated by the rules.

Best Regards

Dan Lavry

[danlavry]

“Apogee has clearly stated that the effect of BB
does not apply to ASRC based dacs.

Cheers,
Terry”

I heard such statements before. Is it true that SRC based DA is completely immune to jitter? If such were the case, all the DA makers would be putting an SRC in front of the DA’s. Other then increased latency (which is an application specific drawback) the DA jitter would be completely solved. Is it so?

The idea of SRC is to take data arriving with a jittery clock, and make it into data with a steady clock. Indeed, one can use an internal crystal oscillator, which beats any “jitter external cleaning device”, and is even slightly better than a  VCXO (pull able crystal) based PLL circuits.

But this is not the “end of the story”. There is something else that is taking place while substituting the jittery input clock with a clean fixed internal crystal. That something else is a complete and elaborate computation calls SRC.

The relationship between the incoming jittery clock (at the input of the SRC) and the fixed clean clock (at the output of the SRC) is not fixed. The relative timing between each input clock and the output “clock train” is not well defined. The phase is totally unknown, and the “specific per sample time location” is “bouncing” forwards and backwards in time. The more jitter the more it bounces.

Each individual output sample (the data itself), is figured out with it’s own unique set of coefficients. The selection of the coefficient set is based on the relative timing of the INDIVIDUAL output sample to the incoming data sample time locations. One ends up with a filter computation, where a complete set of coefficients are is being “replaced” changed from sample to sample…

So the DATA ITSELF is being altered. Not only does it get to go through a complete LPF (low pass filter) computation, the filter coefficients are timing dependent. Jitter does modulate the coefficient selection process. The more jitter, the more it alteration of the data.

Therefore, SRC is not a "perfect solution" to eliminate problems caused by jitter:

The clean internal PLL and clock is an attempt to fight the physical time jitter. The advantage of this method is the fact that the DATA IS LEFT INTACT.

The SRC solution provides a great clean clock, but IT ALTERS THE DATA in order to make it “match the new clean clock”.

The artifacts of both approaches (clean PLL based and SRC) are very different.

The better the SRC, the closer we get to perfection. The better the PLL, the closer we get to perfection.      

My point is: the assumption (or marketing claim) that SRC based DA’s offer a complete solution to jitter, is not correct. There is a price to be paid – a SRC in series!

BR
Dan Lavry

[Roland Storch]

danlavry wrote on Wed, 10 November 2004 19:26

Therefore, SRC is not a "perfect solution" to eliminate problems caused by jitter: The clean internal PLL and clock is an attempt to fight the physical time jitter. The advantage of this method is the fact that the DATA IS LEFT INTACT. The SRC solution provides a great clean clock, but IT ALTERS THE DATA in order to make it ?match the new clean clock?. The artifacts of both approaches (clean PLL based and SRC) are very different. The better the SRC, the closer we get to perfection. The better the PLL, the closer we get to perfection.       My point is: the assumption (or marketing claim) that SRC based DA?s offer a complete solution to jitter, is not correct. There is a price to be paid ? a SRC in series! BR Dan Lavry

Thanks for this explanation. That means there is no perfect DAC which works synchronious to an incoming digital signal.

Wouldn?t than a bigger buffer be the best solution? I mean if I took a harddisk to record the incomming data from a digital source and play that back later I could have a perfect internal clock for my DA converter fed with data from the HD.

If I needed less "delay" couldn?t I just take more buffer size? I wouldn?t have a really synchronized DAC but if I only needed the best playback I could determine the incoming frequency, lets say 48k, then set the internal clock of the DAC to 48k and play. So there would be a small drift, maybe some milliseconds in an hour, but for playback only I had the best solution.

This would not work in studio where the signal has to be synchronious. But for playback only for my ears without further manipulation of the signal, i.e. any player for only hearing a digital source, wouldn?t?that be a perfect (because decoupled) DAC?

[Bob Olhsson]

The bottom-line of all this stuff is the actual quantity and the spectral character of the artifacts produced by each particular PLL or SRC implementation.

[Nika Aldrich]

Ahh, I'm lovinig the direction of this thread.  It's great to see some of this stuff addressed and understood in public.  To answer the questions:

Roland Storch wrote on Wed, 10 November 2004 16:56

Thanks for this explanation. That means there is no perfect DAC which works synchronious to an incoming digital signal.

Well we have to be careful about that.  Sure, it may not work "perfect" to the analog signal, but who cares about perfection?  We're talking about human beings and human limitations.  What we care about is that the variations in the eventual clock signal used for reproduction (the jitter at the D/A) is low enough and of a character enough that it manifests itself as distortion that is too low in amplitude or outside the audible spectrum.  If we can create a system that produces low enough jitter related distortion that we can't hear it then why do we care about "perfect" synchronization?

Quote:

Wouldn?t than a bigger buffer be the best solution? I mean if I took a harddisk to record the incomming data from a digital source and play that back later I could have a perfect internal clock for my DA converter fed with data from the HD.

Sure, so the tradeoff is latency and cost of the larger buffer versus jitter.  Compromises are obviously made along the way.  If you have a HUGE buffer you have to have a lot of local memory and you induce potentially very long latency, but can reduce the jitter to inconsequential, no?  If you only have 1 sample of buffer then you're going to have to reconcile pretty quickly, and that reconciliation causes jitter, yes?

Quote:

This would not work in studio where the signal has to be synchronious. But for playback only for my ears without further manipulation of the signal, i.e. any player for only hearing a digital source, wouldn?t?that be a perfect (because decoupled) DAC?

Sure, and while Dan may not toot his own horn, that is essentially what his gold series converters do.  They have something like 10 seconds worth of buffering in them.  OK, it's not really 10 seconds worth of buffering.  It's 10 seconds worth of buffering when you know the maximum amount the clock will drift.

That is important.  Let me repeat.  If you can know a small detail about the clock - say how much the maximum amount is that it can drift - then you can make a system that caters to that.  No longer do we have to have an infinitely large buffer.  We can instead have only enough of a buffer to last a certain amount of time, and we have a lot more flexibility about how we design that PLL, no?  I mean, if it's only going to drift by x amount then our PLL can be that slow in recalibrating itself.  

I'm not sure if I'm talking at your level or not.   Do you know the axle/wheel analogy for the PLL?

Nika

[Andy Peters]

Just thinking out loud here.  It seems to me that the rather obvious solution is a small elastic buffer.  I wouldn't be surprised if this is already implemented in various places.  Or maybe I'm just missing the point ...

The problem, as I see it, is really that the incoming serial audio data stream is asynchronous to the converter's clocks.  This is because we have to recover the clock and data from the AES/EBU or S/PDIF signal and a recovered clock will always have some amount of jitter.  This jitter will clearly be worse than a crystal.

The classical way of crossing clock domains in a digital system is to use a FIFO. The write side and the read side are totally decoupled and the clocks and read and write enables are separate.  All that is required is that control logic on both sides monitor the FIFO status.  The writing side must monitor a full (or almost-full) flag and hold off writing until their is enough space.  The reading side must monitor an empty (or almost empty) flag to ensure that it doesn't read from an empty buffer.

In the case of an isochronous system like our DAC, we can't hold off writes, as the new incoming samples will simply fall on the floor; nor can we hold off reads, lest we leave holes in our playback.  However, we can further constrain things such that we know that the read and write rates are basically the same. There's no sample rate detection, but that's the point: we use a switch to select the proper sample clock crystal.   This means that the FIFO should never completely fill nor should it ever completely empty (unless we stop writing to it, of course).

The FIFO itself needn't be large, maybe 16 samples ought to do it.  Of course reducing the FIFO size decreases latency.  One way to do it would be to shift the incoming data bits of each sample into a serial-to-parallel shift register and then write that parallel word to the FIFO.  As each sample is shifted in, it's written to the FIFO.

The read side is the reciprocal; when the reader determines there's enough (half full?) samples in the FIFO, it turns on the read state machine and pops a word from the FIFO and shifts it out. The reader continues until it sees an empty FIFO (the indicating that the transmitter stopped sending new samples), at which point it outputs all zeros (simple mute).  The point of all this is that the read side is clocked by the "clean" clocks.

Yeah, it's all just a handful of lines of Verilog ...

--a

[Nika Aldrich]

Andy,

Yes, you're doing great.  So lets look at this.

Andy Peters wrote on Wed, 10 November 2004 20:29

Just thinking out loud here.  It seems to me that the rather obvious solution is a small elastic buffer.  I wouldn't be surprised if this is already implemented in various places.

Yup, exactly, but that doesn't necessarily solve all of the problems.  How much buffering?  And what do you do when you get buffer overload or underload?

Quote:

The problem, as I see it, is really that the incoming serial audio data stream is asynchronous to the converter's clocks.  This is because we have to recover the clock and data from the AES/EBU or S/PDIF signal and a recovered clock will always have some amount of jitter.  This jitter will clearly be worse than a crystal.

Yup!

Quote:

The classical way of crossing clock domains in a digital system is to use a FIFO. The write side and the read side are totally decoupled and the clocks and read and write enables are separate.  All that is required is that control logic on both sides monitor the FIFO status.  The writing side must monitor a full (or almost-full) flag and hold off writing until their is enough space.  The reading side must monitor an empty (or almost empty) flag to ensure that it doesn't read from an empty buffer. In the case of an isochronous system like our DAC, we can't hold off writes, as the new incoming samples will simply fall on the floor; nor can we hold off reads, lest we leave holes in our playback.  However, we can further constrain things such that we know that the read and write rates are basically the same. There's no sample rate detection, but that's the point: we use a switch to select the proper sample clock crystal.   This means that the FIFO should never completely fill nor should it ever completely empty (unless we stop writing to it, of course). The FIFO itself needn't be large, maybe 16 samples ought to do it.  Of course reducing the FIFO size decreases latency.  One way to do it would be to shift the incoming data bits of each sample into a serial-to-parallel shift register and then write that parallel word to the FIFO.  As each sample is shifted in, it's written to the FIFO. The read side is the reciprocal; when the reader determines there's enough (half full?) samples in the FIFO, it turns on the read state machine and pops a word from the FIFO and shifts it out. The reader continues until it sees an empty FIFO (the indicating that the transmitter stopped sending new samples), at which point it outputs all zeros (simple mute).  The point of all this is that the read side is clocked by the "clean" clocks.

OK, so how does that reconcile The following problem:

The uber-stable interior clock is clocking at 44.1kHz, but being a clock that has a tolerance of around 150ppm, perhaps it is actually 44.09999992 kHz.  The data coming in from the AES stream is also coming in at 44.1kHz, but it is also a crystal device with a given tolerance of around 150ppm.  Its clock happens to think that 44.1000002kHz is 44.1kHz.

We're about to play a 1 hour CD.  

In other words, can we actually ever truly decouple the clocks on these digital devices, given that we have tolerances to deal with?  The purpose of the clock reconciling here is not necessarily to reconcile a stable clock against a jittery one.  We also have to deal with clocks that have two completely different senses of time, and somehow bring them together.  In other words, we HAVE to couple the two clocks in some way, somehow.  Your FIFO idea, however, is certainly the first step in solving the problem, and Dan's designs do indeed incorporate a FIFO buffer in them.

Nika