AEC Reference Is the Far-End Signal, Not Another Microphone
Echo cancellation only has a useful reference when the reference represents what the loudspeaker actually played.
TOPIC
Lessons, explainers, experiments, and implementation notes.
Echo cancellation only has a useful reference when the reference represents what the loudspeaker actually played.
Network packets arrive when the network allows; speakers need samples when the audio clock demands them.
Every extra buffered frame trades conversational responsiveness for tolerance to arrival variation.
A processor that removes noise can also remove speech detail when its assumptions do not match the signal.
Prove clocks, framing, routing and gain before judging microphones, speakers or enclosure acoustics.
The physical capture clock and the network codec did not run at the same sample rate.
The downlink could be packet-complete and still sound gritty or artificial after conversion to the physical playback rate.
AEC was implicated in several symptoms, but disabling it permanently would remove a required speakerphone function.
The device received media in repeating bursts that looked like a local queue or I2S starvation problem.
Asterisk was configured for 20 ms media timing, yet packet forwarding arrived in scheduler-sized bursts.
A long-running packet tool looked suspicious, but removing it did not fully restore 20 ms scheduling.
Packet loss, reordering and burst arrival can sound similar but require different fixes.
After server cleanup, Asterisk forwarding became fast, but conversation still felt delayed.
Engineering time was being spent chasing tens of milliseconds in firmware while the media route crossed Bangladesh and Ohio twice.
Later queue, PLC and timer experiments looked more sophisticated on paper but repeatedly introduced crackle, echo or additional delay.
A rebuffer/AEC/volume experiment produced obvious bad crackle instead of the intended stability improvement.
A working phone is not a release unless the exact artifact and source context can survive the next experiment.
A call can sound excellent for thirty seconds while two media clocks slowly walk apart.
Field feedback described the speaker as very tinny even though the digital call path was working.
One strong call can prove a candidate is promising but not that it is ready for manufacturing or field release.
Robotic speech, cutouts, lag and echo initially collapsed into one vague complaint called bad audio.
Later experiments had changed queues, PLC, timing and logs until nobody could safely say which behavior belonged to the last clear build.
It was tempting to use server packet timing as proof of the complete mouth-to-ear delay.
Words like robotic, delayed and crackly were useful user reports but poor root-cause evidence.
An I2S Mode1 conflict warning looked suspicious enough to become a candidate explanation for crackle.
Fast-moving firmware work made it easy for an attractive theory to become remembered as fact.
The firmware sounded worse while producing the very diagnostics intended to explain it.
Crackle and cutouts needed a device-side timing metric that was closer to the DAC than packet arrival.
RTP arrived in bursts even when packet sequence was mostly healthy, so directly pacing I2S from receive callbacks made network jitter audible.
A large first callback-to-speaker delay suggested work was accumulating between RTP reception and physical output.
After digital timing became stable, echo increased at high speaker volume and could no longer be treated as only a network or queue problem.
Increasing jitter tolerance seemed like the obvious response to bursty packet arrival.
Echo tuning was meaningless if the AEC reference did not represent what the loudspeaker actually played.
Codec detection alone did not prove the capture channels meant what the DSP assumed they meant.
The AEC library consumed a block size that did not divide evenly into the telephony frame size.