Component request: Delay processing block with milliseconds (not samples) parameter
Hi everybody,
is there the possibility to ask the team to develop a block of delay with the parameter expressed in milliseconds and not in samples?
The question can seem strange, but it would be very useful in applications where you switch the sampling frequency without the use of a microcontroller, and the firmware remains the same.
I'll explain the problem.
I'm using the 1701 for several boards and often use the delay function (both delay and multi tap voltage controlled delay).
In my applications I often switch sampling frequency, using all the usual ones for hifi audio 44100, 48000 .... to 192k. Of course there are two oscillators on board, and the appropriate master clock, bit clock and LR clock are generated properly.
Now the problem: if the 1701 is used with a microcontroller there are no problems in switching the frequency, and as regards the delay the appropriate parameter (number of samples) can be setup easily, I just have to scale the reference value for 44100 to the one needed for the new frequency and write it (by uc) in the appropriate location. For example, if the delay block is set to 10 (samples) at 44100 (with a maximum delay of let's say 50) and I switch to 88.2K I can calculate an (eventually ) approximate value of 10 * 882000/44100 = 20 samples. In other words if the delay is 10 samples at 44100 Hz (-> 10/44100 = about 0,226 ms), the same delay (0,226ms) can be obtained at 88200 with 20 samples.
I know that the difference between samples and milliseconds is just a scale factor depending on sampling frequency, but I was not able to find a way to read how the dsp is setup regarding the processing ratio (X1, X2, X4) and use it for adjusting the delay.
What I'd like to have is a firmware that actually can work with different sampling rates without the need of external control. Of course that firmware must use only 256 steps (of the full 1024) to work at all frequencies.
In my experiments I see that there's no problem for filter coefficients (they remain the same if I switch sampling frequencies), but the delay parameter if expressed in samples must of course be adapted. This would not be necessary if the parameter was in milliseconds and not in samples, and in the processing block I suppose it would be the matter of a couple of DSP instructions to calculate the "samples" parameter.
Any hope to see this new processing block?
Hi Daniele:
>> see that there's no problem for filter coefficients (they remain the same if I switch sampling frequencies)
I'm afraid your above statement is incorrect. Every time you change the sampling rate, the filter coefficients will change and therefore even if we provide the functionality you suggests, it will not satisfy your needs.
Please comment.
Miguel
As far as I can see from my experiments the coefficients for byquad filters computed at 44100 Hz are OK even if I switch to different frequencies. This is normal, as the coefficients are always related to the relative and not absolute frequency (in other words a filter at 11025 Hz when fs is 44100 is actually at 1/4 fs ... so the same coefficients will work as a filter at 1/4 fs when switching to other sampling rates).
I tried it and it works, I have a DAC board with a 1701 equalizing the behaviour of speakers, and I can switch freely to the sampling freqs that I need. The DAC actually is a USB Class 2 DAC, working with Kernel streaming under windows (so actually using the exact sampling rate of the song). I can freely create playlists with different sampling rates. The fs is switched on the fly (and indicated by LEDs on the board, the microcontroller actually generates the correct MCLK, BCLK and LRCLK using one of two clock sources (XO). Be assured that the fs changes, and filtering remains OK. The firmware for the Adau1701 is loaded from an eeprom at startup (the usual 1701 load mechanism) and remains the same.
If in my workflow I'd like to use delays, of course this won't work unless I change the samples delay parameter. If I need 0.2 ms delay, that's about 0,002 * 44100 = 88,2 samples (I'm rounding it to 88), if I switch to 96000 hz to get the same delay I need 0,002 * 96000 = 192 samples. If the parameter was "ms" and not "samples" the system could go on working without any external intervention.
What do you think about this?
Hi Danielle:
Let me understand what you are doing. Coefficients remain pointing to the correct frequency (absolute) when you change sampling rate because you are using SigmaStudio and SigmaStudio is recalculating the coefficients every time sample range is changed. Is this correct?
You need a ms based delay cell to have SigmaStudio automatically modify the samples used in Delay every time you change sample rates.
Are you using SigmaStudio for production products? What's your application (can you share)?
Please comment.
Miguel
No, It's not Sigmastudio.
Sigmastudio is used only to develop a workflow at 44100 Hz. The 1701 is used in slave mode, so all clocks come from outside (and are properly changed when we switch frequency).
As I wrote before, the coefficients are computed only once, actually is Sigmastudio that computes them (imagine using a second order biquad). The project is setup at 44100 Hz. It's compiled, linked and downloaded. Then it's written inside an eeprom (by Sigmastudio).
When this system starts it does at 44100 Hz. The 1701 loads its program and coefficient from the eeprom via selfboot. The clocks are supplied by the microcontroller.
When we need a frequency switch the DSP is paused, the "Program Lenght" parameter of DSP core is switched (1X, 2X, 4X) appropriately by the microcontroller by writing the correct value inside the corresponding register, and the new clock frequencies applied from the microcontroller.
When the DSP is taken out of pause (I don't remember well, probably pausing is not strictly necessary), it starts working at the new frequency and (supposing that its program length is <=256 instructions) it can work ok at any frequency.
All of this happens in real time.
Just to be clear: the coefficients of the filters are not recomputed.
As far as I have seen it's also possible to set the "Program Lenght" parameter of DSP core fixed at 4x when compiling, fixed, and eveything works at any frequency. So the microcontroller does not need to modify any parameter inside the DSP (I can do that, and I did in the past, but it's extremely boring to maintain the uc and DSP firmware in sync). The microcontroller actually controls only the clock frequencies (it generates them by dividing the master clock). Actually the DSP board is a sort of slave "black box" with its fixed firmware, only clocks are supplied from outside under control of the microcontroller.
In this scenario having a delay with "ms" parameter could allow the creation of completely frequency independent workflows with delays. Write the workflow at a base frequency, compile and link once. Then this DSP firmware can be actually frozen inside an eeprom, and it can work at any frequency.
From the point of view of the DSP, having access programmatically to the multiplier factor (1x, 2x, 4x) of the core (or other values that surely exhist but I'n not aware of) can allow easily to compute how many samples are needed for a specific delay in milliseconds, the firmware would be adaptive..
Just to be clear, I'm not using Sigmastudio for production, only for development.
The final board is completely standalone. It's a DAC with no control with frozen firmware that actually follows the sampling frequency supplied by the host computer (it's connected on USB).
In the past I developed microcontroller code that actually was in charge to recompute the coefficients of filters when switching frequency. It works, it's complete, but maintaining it in sync with the DSP firmware is cumbersome (even if doable). I later realized that recomputing coefficients is not needed at all, they are the same at all frequencies.... you only have to remember that IIR filters are only numbers, and that their filtering action is based on "relative frequency" and not on absolute frequency.
>> I later realized that recomputing coefficients is not needed at all, they are the same at all frequencies
Below is my specific concern. (the filters produced by coefficients have different frequencies when running at different sampling rates, not the same)
For example:
If you compensate a 2kHz speaker resonance with a 2kHz peaking filter AND you change the sampling frequency from 96kHz to 48kHz:
When using the same coefficients.The 2kHz filter will now produce a 1kHz peak, your 2kHz speaker resonance will now, not be compensated.
In other words, the speaker itself doesn't care about the sampling rate.
Does this example makes sense to you?
Thanks
Miguel
This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.
Thank you,
EZ Admin
Please log in to reply.