Suitable circuit for mixing 3 PCM/I2S + 4 PDM micropones with asyncronus sample conversion

Joakim,

I believe the best solution would be the ADAU1450, which is the ADAU1452's lower speed, lower memory, lower cost sibling. No CODEC would be required. Like the ADAU1452, the ADAU1450 has:

Four serial input ports and four serial input ports more than accommodating your two I2S inputs and outputs

Four PDM microphone inputs using one of the space serial port bit clocks and two GPIO (MP) pins

The ability to play samples from a EEPROM on its SPI own master port

A library of compressor/limiter blocks

The tool chain, SigmaStudio, is a free download. See the documentation for the WAV Player block here.

Ken

The ADAU1450 would be ideal. This is the lower memory, lower speed, lower cost sibling of the ADAU1452. Like the ADAU1452, it has:

Enough serial ports to handle your I2S I/O

Four PDM microphone inputs

A sample player block in the libraries

A collection of compressor/limiter blocks in the libraries

Only the addition of a stereo DAC and headphone amplifier would be required.

Ken

Hello Ken, and thanks for your reply!

It seams like ADAU1450 lacks Asynchronous Sample Rate Converters (ASRCs) Which is a must since the "Audio2" block in the diagram above have a sample rate that will vary between use-cases. So I guess that leaves us back at ADAU1452/ADAU1451?

Additionally I have a question regarding clocking, sample rates and how to avoid glitches:

AUDIO1: uses 8 or 16 kHz

It can only be configured as a I2S master

AUDIO2: varies between: 8, 16, 44.1 and 48 kHz

It can be either I2S master or slave.

The DSPs internal sample rate should be 48 kHz

I have identified two possible solutions to avoid glitches due to clock differences:

1. Let the DSP generate its own clock, configure both AUDIO1 and AUDIO2 as masters and internally route both trough ASRCs and let the ASRCs handle any differences between the clocks in the DSP, AUDIO1 and AUDIO2.

2. Make the clocks of ADAU1452 and AUDIO1 synchronous by using AUDIO1s bit clock as an input to ADAU1452s PLL by also routing it to the MCLK pin. Route only AUDIO2 trough the ASRC, since 48 kHz is an even multiple of both 8 and 16 kHz, no asynchronous conversion should be needed to match AUDIO1 to the internal 48 kHz rate.

Are both these solutions sound? are there any obvious advantages to use one over the other? Will power consumption be lower with solution 2 since fewer ASRC channels are used? or will the saving he minimal since we already need one up and running?

BR

Joakim

Joakim,

My apologies. I didn't realized that the sources were not at the same rate and clock slaves. You are correct in that you would need an ADAU1451 for the ASRCs (but not an ADAU1452). Regarding your two possible configurations, I would recommend 1 over 2. The reason is that the core needs to run at the fastest sample rate that you will be working with. If they are both 8 kHz or 16kHz, that is no problem. If one of them is a clock master at 48kHz and the other a clock slave at 8 or 16 kHz, that works, too. However, in your case, it sounds like the faster source has an unpredictable sample rate, and sometimes it is not divisible by 16kHz (when it is 44.1 kHz).

For these reasons, I would recommend running the core from its own clock at 48 kHz and passing both sources through ASRCs. That would prevent the core from limiting the source bandwidth, which would happen it case 2. You can power down the ASRCs in banks of four stereo pairs, so half of the could be off to reduce power. However, the savings there will be minimal. If you are looking for lower power and don't need much processing, I would recommend running the core at 150 MHz instead of its default of 300 MHz.

Ken

Hello again Ken and many thanks for your answers!

Just to clarify, the glitches I mainly worry about are the ones that comes from dropped and missing samples due two two circuits being almost in sync due to small errors in their respective oscillators.

i.e. say we have two ICs that both should process audio at 48 kHz, but due to oscillator errors one is creating samples at 48.0000001 kHz and the other is consuming them at 47.9999999 kHz, which will give the consumer a buffer overflow every once in a while.

