iandcoleman

It's not the hardware per see, ALSA could certainly be improved by vendors, it's the intermediate layers that cause the problem. Android needs to enforce low latency upon vendors, and not continue to give them the easy option of avoiding it.

Android already has an aec module that you can use. It's timestamp based using the timestamp calls to ALSA to perform the cancellation

Sorry, Actually, it's 45ms. From the docs: android.hardware.audio.low_latency indicates a continuous output latency of 45 ms or less. android.hardware.audio.pro indicates a continuous round-trip latency of 20 ms or less

'low_latency' used to be sub 20ms, however 'professional' was introduced a while ago to replace this, with 'low_latency' becoming 40ms

Unfortunately, this is unlikely to improve latency on devices which already don't have 'good latency'. Reviewing the linked doc, this is a 'high level' API whos goal is possibly more about streamlining the API across multiple recent releases, while I'm sure, addressing latency as best it can. The problem is that this API still sits on top of other lower (and already existing api's) aaudio for current releases and opensles for older. A large part of Android audio latency is down to the HAL layer that each vendor provides. Andoid as a framework offers support for varying degrees of latency, but it's up to the vendor supplying the audio HAL to support this. This is exposed through the low_latency prop check (or 'professional' in recent releases). If the vendor HAL doesn't support 'low latency' through reduced buffer sizes and efficient (or no) locking etc, there's nothing a high level API like this can do, other than bypass the HAL and talk to ALSA directly, but this breaks the whole architecture.