Post Go back to editing

Compressor RMS Hold

Category: Software
Product Number: ADAU1701
Software Version: SigmaStudio 4.7

Hi,

I would like your help to find a solution for the inappropriate behavior of the RMS compressor that I am using on the ADAU1701.

The block used is: Dynamic Processors -> RMS -> Full Range (-90 to +24 dB) -> No Post Gain -> Mono -> No Ext Detector Input -> RMS (no gain)

The compression curve: As a limiter.

The problem is related to the hold time. It does not have a constant behavior.

For example, it was configured for 100ms, but each time the limited signal falls below the threshold and the hold time starts to be counted,
it is observed that the total hold time varies to less time value, but never exceeds the configured value (100ms).

It seems to me that the internal variable of the algorithm is not reset.

To perform these tests, I am using a 1kHz audio source that changes the amplitude from 100% to 50% every 500ms;

If anyone can simulate it, I would be immensely grateful.

Thank you.

  • More test conditions:

    RMS TC: 174dB/s

    Hold: 100ms

    Decay: 43dB/s

  • Hello fkan,

    You said:

    To perform these tests, I am using a 1kHz audio source that changes the amplitude from 100% to 50% every 500ms;

    What do you mean by 100%? 

    What is your audio source?

    It would be good to see your project so we can see the curve and any other settings you may have. 

    Thanks,

    Dave T

  • Hello Dave, I hope you are well!

    It is an analog audio source, where at the ADC input we have cycles of 1VRMS for 500ms and 0.5VRMS for another 500ms.


    The test involves only the input signal coming from the ADC + this compressor block + DAC.

    I notice that the higher the attack speed(dB/s) (i.e., the shorter the total attack time (ms)), the variation in this issue with the hold time in practice is more noticeable.

    Thanks,

  •      Hello Dave and fkan,

         This issue is new to me, yet it appears to be real.  My test project is pictured below and attached:

    Although the Real-Time Display demonstrates this result, it appears better on a scope.  I used somewhat faster TC and Delay settings to make the pictures show better, yet adjusting these had little effect.  I caught these correct and too-short hold times below:

         It's my understanding that the Hold Time's purpose is to prevent ripple from the RMS or Peak detector from modulating the gain and thus distorting the audio.  Thus, when set up properly, these compressors are virtually distortion-free.  I usually set the Hold Time for half the period of the lowest bass frequency -- for example, 25 mS for 20 Hz.  Yet, the Hold Time should work properly regardless of its setting.

         Anyway, I hope my input will save time for everyone.  Over the (many) years I've noticed that when those needing help attach their project files, answers come quicker and better.  NevadaMark's excellent post is good advice for anyone asking a question on EZ.

         Best regards,

         Bob

    RMS-compress.zip

  •      On a hunch, I tried a modified version of the test circuit.  In this version, while the sine wave is at its high level, it also increases imperceptibly during this time.  A counter increases the test signal's amplitude by two LSBs each period (1 mS) of the sine wave.  As a result, the compressor always sees a new higher level.

    RMS-compress-rising-hold-test.zip

         With the Ramp switch in the Off position, it holds the Counter's Reset pin high, disabling the ramp.  In this case, the scope shows a random Hold time as before. Switching the Ramp switch to its low 'ON' position, and the ramp operates as described.  Then we see a constant 100 mS Hold every time!  This is another example of how SigmaStudio can troubleshoot itself, as brought out in Dave's video.

         From this test, it appears that the Compressor needs to measure a higher input than it has ever seen previously in order to restart its Hold timer.  In actual practice with program material that fluctuates in level, this shouldn't be an issue.  Perhaps fkan has another application in mind where it would matter.  I also tried a workaround using an External Sense Input compressor, where I dithered the external input with noise, but this didn't work for me.

         Best regards,

         Bob

  • Hi KJ,

    Thank you for the test sequence! This helped us better understand the implementation of the algorithm.

    Yes, in real-life this random behavior should not occur.

    The only question is regarding comparative tests between final products.

    Compressor's tests use this type of sinusoidal signal oscillating between two fixed amplitudes.

    Can the AD development team evaluate a possible improvement?

    Best regards,

  • Hello fkan,

    I think I see what the issue might be? Thanks for all your great analysis on this. I agree that with real world signals it would not be as much of a problem. 

    I am guessing here, I do not have access to the code to see. But it seems like with a steady state sine wave generated from a "perfect" DSP oscillator the peak level will not differ. So it records the peak level and then starts to count down the hold time. It does not see another peak greater than the last recorded peak so it does not restart the counter. Therefore it will count down the hold time and then finally see a new peak and start over.

    So then once you randomly lower the level the length of time before you see the release will be random. 

    This is a subtle bug that as a programmer I can see can be easily missed. I think the solution would be to have the recorded peak level decay a little each sample period. Then it would see the next sine wave peak as a new peak and reset the timer. However, this might then have other consequences. 

    Then if the level were going down gradually, and you had a long hold time then it would constantly be reset and the release time would never be reached. The gain would go down and down and never fully finish the hold time but then the threshold would eventually be reached and the hold time would stop and the release begin. This requires some thought. 

    In the old analog days this was not an issue. There was no such thing as a hold time! I have designed a few analog compressors in my days. In a way, I could argue that this is the way an analog compressor works. The peak level is integrated and if it goes down slowly so does the peak threshold. If the sine wave stays at the same level it just recharges it the little bit it discharged. But, this is the decay involved not a hold. So setting the hold time to zero would make it behave as an old analog compressor. 

    Maybe the solution is if the peak level is less than OR equal to then reset the timer! Bob did try some dither and I would have thought that would help but apparently not. We probably have a window programmed in so factor out the noise! I will inquire with the programmers but they are rather busy working on SS+ so I would not expect anything in the near future. This would be a low priority. Well below the threshold. Ha! 

    I will give this some more thought to see if there is another creative solution either using an external sidechain input or writing to the peak parameter to reduce it by a small amount each sample period?

    Thanks for the great discussion.

    Dave T 

  • Maybe the solution is if the peak level is less than OR equal to then reset the timer!

         Yes, this would likely make the test case which fkan mentioned work.  And it should be trivial to for the programmers to implement.

  • Hi Dave and Bob,

    I appreciate and thank you for the time you took to understand the case.

    Can we create a ticket to follow up on this case and get some feedback from programmer team?

    An improvement analysis and a deadline for implementation would be of great importance for our applications that involve the family SigmaDSP, including this behavior also occurs in other partnumbers (eg. ADAU145x).

    Thanks

  • Hello fkan,

    I did submit a report about this. Getting this updated is a bit complicated to describe. I can see your info due to my forum permissions so contact Juliano and lets get some dialog going off-forum. 

    This issue is more of an issue with the testing methodology because in the real world the audio level will never stay that steady to cause the timer to look like it is changing values. Try a short burst that is longer than the attack time but not by more than a cycle or two and then lower the level and you should see it be consistent from the first cycle to reach the max level after the attack time. 

    The programmers did see it. I had to explain it for a bit then they understood the problem. They have not opened the code up yet to see how easy but I think changing the test to be greater than or equal to will solve the problem and be easy to do. 
    The big issue is when SS Rev 4.7 might be updated. We are focusing on SS+ at the moment. So let us discuss this off line to see what can be done for you. We value your business. 

    Thanks,

    Dave T