Audio Clocks

[quiller]

I am curious about how much clock inaccuracy is acceptable in a pro-audio device. I suspect the answer is *none*... but if you had a choice of adding to the cost of goods or going with something a little less accurate, what would you do?

I am using a Freescale MPC5200 as the CPU in a gizmo I am working on. The MPC5200 has many nice aspects. Fast, low power, PowerPC, FPU, multiple serial controllers, ...etc. However, it has one serious drawback as an audio processor. It does not have a very accurate clock generator for audio frequencies. Ouch!

The problem is that the clock divider on the MPC5200 does not have enough precision. So, you can only approximate some of the more important audio frequencies. The best I can do is 0.07% error on a 32KHz signal. That doesn't sound too bad. That error is about 23 Hz. However, the worst is 2.31% error at 192KHz. A 2.31% error on a 192KHz signal means that it is actually running at 187.56KHz. That sounds bad...

I can clock the serial channels of the MPC5200 with an external clock. However, they aren't cheap. Adding an audio clock generator to the design might add as much as $4 to the design. It also complicates the design a little more.

So... how much error is too much error? I already have about $40 in expensive chips so adding the external audio clock generator would add about 10% to my 'expensive components' pile. Is it worth it?

[rfbrw]

+/-1000ppm is probably the outer limit. AES5 is the actual specification that defines the sample rate tolerances.

[rossl]

This clock has 0.5 pS jitter and is $2.31 in low quantity. It is absolutely worth it.

http://www.mouser.com/search/refine....9-C3391-24.576

I'm not familiar with the MPC5200. What is complicated about using an external low-jitter audio clock?

[quiller]

Thank you for the responses.

Thank you for the clock suggestion.

I am going to incorporate an external clock. I was hoping to avoid it... but the error is just too great.

To answer the complication question...
It really is not a lot more complicated. It is just mighty convenient to use the internal clock of the MPC5200 and leave the serial interfaces in master mode. The MPC5200 does not let me generate a bitclock and frameclock from an external mclock, so, I would have to put the interfaces into slave mode and provide them with bit and frame clocks. Alternately, the MPC5200 does let me input a bitclock on one interface and use it as the master clock to another interface. Unfortunately, this consumes an interface just to get the clock into the chip and I have already assigned other tasks to all the serial controllers. Oh well. Right now, this second alternative is probably what I am going to prototype out and see how it goes.

When I initially looked around for a CPU for this gizmo, the MPC5200 looked like a good choice. Plenty of power. Linux support. Six serial controllers (4 of which can do I2S), Timers, USB, Ethernet, GPIO, ...etc. It looked pretty good. However, not having accurate audio clocks is a fatal flaw. If Freescale had just added a couple more bits of precision...

[TNT]

If Your gizmo does not convert from dig. to ana. or does not provide a sp/dif out, you don't have to bother.

[oshifis]

Originally posted by rossl
This clock has 0.5 pS jitter and is $2.31 in low quantity. It is absolutely worth it.

http://www.mouser.com/search/refine....9-C3391-24.576

Unfortunately it is specified from 12 kHz to 80 MHz (suitable for RF applications, not audio :-( )

[analog_sa]

You can't hear 12kHz?

[Dave Z]

I'm kind of confused by the whole thread. What sampling rate are you running at? Usually you would need a Master Clock of 256*Fs or 512*Fs, at 48kHz sampling for example, that would be 12.288MHz or 24.576MHz. I don't know why everyone is talking about such low frequency master clocks. If your Freescale has the I2S interfaces then it should take care of the clock dividing for you. If you really need to run your Freescale in slave then you should be able to use a DAC in Master mode and generate all clocks internally in the DAC as long as you supply the master from the oscillator. If you are using S/PDIF as source you need to use the reciever as the Master Clock because the PLL in the receiver needs to extract the clock from the S/PDIF and the master clock will change frequency based on sampling rate.

Dave

[jonsmirl]

We're looking at playing back 192Khz sampled HD audio as well as the common 44.1Khz audio. The Freescale chip does have internal dividers for making the clocks but they aren't fractional-N. That means the 44.1 * 256 clock has 0.7% error in it and the 192Khz * 256 clock has 2.7% error.

There is no standard DAC involved. The output goes to a TI PWM audio controller. The TI chip synchronously produces the music based on the i2s clock. It can be set for the whole spectrum of sample rates.

The problem with the clock error is that it makes the music playback too fast. HD audio will play back 2.7% too fast since its clock source is off frequency.

S/PDIF input is supported but it is not processed synchronously. The S/PDIF input is brought into the CPU and manipulated first. It can then be sent out again using the standard system clock. This is another source of frequency drift that the software has to deal with. Think of it as if the S/PDIF was being recorded and then played back.

Back to the original question, is a 2.7% frequency error in the 192Khz clock unacceptable for playing back HD music? If it is, then we need to add an external clock chip that can generate 36.864Mhz more accurately.

As a digression, it is likely that 192Khz sampled HD audio wil become popular in the next five years? It's already on BlueRay/HD-DVD but it is DRM'd and it only come out on the HDMI connector. S/PDIF from the player gets 44.1 audio. There are two sound tracks on the DVDs - one at 44.1 and one at 192.

[gfiandy]

Hi,

In answer to your question yes 2.7% is far too much. For high quality audio playback you should be looking at 100ppm error not 27000 ppm which I think is what 2.7% works out at.

Studio referances now work to 10ppm tolernace or better typically.

Most reasonable quality audio components work to 100ppm.

You can't process SPDIF in the manner you are considering as eventually you will run out of data if the signal is playing back faster than the reciver and you will need to sample repeat. Or if it is running faster that the playback you will eventually overrun your buffer and have to sample slip. This is only applicable if your system needs to run continually. If you can down load the entire file or guarantee the memeory wont run out of buffer during playback then its ok. However with a 2.7% error you are going to need alot of memeory to keep up.

Regards,
Andrew