Start pulse and core rates. ADAU144x
Lets say that the DSP core is being used for nothing other then data routing. In other words 1 stereo I2S input, being split into 4 stereo I2S output streams. Ergo no sampling frequency dependant filters are being used.
Lets say the DSP is set to generate the start pulse based off of the sampling frequency present on the input clock domain. Lets say it starts up at 48khz. The chips intput/outputs are also slaved to this same clock domain.
If the sampling frequency were to now change to 96/192khz would this require a reset of the chip or would it adapt to the new sampling frequency?
Obviously the ADAU144x isn't working as a master for any of the clock domains, so no software changes are required to reflect the change of the input sampling frequency, the BIT and LR clocks are provided by another source.
Initially I thought that I'd have to reset the ADAU144x when the sampling frequency changed, so that the core would start up from the new sampling frequency present on the intput clock domain. However when going about this I noticed that the rate of the data stream being output changed to reflect the rate of the data stream on the input, without needing to pass a reset.
Do I need to reset the chip when the sampling frequency changes or can the chip handle this itself? Obviously I'd need to change the software if filters were being used, but if they aren't?
The core is always screaming away at 172 MHz, so that never changes. The start pulse select register basically lets you change where the signal comes from that tells the core "start processing a new sample." In other words, it changes the audio i/o rate of the core.
The program counter will jump to the start of the program when it finishes processing a frame and then wait for that next audio sample to arrive. It will start processing once the next edge of the start pulse clock comes. So, in theory, if your program is very short and not at all frequency-dependent, then I suppose yes, you could change the sample rate clocking the core without any ill effect. The problem is that by increasing the rate of audio i/o to the core, you proportionally decrease the number of program instructions that can be executed in a given frame. At the default of 48 kHz, you can process 3584 instructions in a cycle. However, if your core start pulse suddenly doubled in frequency, that number halves to 1792. If the rate jumped to 192 kHz, then your executable program size decreases to 896.
In the case of a short program (a few hundred instructions), this doesn't matter, but if you had a program with 1k instructions, then the moment your sample rate jumps up to 192 kHz, the core will start skipping every other audio sample. This would severely lower the audio quality of the system - it's definitely something you want to avoid.
So, I guess if you're planning to change the sample rate while the system is running, I would have two suggestions:
Make sure you're using fewer instructions than the limit for the highest sample rate in your system (i.e. 896 or lower for 192 kHz), or...
Just use the ADAU1442 or ADAU1445 and route those signals through the ASRCs, and always keep the DSP at the same rate.
I would strongly recommend against the first option and strongly recommend that you use the second option. That is, after all, what we designed the ASRCs for in the first place: changing sample rates during operation of the system. I don't think there has been extensive testing of changing the start pulse during operation of the device and I can only assume you would get some unwanted audio artifacts if you take that approach.
My intended end application is to use the 1445 to handle the filtering required for a 4 way active loudspeaker. The DSP is to be able to handle up to 192khz, so indeed the program length will not exceed 896 operations. When the sampling frequency changes, a micro controller will update the parameter RAM to reflect the necessary adjustments to the filter coefficients.
I was under the initial impression that the start pulse was a one off event that occurs when the core is first initialised, and that any subsequent change to the sampling frequency would require a reset. However when you said...
It will start processing once the next edge of the start pulse clock comes.
It would appear that my assumptions were incorrect and the core is infact delivered a start pulse with each subsequent audio sample. This simplifies things greatly, although it might be a good idea to disable the core before updating the parameter RAM, then enabling it again once the update is complete.
Thank you for your response .
That's right, a new start pulse arrives every audio frame. Disabling the core before updating the start pulse and parameters is strongly recommended. I would also recommend inserting a master mute in the signal flow that uses slew. That will let you smoothly mute and un-mute prior to and proceeding the update.
So, the sequence would be:
Slew Mute - Disable Start Pulse - Disable Core - Update Parameters - Enable New Start Pulse - Enable Core - Slew Unmute
Please log in to reply.