Bug in SigmaStudio re-routes signal differently from the schematic?
Thread Summary
The user encountered a re-routing bug in the firmware after using MLSSA and Stimulus/Probe blocks to flatten a speaker response post-crossover. The high-frequency (HF) and low-frequency (LF) outputs were both receiving signals from the low output of the crossover, and the mute switch in the LF path also muted the HF path. The final solution involved setting the delay cell to 1 sample to prevent pointer corruption, and the engineer suggested using a MUX without slew to save on MIPS. The user confirmed the issue with the crossover outputs but could not reproduce the mute switch behavior, and the engineer requested the firmware files via a direct message for further analysis.AI Generated Content
I used the "Speaker Response: MLSSA" blocks and Stimulus/Probe blocks to flatten out a speaker response after the crossover, but when I went to actually use the modified firmware, it behaved bizarrely. The HF and LF were both getting signal from the Lo output of the crossover, despite the HF not being connected to it at all, and the mute switch in the LF path also mutes the HF path, despite not being connected to it at all. It was very strange, and persisted even after I removed the MLSSA and Stimulus blocks and connected it up as I had before adding them. I had to revert to a previous version file of the firmware, and manually implement the same filters in the EQ blocks, in order to get a working firmware without the re-routing bug.
Audio Signal Processors
bug_report
software
sigmaStudio 4.7
sigmastudio
SigmaDSP Audio Processors
adau1701
Show More
Hello J3627,
This is all well tested code and nobody has ever come across this before. So something is up that will take a bit more digging to uncover. There has to be an explanation.
Do you have a system controller involved?
Is the DSP using Selfboot?
Especially the 1701. Such a super popular part for this exact application. I am pretty sure you know how to reach me directly via email so we can share more information like the files so you can keep them confidential. I think you have emailed me before? Anyhow, if not then send me a friend request and then a DM and we can hook up.
How things like this usually happen has to do with pointers getting corrupted. If something is written to the wrong address it can corrupt a pointer in an object such that it will get its data from a different place in the program.
Dave T
It's in self-boot mode, no controller. I will verify that I can reproduce it and then send the files if so. I had never used the MLSSA block before, so I suspect it has to do with that. Or maybe from having multiple Stimulus blocks upstream from the same Probe block?
OK I tested again and confirmed that the Lo filter is affecting both outputs of the crossover. (Though I don't see the behavior of muting the wrong path now.) I don't see how to email you the files, though.
Hello J3627,
Send it to me in a DM, a Direct Message.
Mouse over my name and you should see at the bottom of the pop up window the link to send a private message.
Dave T
Hello J3627,
I think I found where the issue is. There seems to be a bug in the delay cell. You had it set for 0 samples of delay so it must be setting the pointer to grab data from the wrong memory location and the one next to it would be the other crossover output. I set it to 1 and it seemed to work well.
So give this a try. I have to run so I cannot delve into this further at the moment. I suggest you put in a MUX with a switch to set it to a delay of 0..
Here is that you have: (You see I changed it to "1")
This is what I suggest you use. Use one without slew to save on MIPS. You are low on instructions.
Notice I had moved a couple of your meters so I could see it on this page.
Dave T
OK I will add to the wiki that you can't set it to 0?
https://wiki.analog.com/resources/tools-software/sigmastudio/toolbox/basicdsp/delay actually says that the default value is 0, so that's strange that it hasn't been noticed before if it's the default...
Please log in to reply.