# HG changeset patch
# User Mychaela Falconia <falcon@freecalypso.org>
# Date 1627552130 0
# Node ID 754be25cd6a03d54de1ee87f73990bb461ab3868
# Parent  0f9606d1f8b861b769d7ffe912054d7288231a97
new-aec-defaults: read out from the DSP

diff -r 0f9606d1f8b8 -r 754be25cd6a0 new-aec-defaults
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/new-aec-defaults	Thu Jul 29 09:48:50 2021 +0000
@@ -0,0 +1,29 @@
+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.