Post Go back to editing

Sigma 300 (ADAU145x) Slew Volume Rates

     Slew volume controls can filter noisy control inputs and minimize clicks.  Often the desired slew rate can be found by experiment.  However, in some applications it would help to know the actual slew rate a given setting yields.  For example, the ADAU1701's slew rates are described at

    The -1452's slew volume controls are different (and more versatile) than those of older SogmaDSPs,  There's separate rise and fall settings, each with several curves to choose from.  The "RC" curve setting shown here provides slewing similar to that of the older slew volume blocks, thus the slew rates can be measured the same way (see the post cited above).  Although this RC curve is exponential in nature (it follows the RC characteristic that includes the term e^(-t/RC), the -1452 slew block also offers a separate exponential choice. Testing the -1452's RC slewing this way results in the table below.  Slew times are given as a time constant as well as the dB/s rate often specified for SigmaDSP dynamics processors.

The Sigma 300's Exponential slewing operates in ways both similar to, and different from, the RC slewing.  The post at Sigma 300 (ADAU145x) Exponential Slewing describes the differences.

    Linear slew settings yield these 10 -- 90 % rise and fall times.  If you prefer 0 -- 100 % times, multiply these times by 1.25..

  • This information is quite useful when using SigmaStudio, but I am trying to decipher the slew rate/mode so that I can set them using registers under program control.   I can't seem to find any information in the literature or web site regarding the format for this data word.  I am using the ADAU1452.

    According to a test file I have created, I have a single volume control (Single 1) which is set up to use HW slew.  In the PARAMs data file, here what it shows:

    Cell Name         = Single 1

    Parameter Name    = HWGainADAU145XAlg2slew_mode

    Parameter Address = 55

    Parameter Value   = 8320

    Parameter Data :

    0x00, 0x00, 0x20, 0x80,

    The slew mode is currently set as Linear.  When set to RC, the value is 8330 (0x208A) and when set to Const DB the value is set to 8325 (0x2085).  That's all I've been able to glean so far.  Can you provide some additional insight on the format for this data word?



  •      Hello,

         Yes, I checked the Wiki and found not even the GUI slew rate info I had worked out, let alone anything about uC control of this very useful block.  So it looks like we'll have to figure this out on our own.  You're on the right track with your trying different settings while noting the resulting four-byte parameter register value.  Rather than viewing the PARAMS.dat file after each change, you can get immediate feedback from the Capture Window:

         With the default linear slew modes as shown, setting "1" in first the rise and then the fall boxes caused the parameter words shown in the Capture Window.  Based on this and a few additional trials, I concluded that the linear slew settings appear like this:

         In accord with the extent of the runtime adjustments your system requires, you can work this method to deduce what register values correspond to the GUI settings.  Sorry that you need to reverse engineer these parameters!

         Best regards,


  • It's pretty silly indeed we have to reverse engineer this to obtain decent documentation.  Anyhow, here's my contribution: it seems to be (starting with the lsb) 2x 2-bit slew type and 2x 6-bit value, although e.g. linear type only uses value range 0-15.  Type 0 is linear, type 1 is const db, type 2 is RC.

    Linear slew adds/subtracts the following amount each audio sample:

        hex   decimal
    0  ca63  51811
    1  a0c3  41155
    2  7fb2  32690
    3  656f  25967
    4  5092  20626
    5  4000  16384
    6  32d6  13014
    7  2862  10338
    8  2013   8211
    9  197b   6523
    10  143d   5181
    11  1013   4115
    12   cc5   3269
    13   a25   2597
    14   80f   2063
    15   666   1638
  • And those numbers turn out to be round(0x4000 * exp10(0.5 - 0.1*value)) exactly.

  •      Thanks for expanding the SigmaDSP knowledge base.  Did you know that anyone can edit the SigmaStudio Toolbox [Analog Devices Wiki] -- although I've only done it on rare occasions, as it's easier to just post my findings here in Engineer Zone.  As for the evident need for reverse engineering for self-documentation -- this appears to be an industry trend.  My otherwise excellent C compiler comes with docs so bad that my only way to understand a function is to try it out and play until it works.

         Best regards,


  • Next chapter: constant dB

    As expected this basically multiplies the value by some constant each frame until it reaches the endpoint, specifically by 1+δ when rising or 1-δ when falling. (Note that this implies it falls a bit faster than it rises for any given parameter value.) The values of δ for slope parameter values 0...63 are easiest to express in binary:

     0  0.00011
    1  0.000101
    2  0.0001001
    3  0.0001
    4  0.000011
    5  0.0000101
    6  0.00001001
    7  0.00001
    60  0.00000000000000000011
    61  0.000000000000000000101
    62  0.0000000000000000001001
    63  0.0000000000000000001

    Based on limited testing it appears the exact update is:

    x = x + max( floor( δ * x ), 1 )  when rising

    x = x - floor( δ * x ) - 1  when falling (this is wrong, see later post)

    until the target value is reached of course.

  • After further testing I found my description of constant-dB slew was not yet quite accurate in all cases. I've tried to capture the fine details into a small piece of python code that simulates the slew peripheral. I've also added support for negative numbers, and mostly-correct support for RC slew. Since I don't really care about RC slew much I think I'm going to consider the slew peripheral "sufficiently clarified" for now ;-)  Of course I'd still be happy to receive and apply patches that close the gap between my simulator and the real thing.

    I've put the script here on github.

  • FormerMember
on Feb 22, 2021 3:53 PM

Dear Bob,

Is there any formula to derive time in milliseconds from the slew rate ? There does not seem to be any fixed pattern or differences between consecutive slew rates and their corresponding time in ms

Also how is amplitude reduced or increased (by a factor of what) for say each setting of the slew rate value



  • Hello All,

    I think it is time to post the details of the hardware slew engine in the Sigma300/350 processors. 

    This is what I have for information.

    Dave T


  • Time to slew depends on slew rate and how much distance it has to go (on linear scale or in dB depending on slew mode).

    The meaning of the various slew rate setings wasalready elucidated in this discussion thread, culminating with my last reply in 2018 that has a link to a python script that accurately emulates the slewing behaviour of the ADAU145x, which can therefore also be used as an unambiguious form of documentation / specification.  I fixed the remaining issue last year (it now simulates the chip bug that occurs when using RC slewmode when the distance from current value to target value does not fit in a signed 32-bit integer) and with that update it is now perfectly emulates the hardware as far as I can tell.