ADAU1772 48KHz processing by underclocking?
I have some questions regarding sample/clock rates in the ADAU1772 with the goal of processing audio at a 48KHz sample rate and connecting bi-directional audio on the serial port as a slave at 48KHz, 16KHz, and 8KHz (need to support multiple modes of operation) , with a 12.288 MHz ext clock source. Note we need to run our signal processing 48KHz because at 96KHz there are not enough instruction elements to handle our filter spans which would be twice as long at 96KHz.
1. It seems the CORE_FS can only be set for 96KHz or 192KHz (In Register 9) similarly the A/D rate can be set to 96KHz or 192 in Reg 0x1b.
If the A/D rate and CORE_FS are set to 96KHz can I safely under-clock and setup the clock control so that the master clock and core clock are 6.144MHz (running at 1/2 rate using the divide by 2 in CC_MDIV and CC_CDIV in Reg 0 with the 12.288MHz ext clock) to achieve a 48KHz processing sample rate? Are there any internal analog filters that won’t automatically adjust with the under-clocking?
2. For the serial audio connection, in our setup the ADAU will be the slave (using external serial clk input). In this mode, is the serial clock rate setting (SER_PORT_FS) in Reg 0x32 used by the chip or totally ignored? Is it still used internally for selection of decimation/interpolation filters or will these be selected automatically based on a serial clock input rate lock? Does it have to be set to be “close” to the input serial clock?
3. Assuming SER_PORT_FS does still need to be set as a serial slave and assuming I can underclock at ½ rate then, similarly to question 1) then can you confirm, for example, that if the CORE_FS and A/D rate are set to 96KHz and the MCLK is 6.144MHz (underclocked) then if the actual serial input clock was 8KHz then I would need to set SER_PORT_FS to 16KHz to compensate for the underclocking and everything will work out properly (there are no fixed analog filtering effects)?
4. Given my setup/goals are there performance optimizations possible by setting CC_MDIV and differently (do I need to under-clock both to achieve my goal)?
adau1772
Integrated/Special Purpose A/D Converters
Audio CODECs
Hi jpov,
in theory, this should work. The goal of a PLL is to obtain a given ratio between local clock and external clock. However, I am not sure that the local clock can go so low. You should check that on the datasheet.
Otherwise, you take the risk that the PLL never locks because the local oscillator does not go low enough.
There is also a risk that the processor core becomes unstable (some processor cores can't run with a clock frequency which is too low because of dynamic refreshing of some cells). Once again, check on the datasheet what is the minimum allowed clock.
Benoit
Hello JPov,
The architecture of this part is very different from most DSPs. Running the core faster or slower will not give you more instructions per sample period nor will it give you more. So you do not take a hit for number of instructions when running at a faster rate.
Regarding the serial ports, the data going between the core and the serial port passes through sample rate converters. These ASRCs will convert from the serial port rate to the core rate. So you do not need to trick the core to run slower to match the serial ports. I would not try to run the core at 48kHz. Run it at 96kHz to save power or at 192kHz if you need lower latency.
The Serial port fs register is to set the serial port rate when it is in master mode. When it is a slave it ignores this register. The ASRC will always monitor the fs on the serial port side and convert it to the core rate. So in slave mode that would be the clocks you are feeding to it. In Master mode it takes its own clocks that is driving the serial port. The ASRC does not really know where the clocks are coming from, it just happily translates what it sees on the serial port clock pins.
Dave T
Hello David,
Thanks for the info.
Our need for running the core at Fs=48KHz is that this reduces the span/length of the filters required for our application. At 96KHz there are not enough "instructions" to implement our desired application on that part. Specifically our beamforming application needs many biquads elements to create the required delays. At 96KHz twice as many filter blocks are required to achieve the same delay on each mic signal path compared to running with Fs=48KHz (by underclocking).
If it is safe to run with a 6.144MHz MCLK (driven by external 12.288MHz clock - not the PLL) and setting the core to run at 96KHz (so really running at Fs=48KHz) then this is the ONLY way to run our target application. Prototyping this seems to work fine as hoped (no issues observed yet), but the datasheet says that MCLK should be very close to 12.288MHz (Pg 10). Is that a real constraint? If so what are the problems under-clocking may cause? This is for a high-volume consumer product so we are concerned about small percentage failure risks too.
Thanks.
JP
Hello JP,
Sorry for the delay in my response.
As long as you are not using the PLL then it is safe to under-clock the part. You are not taking it to an extreme.
The only complication I see is with the ASRCs for the serial ports. It requires a certain number of clock cycles per sample. If you were trying to go to 192kHz then it may be a problem but you are not trying to do that so you should be fine.
Now I am confused by something. This part is a very different architecture. Running it slower does not give you more instructions. So you should be able to run the same amount of filters regardless of the sample rate settings. Now I think you are talking about an external DSP that requires the time to process the filters. Correct?
Feel free to contact me directly. Then we can discuss more detail about your application.
Thanks,
Dave T
Dave,
Sure it would be great to talk to you directly but I don't have your contact info. Perhaps you can email or call from my profile info that you can possibly see as an AD employee.
To answer your question, our application requires delaying and adding several audio input signals. The amount of program elements (biquad filter blocks) required to achieve a desired delay is proportional to the Fs sample rate.
E.g. say you need a delay of 41.6 usecs, this is two Fs=48KHz samples or b[m]=[0 0 1] and can be achieved with 1 biquad filter block (only using the feedforward-numerator b[]).
If the Fs=96KHz then the same 41.6usecs is 4 samples requiring b[m]=[0 0 0 0 1] and two cascaded sigma biquad elements.
Therefore you need double the biquad program blocks to implement the same application at Fs=96KHz compared to Fs=48KHz, therefore an application that fits at the 48KHz=Fs may not fit at 96KHz.
Regards,
JP
Please log in to reply.