Runtime Delay Adjustment Causing Unexpected Glitch in SigmaStudio 4.5
I'm using multiple simple Delay blocks to offset separate data flows in a SigmaStudio 4.5 project.
___________________________________________
Example Setup:
SourceA --> DelayA --> SourceA_delayed
SourceB --> DelayB --> SourceB_delayed
___________________________________________
I change the delay values at runtime and observed this behavior:
If SourceA has no input and SourceB has input, and I increase the delay value of DelayA, I see a glitch on SourceA_delayed, which disappears after a while.
If SourceA has no input and SourceB has input, and I decrease the delay value of DelayA, everything works properly (no glitch).
If both SourceA and SourceB have no input, and I increase the delay value of DelayB, everything works properly (no glitch).
I plan to try a different delay block, such as Multi-Tap Voltage Delay Control, but this is inconvenient because that block + DC input uses 18 MIPS instead of 5.
Question:
Can you explain the strange behavior described in point 1?
Is there any way to change the value of a simple delay block at runtime without these side effects?
Audio Signal Processors
software
adau1442
SigmaDSP Audio Processors
delay
SigmaStudio 4.5
Show More
Hello padulab,
I could make a funny comment that DelayA just does not like being ignored and so it is complaining!!
What I suspect is going on is that the memory may not be fully cleared at bootup. I think this was a bug that they fixed in earlier versions of SigmaStudio. Why are you not using Rev 4.7?
Anyhow, so when you expand it the delay then pulls from memory with random data in it. Once it has completed it will now be filled with zeros if the input is muted. Then add to this that often this random data goes from low levels to high levels which are loud pops and also causes issues with the IIR filters since those use feedback it will cause them to ring for a short time. I would guess that you may have some EQ after the delay cell.
If you have a system controller then I suggest you have a startup routine to clear out the delay memory either directly by writing to the RAM or have the delays set to the max length when you compile the project and output the system files or program the EEPROM. Then also have the input to the delays muted so the DSP wakes up with the delays set to max and the input muted. Then have the system controller wait the length of time of the full delay line, then reduce the delay setting to the desired default and unmute what you desire to unmute.
You had me surprised because I read your post and started thinking about it then realized you are using the ADAU1442!! That was a great part but it is not used too much anymore.
Also, one more thing. You mention that Source_A has no signal, does this mean it is muted or just a floating input with no active signal? Because then, there could be things like a DC offset or some other high frequency noise that could cause some issues.
Dave T
Hello Dave,
thank you for your reply.
The project was started some years ago and we maintained the old software version.
Anyway, I tried to open the project with v.4.7 but this hasn't solved the issue.
I also tried to initialize the delay with the maximum value and then change it. But even in this case, after reducing the delay value, when I increase it again, even by only 1 sample, I encounter the same issue.
At the moment, the only thing that seems to work is using the multitap voltage-controlled delay.
You mention that Source_A has no signal, does this mean it is muted or just a floating input with no active signal --> I also tried providing a zero signal but the effect is the same.
I haven't yet tried to clear the RAM, but I guess this won't solve the issue either. The problem doesn't exist only at startup but occurs every time I try to increase the delay value.
If you need more details, I can provide them.
Thank you for your time, and I hope we can find a solution—or at least understand the reason behind this behavior.
Biagio P.
Please log in to reply.