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?
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?
+/-1000ppm is probably the outer limit. AES5 is the actual specification that defines the sample rate tolerances.
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.aspx?Ntt=549-C3391-24.576
I'm not familiar with the MPC5200. What is complicated about using an external low-jitter audio clock?
http://www.mouser.com/search/refine.aspx?Ntt=549-C3391-24.576
I'm not familiar with the MPC5200. What is complicated about using an external low-jitter audio clock?
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...
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...
If Your gizmo does not convert from dig. to ana. or does not provide a sp/dif out, you don't have to bother.
Unfortunately it is specified from 12 kHz to 80 MHz (suitable for RF applications, not audio :-( )rossl said:
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
Dave
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.
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.
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
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
But most of the I2S devices that support 192kHz will change the MCLK divider. You still will not need to go 49.152MHz for 192kHz. For example (I don't know which TI chip you will be using) the TAS5012 PWM controller has normal, double, and quad speed modes. For 192kHz it needs quad speed mode but quad speed is MCLK 128*Fs (24.576MHz). From 44.1kHz to 192kHz the clock range would be 11.289MHz up to 24.576MHz. This should not be a jump from 0.7% up to 2.7%. Was this only based on math or did you measure this? Why do you need to run at 192*Fs to give you 36.864MHz?
Dave
Dave
Dave Z...
Sorry for the confusion. The MPC5200 can generate master clocks for its I2S interfaces internally. Unfortunately, the method they provide can not accurately produce some of the common master clock frequencies. Some of those frequencies can be off by as much as 2.31% (for instance, when I try to make a 24.576MHz master clock). Of course, this translates to that amount of inaccuracy in the playback rate (that is, 192KHz data is played back 2.31% slower or faster).
Andrew...
Understood about the problems of clocking in and clocking out data at different rates. Eventually, one side or the other is short of data.
Jonsmirl failed to mention in his post that we do have the ability to clock our PWM modulator directly from our I/O module. No buffering involved. No CPU involved. I think he was referring to a case where he wants to tap into the input stream, suck it into the CPU and fool-around with it (encode it, store it in a file, send it over the net, ...etc).
Sorry for the confusion. The MPC5200 can generate master clocks for its I2S interfaces internally. Unfortunately, the method they provide can not accurately produce some of the common master clock frequencies. Some of those frequencies can be off by as much as 2.31% (for instance, when I try to make a 24.576MHz master clock). Of course, this translates to that amount of inaccuracy in the playback rate (that is, 192KHz data is played back 2.31% slower or faster).
Andrew...
Understood about the problems of clocking in and clocking out data at different rates. Eventually, one side or the other is short of data.
Jonsmirl failed to mention in his post that we do have the ability to clock our PWM modulator directly from our I/O module. No buffering involved. No CPU involved. I think he was referring to a case where he wants to tap into the input stream, suck it into the CPU and fool-around with it (encode it, store it in a file, send it over the net, ...etc).
If you are using S/PDIF then the S/PDIF receiver would extract the MCLK from the bitstream and could be the master. All of the clocks would get tied together (S/PDIF, Freescale, PWM modulator) so there should be no need to generate this inside the Freescale and there would be no speed problems. The Freescale just gets the data in, processes it and puts it back out. Most S/PDIF receivers now have an MCLK input so if the S/PDIF stream is lost it would switch to the XTAL input but the receiver would still be the master
Dave
Dave
- Status
- Not open for further replies.