Max channels per ADAU1451 I2S port and changing sample rate at runtime
I'm utilizing the ADAU1451 in a project which will be supporting up to 32 bit audio at a sample rate of 192 KHz. We designed our prototype board with the assumption that all 48 I2S channels could be used across the 4 I2S ports (16 channels for two of the ports and 8 channels for the other two). However, I recently discovered that it appears the maximum BCLK frequency is 24.576 MHz (page 10 of the product data sheet). I think this means a maximum of 4 channels per I2S port when utilizing 32 bit and 192 KHz sample rate. Can anyone confirm this? I think this would still allow for up to 16 channels of 32 bit audio, on I2S ports which support this, at 48 KHz though, or 16 channels of 16 bit audio at 96 KHz, etc. so long as the 24.576 MHz bit clock is not exceeded.
Another question I have is in regards to changing the DSP sample rate at runtime. This will not be a common operation and will typically be done only once during product deployment. Does such a change require separate DSP images? Or can this change be made by register assignments only?
Thank you in advance for any tips or answers to these questions.
Audio Signal Processors
adau1451
i2s
SigmaDSP Audio Processors
SigmaDSP
Hello Element,
Sorry for the delay. Been busy which I guess is a good thing.
Yes, the 24.576MHz bit clock is a real limit and cannot be exceeded. This is the limiting factor on the serial ports. So you are correct that the limit will be TDM4 when running at 192kHz. You are correct about getting 16 channels of 16 bit audio on one TDM stream running at 96kHz provided the data is packed with no extra unused bits in the stream. There are tricks to get higher channel counts but in your case with 32 bit data you still run into the 24.756MHz wall.
Changing the DSP sample rate at runtime?... Most of the change is registers so that is easy to do. The issue comes with the DSP code. There are many of the cells that do not care and does not matter what the sample rate is. Like a volume control, does not matter. But, with things like oscillators and filters where the sample rate is the time reference then it does matter. Oscillators will output at twice or half the rate depending on the difference in rates. Filter corner frequencies will be in the wrong place. That is where the sampling rate set on the SigmaStudio screen tells the compiler to compile the code for that sample rate. Then it is up to you to send the proper clocks to the DSP and to set the registers properly so that the DSP core is actually running at the correct rate.
So depending on your application and what you are doing in the DSP then it might be a simple register change. If not then you have to download new code for the new rate. If you have extra MIPS then I suppose you could compile two sets of filters, one for each sample rate then switch between them. SigmaStudio should let you do that but I have not tried it.
One other comment. If you are going to run at 192kHz then setup your system so the ADC data coming in is the master and the DSP is the slave. Then have the DSP be the master on the output serial ports going to the DACs or whatever the output device is. This will help you with timing margins to prevent clicks and pops.
Dave T
Yes, being busy can be a good thing :-)
Thank you for the detailed information and confirmation of my analysis about the I2S ports and limitations.
Also good to know that I can change the DSP's sample rate via registers for simpler audio processing cells like volume control. I would think the asynchronous resampling units might be sensitive to rate changes though? We are using those for AES inputs.
I have an FPGA as the central component which is connected to ADCs, DACs, AES buffers, and SigmaDSPs. Our prototype is currently designed with the FPGA as the master for all I2S interfaces, both to and from the SigmaDSPs and other audio interfaces. This seems to be working and I did not observe any audio issues (though I did not do any extensive analysis of this yet). I wasn't expecting any problems though, because it is using the same clock. In regards to the issue you mentioned, would using the same clock source for to/from the DSP still potentially have this problem?
Thanks again for the helpful information.
Hello Element,
The ASRCs are lovely things! They operate fully on their own and all they do is look at the clocks on the input and compare them to the clock on the output and match them up with no user interaction! Happens automatically. The only little issue is that it will mute when it looses lock for a second but that is not bad. So if you write to the register that selects one of the clock sources then it will unlock and relock to the new rate.
If you are talking about the timing margin problem? Yes, it is always something to pay attention to but it is a solvable problem. Many products are out there that work well. It is really important when it is something like an automotive product that if there is one failure it is a huge issue! So being certain that there is plenty of timing margin for variations in temperatures and silicon is important. So to avoid issues you have to be careful with PBC layouts.
Dave T
Agree, ASRCs are the #1 reason we are using the SigmaDSPs. Glad to hear they operate independently of the sample rate. I kind of suspected as much, seeing as how their whole purpose is to operate asynchronously with 2 different clocks. Silence while re-locking is not an issue for our application, since the sample rate will rarely be changed.
Thank you again for all the helpful info.
Best regards,
Element Green
Please log in to reply.