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.

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

Regards'

Hermione

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

PDF 

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.