Can the ASRCs handle such small arbitrary differences or do they only work on larger preset sample rate intervals (like 44.1 to 48 kHz)?

I am planning to run the audio processing in the DSP at 48 kHz internally anyway since that is the quality I need from the sound taken from the PDM microphones.

In the situation described under alternative 2 I was planning to use a 4.608 MHz bit clock from AUDIO1 and connect it to XTALIN/MCLK, set the predivider to 2 and the feedback divider to 127 to generate a 292.608 MHz clock.

To bridge the gap between the 16 kHz sample rate of AUDIO1 and the 48 KHz sample rate of the internal DSP I was just planing on repeating each 16kHz sample three times. Would this have been a viable solution?

Tough I think I agree with you that letting the ASRCs handle all discrepancies (as described in alt1) still seams like the best solution?

Here comes some additional questions regarding the different variants:

1. If I have understund things correctly the only differences between ADAU1415 and ADAU1452 is that 1452 has a larger memory? but otherwise they are identical and pin compatible? in that case we would prefer using the larger one on this our first revision and then maybe downsize once the FW is locked down and we know it fits.

2. ADAU1452 exist in a 150 MHz version. Can the 300 MHz version of ADAU1452 also run at 150 MHz? and if that is the case, is there any difference in power consumption between the 300 and the 150 MHz version if both are running at 150 MHz?

Hello Joakim,

I will jump in here and continue where Ken left off.

The ASRC is designed to work with a very close sample rate but it is a very difficult thing for an ASRC to do. It is best to give it a larger difference to work with. I have seen some applications where the core is purposely running at a rate that is around 5% different from the nominal rate. If this can be done will depend on your system but it is something to consider if you know the rates will often be almost the same.

It is best to use the ASRCs since they are there and do a great job without consuming MIPS in the DSP.

You can run the 300MHz version at 150MHz but there will be a few details that you need to deal with. First of all, the clock to all the modules around the core will be at half speed. So when you set the serial port to 48kHz it will be running at 24kHz fs. So you will need to use the fs x 2 setting to get 48kHz. Likewise, the AUXADCs will be running at half speed which may not be an issue.

The only other thing that might be an issue is the SPI and I2C ports. I think you will still be OK at 150MHz if you are running the SPI at the max of ~ 20MHz. The master port setup will also be 1/2 speed so there may be some things you have to adjust.

The actual 150MHz part has circuits that automatically compensate for the difference in the internal system clock rate so you do not see these issues. You can take a program that works fine on the 1452 and run it on the 1452K with no changes required. (of course I am assuming the program is not too large to run with half the MIPS available). So I suggest you run the 1452 with its normal clocks then you do not have to make any changes when you run it on the 1452K. When you compile the program you will need to watch the resource usage to be certain you do not use more than 50% of the MIPS.

If you have to gather power data then I guess you will need to make the changes in the settings I mentioned above.

If both the 300MHz and 150MHz versions are running at 150MHz the power dissipation will be very close. Since some subsystems are running at half speed the 300MHz version should have lower power when running at 150MHz. However, the core is the power hog in this part so the difference should be small.

Dave T

Hello Dave, and lots of thanks for those very in-depth answers!

Very interesting to know that ASRCs can struggle with close rates. Do they also struggle with rates whose even multiples are close to each other. e.g. Lets say one of our audio devices generates samples at 16.00001 kHz while the DSP consumes them at 47.999999 kHz. Would that create similar issues due to 3*16 = 48?

If we would go with the 5% off solution, I guess ~ 46 kHz would be a good core speed since that is about 5% off from both 44.1 and 48 kHz?

Another possibility for us is that AUDIO2 in the diagram above can be clocked with an external high precision 26 MHz source. So we could add a 26 MHz oscillator drives both ADAU1452 and AUDIO2 with the same clock. That would make the two complete synchronous when AUDIO2 is working at 48 kHz. Is there any potential issue by feeding an ASRC with the exact same sample rate it is supposed to convert to?

