[pulseaudio-discuss] Testing echo cancellation on an armhf OMAP phone

[Neil Jerram]

Tanu Kaskinen <tanuk at iki.fi> writes:

> If you haven't configured the sample rate of module-echo-cancel, then it
> will default to 32 kHz (I don't know why), which indeed will cause
> unnecessary resampling just as you described. If the hardware runs at 48
> kHz, then I think it's best to pass "rate=48000" to module-echo-cancel.

Thanks, I'll try that.

>> Now - still with src-linear - if I try the parecord line at the same
>> time as the playback, the log goes crazy with umpteen rapid repeats of:
>> 
>> Dec 17 21:04:34 neo pulse.sh: I: [alsa-source] alsa-source.c: Trying resume...
>> Dec 17 21:04:34 neo pulse.sh: I: [alsa-source] alsa-util.c: Trying to disable ALSA period wakeups, using timers only
>> Dec 17 21:04:34 neo pulse.sh: I: [alsa-source] alsa-util.c: Device hw:0 doesn't support 44100 Hz, changed to 48000 Hz.
>> Dec 17 21:04:34 neo pulse.sh: I: [alsa-source] alsa-util.c: ALSA period wakeups disabled
>> Dec 17 21:04:34 neo pulse.sh: W: [alsa-source] alsa-source.c: Resume failed, couldn't restore original sample settings.
>
> Are only these five lines repeated? I don't understand why this would be
> looping, maybe setting the log level to more verbose would reveal the
> reason.

Thanks; if I keep seeing this, despite the following help, I'll try to
get a better log.

> Anyway, looping or not, the reason why you can't get anything recorded
> is that the source fails to resume from suspended state. If this happens
> only when playback is happening at the same time, it suggests that
> initially, when playback was not active, the source successfully opened
> the device with 44100 sample rate, at which point the rate got locked in
> pulseaudio (I think pulseaudio could be fixed to not do that). When
> playback is active (presumably at 48 kHz), the hardware doesn't anymore
> support capturing at 44.1 kHz, so when pulseaudio tries to open the
> device with the old rate, it doesn't work anymore.
>
> You can fix this by setting the default sample rate to 48000.

I'm still a bit confused on the detail here, but I think I understand
the principle of what's happening now.  Presumably there's something I
can find inside pacmd that will tell me what the current locked-in rate
is?  I'll check for that, and also try changing default sample rate as
you suggest.

Now, as I wrote in my reply just now to Arun, I realise that I really
want my in-call audio to run entirely at 8000.  Does that mean that I
need to modify your advice above to:

-  load-module module-echo-cancel rate=8000

-  default-sample-rate = 8000

If I did that, should I then expect the microphone sink to be detected
and used at 8000?  (Currently it's initially detected at 44100.)

Many thanks,
     Neil