view new-aec-defaults @ 384:dec73b00871d

pirelli/audio-tones: call waiting tone captured
author Mychaela Falconia <falcon@freecalypso.org>
date Wed, 10 Nov 2021 02:15:27 +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.