By driving ADAU1452 with 26 MHz clock, is it correctly understood that we cannot make the core work at exactly 48 kHz? and that we instead need to work with the closest rate that can be achieved from dividing the core clock with an even divisor?

E.g:

26/8*90 = 292.5 Mhz core clock.

292500 khz / 6094 = 47.998 kHz, closest achievable core speed with 26 MHz as PLL input?

Have I understood the situation correctly?

While we are at it, I cannot seem to find the voltage requirements for the XTALIN/MCLK pin. Are they related to the I/O voltage or the PLL voltage?

BR

Joakim

Hello Joakim,

The XTALIN/MCLK pin is on the IOVDD domain. If that is what you mean by voltage requirements. So if you are looking at the digital high verses low then use the Digital input and output pin specifications. The leakage is a little different and that is listed in the datasheet.

The designer who designed these ASRCs was very good and he did a great job with them. What is the issue is that when you calculate the difference in sample rates to then figure out the ratio, if the are very close the difference approaches zero. The variables are a fixed number of bits so if the number gets really small then you start having truncation errors and other calculation issues. Like I said, he addressed a lot of this so our ASRCs perform really well even at almost the exact same rate.

I did write a project that looks at the ratio and if it ever reaches "1" it switches from using the ASRC to a direct connection. This was for a customer who would sometimes switch to a source that was on the same clock domain. So it automatically would switch them on and off. I could dig that up and attach it if you like.

You are correct about the core speed. You would be slightly off if you use the internal clock as a master.

Keep in mind that if you run the core 5% slower you will have 5% less MIPS. The core can run asynchronous to the audio and the sample rate as long as you do not use the internal clocks like making a serial port a master. If everything is a slave then even the core start pulse can be triggered by something like the serial port so the system would be running at that sampling rate but the instructions would be at its own rate. So the number of MIPS per frame may slightly vary as they drift but we are talking only a few instructions out of the 6,144 for a nominal core clock. The clocking on this part is so flexible.

Dave T

Hello again Dave, and once more thanks for your extensive answers!

So if I understand you correctly 16.00001 kHz to 47.999999 kHz should be no issue at all?

It would be great if you could dig up the auto switching project that bypasses the ASRCs at even sample rates.

I am really not worried about loosing some of the MIPS since I think our project will be quite resource light anyway.

When you say that the core can run asynchronous to the audio sampling rate, does that assume that all audio IO goes trough the ASRCs?

I am a bit new to DSPs, so the concept of "start pulse" was new to me, but if I have understood things correctly, the start pulse is something that must occur at the beginning of each audio frame to initiate processing? and that means that the start pulse must be controlled by the fastest sample rate, which is either the Frame sync of one of the serial audio interfaces, or something internally generated if the internal sample rate is faster than any of the external audio interfaces?

Yes. You understand correctly. The SigmaDSP is a little different from most DSPs in that it normally executes the entire program once per audio sample (multirate and block processing being the two exceptions). The start pulse is an interrupt that indicates that the core should begin processing the new frame. This must occur at least at the fastest input rate so that no samples are dropped. The source of this start pulse can be an internal clock or any of the serial input or output frame syncs.

The ASRCs are designed to handle nearly 1:8 through 8:1 ratios of sample rates. You may think of the lock to the incoming stream as a digital PLL that servos as the rate drifts. For this reason, ASRCs are often used to reduce jitter since the tracked rate does not change instantaneously. The ratio of incoming rate to outgoing rate is continuously calculated in hardware and may be seen in the ASRC register window. In practice, even ratios very close to unity are not a problem (even with the finite precision) because it will smooth out grace fully over a few cycles. Note that the core should match the output rate of the ASRCs.

Ken

Hello Ken

