0
\$\begingroup\$

I have a system with two DSP modules. The audio is routed from DSP1 to DSP2 and then back to DSP1, which in turn immediately sends it to DAC. It's a high-quality stereo sound at 44.1KHz.

This is a requirement, there should be two DSPs and routing can't be changed.

The problem is the clocks. Each DSP module has its own internal clock, which can't be ideally synchronised. I set the rate numerically on both, but the result is that I get a slightly glitchy sound, for obvious reasons.

One solution would be, of course, to feed the clock from one DSP to the other, but at this time this is a bit problematic for me.

Is there another way around this? E.g. a relatively simple algorithm that can compensate little differences between clocks? Any other ideas?

Edit: the connection between the DSPs is I2S. Either module can operate in master mode, but it doesn't help.

\$\endgroup\$
6
  • \$\begingroup\$ What is the original source of the audio? What is the nature of the communication channel(s) between the two DSPs? Actual part numbers would be helpful. \$\endgroup\$
    – Dave Tweed
    May 21, 2014 at 20:37
  • \$\begingroup\$ @DaveTweed it's a Bluetooth device, so audio comes via A2DP and is handled by the first DSP. It's CSR8670, the second DSP is our own. \$\endgroup\$
    – mojuba
    May 21, 2014 at 20:48
  • \$\begingroup\$ @DaveTweed the connection is I2S. \$\endgroup\$
    – mojuba
    May 21, 2014 at 20:52
  • \$\begingroup\$ It is common for the onboard I2S transciever to only want to operate as a master (that is, each device wants to generate the clock), since going into a 'dumb' CODEC is the usage 90+% of the time. I know this is true of the AD SHARC DSPs, in which case you (I think) would actually need to use sample rate conversion. Alternatively you can try to hack one of the generic synchronous serial ports (SPORT,MCBSP, etc) to emulate an I2S slave. \$\endgroup\$
    – Zuofu
    May 21, 2014 at 20:58
  • \$\begingroup\$ A block diagram would be really helpful. So you have audio coming into the CSR8670 via the Bluetooth connection, then you're passing that data to your proprietary DSP via I2S, doing some processing, then passing the data back to the CSR8670 (via I2S again?) which then sends it to the DAC? Which device is the I2S master? If it's the CSR8670, there should be no problem at all; the other DSP simply responds to the I2S interrupts and does its processing accordingly. If it's the other way around, you'll need to invent a flow-control mechanism to manage the transfers of audio samples. \$\endgroup\$
    – Dave Tweed
    May 21, 2014 at 21:30

1 Answer 1

1
\$\begingroup\$

If both DSPs cannot be slaved to the same oscillator for some reason you must use sample rate conversion. This is because after awhile, you inevitably will have 1 more or 1 fewer sample due to slightly mismatched clock rates. You can use simple interpolation, or more complex sinc based SRC methods for much better audio performance (see this paper for example). Alternatively, it is typically possible for the audio clock (for example, a I2S or AC97 clock) to be asynchronous from the DSP's internal processing clock, but this will largely depend on if the DSP has internal hardware to cross that clock domain (basically, it needs a dual clock FIFO). Some DSPs designed for audio (for example, the Analog Devices SHARC series) will have built in sample rate conversion modules for this exact purpose.

\$\endgroup\$
2
  • \$\begingroup\$ This is actually a very poor answer in the context of the question. It is rarely necessary to resort to sample rate conversion or asynchronous FIFOs when processing digital audio data. There are many other simpler techniques that can be applied first. \$\endgroup\$
    – Dave Tweed
    May 21, 2014 at 20:36
  • \$\begingroup\$ Well, it is not clear from the original question whether the DSP2 is an independent device (for example, connected over SPDIF) or whether the DSP is on the same board and you can run the clock lines from one CODEC to the other. I answered with the assumption that the DSP2 is on a second device connected only through the audio interface and left a caveat for the other case (basically, you can use a dual clock FIFO as I've said). I think the question needs to be more specific for a more specific answer. I think these are two very different scenarios and the question can be read either way. \$\endgroup\$
    – Zuofu
    May 21, 2014 at 20:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.