Integration of echo-cancelling

[dr-ni]

Do you think you can integrate an echo-cancelling option for hfp ofono?

There is already a very well working speexdsp example for mono raw audio files:
https://github.com/xiph/speexdsp/blob/master/libspeexdsp/testecho.c

The example

./testecho ~/local_mic_recording.raw ~/incomming_bluealsa.raw ~/outgoing_to_bluealsa.raw

is working pretty good:

incomming_bluealsa is completely removed from the recording mixture. However, smaller stream-frames for real-time-processing will not allow to remove all incomming_bluealsa if not in sync - but should be possible at all.

I used https://github.com/voice-engine/ec.git and https://github.com/voice-engine/alsa_plugin_fifo.git to write out the necessary files (playing audio incomming_bluealsa and recording local_mic_recording - all with 16 kHz sampling-rate and recording at the same time). The ec tool is somehow working but there are some problems - maybe mixing up stereo and mono. And the used alsa configuration is not very practical because ec is closing after stopping the recording and the LOOPBACK device is blocked. After stereo to mono conversion of all output of ~/ec/ec -i plughw:1 -o plughw:1 -d 200 -s and running testecho the resulting audio is much better than using ec directly.

[arkq]

To be honest I'm not sure whether AEC should be a part of bluealsa itself. The case is that the BlueALSA service should be treated as a sound card with many PCM devices (playback and capture). It is not a telephony application. One can build a telephony-like application on top of bluealsa - using it as an audio backend for mic and speaker (in the same way a standard audio card would be used). Do you know of any sound card which has build-in echo cancelation? If there are sound cards like that, maybe we can try to mimic such solution in BlueALSA service. But for now, I'm not sure how it should work from the user point of view - BlueALSA service might have many capture PCMs and many playback PCMs...

[borine]

I think echo cancellation is a function that is applied to the stream from the local microphone, not the remote bluetooth one. It should be performed by an application that handles the local microphone and speaker (or by the local soundcard that produces/consumes those streams). So I think that the bluealsa daemon would be the wrong place for this function. (Remote echo cancellation would be performed by the remote host before sending the stream to bluetooth - so the bluetooth stack has no part to play in this function).

[arkq]

I think echo cancellation is a function that is applied to the stream from the local microphone, not the remote bluetooth one.

It all depends how BlueALSA is used - what kind of setup we are talking about. Because remote Bluetooth device might be a local device, e.g. BT speaker. So, echo cancelation will be done on a "local" BT device, and audio from the BT speaker mic will be transferred over VoIP. Anyway, I do agree that it's not a BlueALSA job to perform echo cancelation, but rather an application which is using PCM audio device.

[dr-ni]

Hi again, and sorry for my late answer.
Of course AEC is a local sound problem. And you are totally right that it is not directly related to bluez-alsa. However, I have now managed to hack in a little proove of concept tool - and it hasn't been showing so much effort to build. So may be an option for you to include such a small tool?

https://github.com/dr-ni/aec_cmdline.git

Such tool can be easily used with files:

aec_cmdline < infile.raw > outfile.raw

or in combination with bluez-alsa arecord and aplay:

arecord -f S16_LE -D bluealsa | aplay -D mloopplay -f S16_LE -r 16000

and

arecord -D aec_internal -f S16_LE -c 2 -r 16000 | aec_cmdline | aplay -D bluealsa

The tool is reading a stereo track, holding the local recording on the left and the parasitic reference signal (here bluealsa remote) on the right. The required input stereo track is being supplied from a loopback device as described in:

https://github.com/SaneBow/alsa-aec.git

Cheers Uwe

[dr-ni]

Update:
Now for 8000 Hz mono_mloopplay and stereo_mloopplay support (prior 16 kHz stereo mloopplay only, see my new 50-aec.conf and changed sampleRate in aec_cmdline.c)

So

arecord -f S16_LE -D bluealsa | aplay -D mono_mloopplay -f S16_LE -r 8000

and

arecord -D aec_internal -f S16_LE -c 2 -r 8000 | aec_cmdline | aplay -D bluealsa -f S16_LE -c 1 -r 8000

should now be working with ofono