Add microphone audio preprocessing

[brownard]

The app should try and take advantage of hardware noise suppression and acoustic echo cancellation available on Android devices to improve wake word responsiveness, e.g. when playing media or sound effects. This will help to address #20, #28, and #30.

Currently I haven't been able to get consistent results, manually enabling the processing effects doesn't seem to do anything on the devices I've tested (Samsung Galaxy S9 and Lenovo M10 Tab), instead the enabling of effects seems to only be determined by the AudioSource used by the AudioRecord. Using a source of VOICE_COMMUNICATION gives the best voice isolation but has its own issues, see comment in the debug implementation here.

[brownard]

@xvello I have pushed a test branch here that contains a minor refactor of the microphone input handling, a first attempt at manually enabling audio pre-processing (that doesn't seem to work) and a wav file writer that writes the mic audio received to a wav file in the device's shared Music directory. Note that the mic audio is buffered in memory from when the service is connected and is only written to the file when the service is manually stopped, so its not suitable for leaving running for long periods of time.

[xvello]

As I alluded to in #30 (comment), the audiofx package is only a shim to set audio driver settings, which is why I looked at audio_effects.xml on the devices. If the effect is not declared, the function calls are no-ops.

You can list available and active effects by adding this code to the bottom of MicrophoneInput.start():

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
    for (mic in audioRecord!!.activeMicrophones) {
        Timber.d("Active microphone: %s - %s", mic.address, mic.description)
    }
}
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
    for (effect in audioRecord!!.activeRecordingConfiguration!!.effects) {
        Timber.d("Active effect: %s - %s - %s", effect.connectMode, effect.name, effect.uuid)
    }
}
for (effect in AudioEffect.queryEffects()) {
    Timber.d("Available effect: %s - %s - %s", effect.connectMode, effect.name, effect.uuid)
}

If you also have access to a context, you can call AudioManager.getMicrophones(). On my A3, two microphones (bottom and back) are listed, but only the bottom one is reported as active (both in VOICE_RECOG and VOICE_COMM). I assume that this is a red herring, but the rabbit hole goes deep. I don't think going this way right now is the best use of limited resources.

• I'd be fine with the reduced speaker quality of VOICE_COMMUNICATION (would still be an upgrade over my esp32 devices' speakers). Maybe if we only set isSpeakerphoneOn on wake word activation, then turn it off on VOICE_ASSISTANT_STT_VAD_END before the TTS reply plays?
• I'd also like to have a switch to return to the old "half-duplex" setup (run the microphone capture, but drop frames until the wake sound ends, instead of buffering them). Again, that's what my current esp32 devices do, so I don't mind the delay.

What about adding a "Echo cancellation" select with options:

• None: current behaviour
• Pause: drop micorphone frames while the sound is playing (plus a small margin to account for latency & echo)
• Speakerphone: use VOICE_COMM and isSpeakerphoneOn

We can keep experimenting with other options and algorithms later

[xvello]

Long term, the solution will probably be to implement AEC (and AGC) in the application itself. Two options come to mind:

• a naive solution could be to record a "calibration" sample (play the wake sound, capture the microphone, re-record it if the speaker volume / satellite position changes) that we could subtract to the buffered audio before sending it. We'd still need some logic to compensate for the variable latency in the Android audio stack (find the first peak to align the audio before subtraction?)

• using https://github.com/theeasiestway/android-webrtc-aecm or a similar library to process the microphone input before sending it. It has the benefit of being generic on the noise, to support ask_question workflows

I don't have a background in signal processing, so there's probably better solutions out there. My personal preference would be to implement the two simple options first before we dive into more complex ones, they'll still be reliable fallback options in the future.

Might also be worth checking out a few satellite implementations and checking out how much signal processing they implement?