You say that ASRCs are some times used to reduce jitter, does that imply that in these cases the audio is sent trough the ASRCs even when the sample rates are the same (on paper)?

I have two other questions regarding signal routing and how signals can be clocked in and out. Take a look at the mock-up schematic attached to this post.

In this design there are four I2S buses with the following characteristics:

I2S_1 DSP is slave, audio should both be transmitted and received.

I2S_2 DSP is slave, audio should both be transmitted and received.

I2S_SYS DSP is slave, audio should only be received

I2S_CODEC DSP is master, audio should only be transmitted

my first question is: In the case where DSP is slave, can I use BCLK_INx and LCRK_INx to clock out data from SDATA_OUTx (like I have done with I2S_2 in the schematic), or must I connect the BCLK signal to both BCLK_INx and BCLK_OUTx and WS to both LRCLK_INx and LRCLK_OUTx (as I have done with I2S_1).

My interpretation of the text and table on page 72 of the datasheet (Serial clock domains) is that a clock in pin can not be used to drive a clock out pin.

My second question is regarding PDM microphone connections. Have I connected them the right way in the schematic? and can I use the BCLK_OUT2 to clock them even tough I am using the IN2 interface to interface with a I2S port?

BR

Joakim

PDF

Joakim,

1. Yes. ADI fellow (and AES and IEEE fellow) Bob Adams invented the ASRC. When it was only available as a stereo standalone IC, a customer implemented a high-end DAC for recording studio use. It passed the signal recovered from an S/PDIF or AES3 receiver through an ASRC clocked with a very stable crystal. Then result was then sent to a DAC running at it's "sweet spot" sample rate, whatever they determined that to be. The design won multiple awards. Jitter in the S/PDIF stream had little or no effect on the audio. To your question, customers have used similar topologies where the output rate is nominally the same as the input rate with excellent results. This is one of its intended use cases.

2. Your interpretation of the table is correct. This is an unfortunate limitation and is often overlooked. Any input can, internally, be set to use any other input's bit clock or frame sync. Similarly, any output can be set to use any other output's bit clock or frame sync. However, there must be an external connection from one of the input's bit clocks to an output bit clock, and also for the frame sync.

3. Your PDM mic clocking and connections look fine. I'm assuming that PDM_1 and PDM_2 are each pairs of microphones. If not, they can share a single MP pin.

Are you planning to pass the signal from all of the clock master devices (other than the DSP) through ASRCs? Exactly one external device may be a synchronous clock master, but not more.

Ken

Hello Ken,

I have to say that the level of support I get from this forum is OUTSTANDING. You and Dave are doing an amazing job!

I am not completely sure about what you mean with the last sentence, so I'll try to explain how I intend to design the system to you:

I intend to run the DSP core at 48 kHz

I2S_1, I2S_2 and I2S_SYS will all have the other device being master and the DSP slave

I2S_1 and I2S_SYS run at 16 kHz

I2S_2 will switch between 8, 16, 44,1 and 48 kHz

I2S_1 and I2S_2 are bidirectional while I2S_SYS only sends data to the DSP.

I am planing on making all the master interfaces asynchronous.

I2S_1 and I2S_2 will consume 2 each since they are bidirectional while I2S_SYS will only need one, this means I will need to use 5 of the 8 available ASRCs

I2S_CODEC will have the DSP as master and the CODEC as slave. I will use the CLKOUT pin to clock the codecs master clock with the intention of making this link fully synchronous.

The PDM clock will be set to match the DSPs core clock, which I guess will make the PDM link synchronous as well.

Do you think the plan outlined above is sound? Have I misinterpreted anything from the ADAU1452 spec that might cause a showstopper?

BR

Joakim

Thank you!

That should work. What I meant was that the core needs to sync to something, whether that is its internally generated clock (simplest) or an external master. If there is more than one external master, then you need to pick one and pass the rest through ASRCs. If you can pass all of the external master sources through the ASRCs (as you plan to do), all the better. I hope that make sense.

Ken