ADAU1452
Production
The ADAU1452 / ADAU1451 / ADAU1450 are automotive qualified audio processors that far exceed the digital signal processing capabilities of earlier SigmaDSP...
Datasheet
ADAU1452 on Analog.com
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 https://ez.analog.com/message/156092#156092
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?
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
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
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.