ADAU1701 audio clicks
I have just finisched my ADAU1701 proto board with AtMega32 AVR processor.
The DSP is booting from an externall NVM and the AtMega32 is used for realtime parameter update through a simple user interface (LCD + Rotary encoder with pushbutton).
I`m updating the parameters through the Saveload Write registers. As soon as I update some parameters in a sequencial order the audio starts to interrupt en clicks are audible.
Is there any way to avoid these interrupts?
I also noticed that some parameters needs to be updated without the 5.23 format. For instance the Hold(mS) in the peak gain compressor is not in 5.23 format. The actual parameter just needs to be shifted in the 4 bytes send buffer. Why?
Best regards,
Vincent.
Audio Signal Processors
SigmaDSP Audio Processors
adau1701
Hello Vincent,
In order to help diagnose and fix the problem, more detail about the problem is required.
1. What parameters in the signal flow are you updating?
2. What is your write sequence when using the safeload registers?
3. Can you supply a SigmaStudio project file or any other data that would help us to better understand the issue and duplicate it on our side?
It is important to note that Safeload only guarantees that parameters are updated between processing frames. It does not guarantee click/pop-free parameter updates. Changing any parameter instantaneously will create a pop/click sound. Generally speaking, the bigger the change, the bigger the audible artifact. In order to avoid these sounds, slew updates should be used for all controls that can be updated in real-time by a user. For example, slew volume controls will slowly fade the parameter from one value to another, avoiding clicks or zipper noise that would be audible when using a non-slew control.
You might want to try replacing any cells that can be controlled in real-time with slew versions from the algorithm library. If a slew version doesn't exist, you should try changing the parameter by a smaller amount in order to make the sound quieter.
Vincent,
In response to the second part of your post - not all parameters are saved in 5.23 format, as you've seen. When a signed integer.fractional format is not necessary for a certain parameter, they are typically saved in 28.0 format. You'll find many parameters in this format when the lower end of their range is 0 (no negative representation), so the upper range will be (2^28)-1.
Some parameters are also stored in a format which is neither 5.23 nor 28.0. In general, these parameters are used for internal calculations in the algorithm, and the algorithm designer has chosen a data representation that maximizes processing efficiency.
In any case, the best way to see what value is being stored in RAM is to change the parameter in SigmaStudio and check what is being output to the Capture Window.
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.