Sigma 300 (ADAU145x) Slew Volume Rates

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?

Thanks,

EdA

     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,

     Bob

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,

     Bob

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.