Post Go back to editing

ADAU1452 Detecting the end of a slew-rate limited mute transition

Category: Software
Product Number: ADAU1452
Software Version: Sigma Studio 4.6

Hi.  I have a mute block with a custom slew type (0xAAAA), which gives me a slow fade to mute over about two seconds.  Rather than hard-coding the transition time in the MCU, I'd rather get this information from the DSP.  My current approach is to read the mute block's gain value.

What I've found is that the gain value is not exposed directly in the PARAM.h header.  The documentation for the Mute block (here) indicates that I should have a MOD_<block_name>_MUTE1_ALG0_MUTEONOFF_ADDR definition, but that's unfortunately not the case.  MUTE_ADDR and SLEW_RATE_ADDR are provided, neither of which change when I mute this block.  There is, however, a 4-byte gap between the preceding block's address (also a mute block) and the first address of the mute block I care about.  If I read this, I get the slewing gain value.

I can add the gain value to the indirection parameter access table and read it using this address, but I'm a bit hesitant to do so as the value isn't available directly.

So, I have two questions, then.  As the mute block's gain is not exposed through the normal API, is it safe to be reading it, and is it guaranteed to behave as expected?  Also, stepping back a bit, is there a better way to indicate to the MCU that the mute block has completed ramping to its final value?

Excerpt from PARAM.h (MOD_MUTEWITHFADE is the mute block I care about):

/* Module MasterMute - Mute*/
#define MOD_MASTERMUTE_COUNT                           2
#define MOD_MASTERMUTE_DEVICE                          "IC1"
#define MOD_MASTERMUTE_ALG0_SLEW_MODE_ADDR             761
#define MOD_MASTERMUTE_ALG0_SLEW_MODE_FIXPT            0x0000208A
#define MOD_MASTERMUTE_ALG0_SLEW_MODE_VALUE            SIGMASTUDIOTYPE_INTEGER_CONVERT(8330)
#define MOD_MASTERMUTE_ALG0_SLEW_MODE_TYPE             SIGMASTUDIOTYPE_INTEGER
#define MOD_MASTERMUTE_ALG0_MUTE_ADDR                  762
#define MOD_MASTERMUTE_ALG0_MUTE_VALUE                 SIGMASTUDIOTYPE_8_24_CONVERT(0)
#define MOD_MASTERMUTE_ALG0_MUTE_TYPE                  SIGMASTUDIOTYPE_8_24

/* MOD_MASTERMUTE_ALG0_MUTE_ADDR + 1 seems to correspond to MOD_MUTEWITHFADE_ALG0_MUTEONOFF_ADDR */

/* Module MuteWithFade - Mute*/
#define MOD_MUTEWITHFADE_COUNT                         2
#define MOD_MUTEWITHFADE_DEVICE                        "IC1"
#define MOD_MUTEWITHFADE_ALG0_SLEW_MODE_ADDR           764
#define MOD_MUTEWITHFADE_ALG0_SLEW_MODE_FIXPT          0x0000AAAA
#define MOD_MUTEWITHFADE_ALG0_SLEW_MODE_VALUE          SIGMASTUDIOTYPE_INTEGER_CONVERT(43690)
#define MOD_MUTEWITHFADE_ALG0_SLEW_MODE_TYPE           SIGMASTUDIOTYPE_INTEGER
#define MOD_MUTEWITHFADE_ALG0_MUTE_ADDR                765
#define MOD_MUTEWITHFADE_ALG0_MUTE_VALUE               SIGMASTUDIOTYPE_8_24_CONVERT(0)
#define MOD_MUTEWITHFADE_ALG0_MUTE_TYPE                SIGMASTUDIOTYPE_8_24
Parents
  • Hello JBTeufel,

     Sorry for the delay in response.

    Yes, You can get the gain address by subtracting the SLEW_MODE_ADDR by one . The reason it's not given in the exported files is , It's not a parameter which is really used. People don't really need to get that value for any reason. So it's not given in the files. Please don't try to write to it, It will affect the slew transition. However, you can read the value for your application no problem with that. But it's very hardly used parameter.   

    Regards,

    Harish

  • Thanks Harish,

    To add a bit to my question, I'd like to fade to silence, swap audio sources, then ramp back up to normal volume.  In my application, the source switch is external to the DSP, so I'd need to coordinate with the MCU for this.  Polling the gain address and changing sources when it's set to zero was my first approach, but it sounds like it's not a common use case at all.  I'm quite new to DSPs, so please forgive my ignorance, but is there another way for the DSP to synchronize this operation with the MCU?

     - Jason

  • Hello Jason, 

    Let me jump in here and ask for some more details. ( Excuse me Harish) 

    Do you need to actually go all the way to zero audio output then start raising the other source?

    We have a crossfade block that will crossfade between one input and another. The difference is that both can be heard at the same time as the crossfade is in the process of switching. If the slew/fade time is fairly quick it is not a problem but if it is a long several second fade, then it is not very pleasing. 

    It can be done to lower one then raise another. I just have to think about how to do that. I think I can setup a GPIO to do this for you so the MCU would not have to be directly involved.

    Dave T

Reply
  • Hello Jason, 

    Let me jump in here and ask for some more details. ( Excuse me Harish) 

    Do you need to actually go all the way to zero audio output then start raising the other source?

    We have a crossfade block that will crossfade between one input and another. The difference is that both can be heard at the same time as the crossfade is in the process of switching. If the slew/fade time is fairly quick it is not a problem but if it is a long several second fade, then it is not very pleasing. 

    It can be done to lower one then raise another. I just have to think about how to do that. I think I can setup a GPIO to do this for you so the MCU would not have to be directly involved.

    Dave T

Children
No Data