N-Channel RMS Compressor bug

Hi electrojim,

I tried to duplicate this failure on my hardware today, but I was unable to see the behavior you're reporting. I'm using my ADAU1781 evaluation board and the attached project. By occasionally clicking the beep button you should be able to see the attack and release pretty clearly on the level detector attached to the N-channel compressor's output. I can set the RMS T/C and Decay values to anything (even up to several thousand), and I'm not seeing a lock-up as described in your post. I can freely set the Decay value to anything I choose (ranging from 1 dB/s up to the maximum of 10,000 dB/s) and the results are as expected.

Could you maybe provide a SigmaStudio .dspproj file so I can duplicate the issue?

Just out of curiosity, does your application require very fast release times like this? In case it does, I just wanted to warn you that decay speeds over a few hundred dB/s are awfully fast and can cause artifacts when they are applied to audio signals. Basically, since the gain is being updated every sample and it is jumping by a rather large amount, steps are created in the output signal that manifest themselves audibly as zipper noise.

Hi Jim,

I'm sorry, I made a mistake when reading your original post! I can now duplicate the issue. This doesn't seem to be version-related; I simply misunderstood the problem in the first place.

It looks like the save function is not allowing the full range of values for that cell to be saved in the project file. I will report this immediately.

It looks like the proper values are exporting in the project files and compiler output, so the temporary workaround would be to just make sure you double-check the GUI values before you generate your build.

Hi, Brett,

Thanks for the reply and advice. I'm well aware of the hazards of too-quick time constants in limiters, my setting of a very fast release was excusable because I was using other modules for envelope following.

I opened your circuit on my computer and, sure enough, your compressor had a Decay rate of 120dB/s. I changed this to 500dB/s, the same as your RMS TC (attack) rate, closed the project and reopened it; sure enough, the box I'd set to 500dB/s was now 120 again.

If this is not happening for you, perhaps I have a 'bug' in my computer, or perhaps my download of the Sigma software is somehow corrupted. Are you using the same version as I am: Version 3.1 Build 20 Rev 375? Maybe this is something that got fixed since I installed.

Anyway, I have attached my limiter circuit; there are some notes attached as Comments.

Jim

Thanks, Brett;

At least I know I'm not going nuts... although others at work may still have their doubts. This issue shouldn't be a problem in the final product, as long as we're dumping the setup to the chip at each boot.

Jim

Hello Jim,

I tried the RMS compressor in Version 3.92 -- now the TCs max out at 8686, but save and load properly.

Bob

I note again, now 3 years later, that this continues to be somewhat of an issue in Sigma 3.8, albeit not to the extent originally reported in 2010.

Say you want to use an RMS compressor with a separate control input as a near-instantly-responding device, depending on actual time constants established by a separate envelope follower. So you set the compressor TC to 10000 with a decay rate of 10000. First you find that those boxes don't want to accept those numbers, and it might take several tries to get those numbers to 'stick.' Once they're in there, however, they do remain, so long as the project is open. Close the project and reopen it, and you'll find those numbers have changed to 8686. This is still a respectable slewing rate, but is it for real, I wonder?

Thanks, Bob,

I'll make a note that 8686 is the new 10000... certainly close enough for rock music!