FreeCalypso > hg > freecalypso-reveng
view new-aec-defaults @ 375:6057c98d11a9
pirelli/audio-modes capture
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 31 Jul 2021 10:18:34 +0000 |
parents | 754be25cd6a0 |
children |
line wrap: on
line source
In the transition from the oldest AEC (the one before L1_NEW_AEC) to the one implemented in DSP ROMs 3416 and 3606 (the one corresponding to L1_NEW_AEC, but not the later LoCosto changes), 8 new parameter words were added to the DSP's NDB page. When L1_NEW_AEC is enabled in the fw build, these parameters must be set by whichever entity enables and configures AEC - so far, so good. But what happens if L1_NEW_AEC is set to 0 (as in TI's shipping TCS211) and the fw tries to configure AEC the old way? To find out, I did this: fc-tmsh r16 ffd0084a 8 It's a read directly from the DSP NDB page - and here is the result: r16: 0000 0001 7FFF 1FFF 4000 0032 1000 1000 Decoding: continuous_filtering = 0 granularity_attenuation = 0x0001 smoothing_coefficient = 0x7FFF max_echo_suppression_level = 0x1FFF (AUDIO_MAX_ECHO_12dB) vad_factor = 0x4000 absolute_threshold = 0x0032 factor_asd_filtering = 0x1000 factor_asd_muting = 0x1000 I can only guess that these NDB words must be initialized by the init code path of the DSP ROM, as nothing on the ARM side writes anything at all - the corresponding API word definitions are excluded from T_NDB_MCU_DSP in l1_defty.h (replaced with a_new_aec_holes[12]) when L1_NEW_AEC is 0.