Bug#828190: pulseaudio fails to interact with alsa, hangs and spams syslog

[Harald Geyer]

retitle 828190 [pulseaudio] sometimes locks up
tag 828190 - moreinfo
stop

Dear Maintainer,

this report is tagged "moreinfo", but I don't see which info is
missing. AFAICS the original submitter provided everything he was
asked. Please add the tag again and clarify, if indeed some information
is missing.

Also I want to refute the theory, that this problem is mostly a bug
in the kernel driver: Everything works for me, if I use ALSA directly
instead of via pulseaudio and duckduckgo finds variants of this problem
reported on the internet related to many different drivers.

Here are my observations:

On my system audio mostly works fine for trivial things like beeps
or playing .wav files. However advanced uses (mostly VoIP software
like empathy, pidgin and baresip) cause pulseaudio to run at
100% CPU (one thread) and spam syslog with this message

Mar 31 00:19:02 teres pulseaudio[9099]: W: [alsa-source-1c22c00.dai-sun8i sun8i-0] alsa-source.c: Resume failed, couldn't restore original sample settings.

about 315 times per second.

The really fun part: After executing
pulseaudio -k; pulseaudio --log-level=4 --log-target=stderr

I can't reproduce the issue. Must be some race involved somewhere.

The system is set up with pulse as the default ALSA device. Interaction
with pulseaudio typically happens via the ALSA API.

From the difficulty in reproducing the behaviour and the content of the
message I gather, that the trigger depends on the state of the
audio HW/alsa and the properties of the audio data to be played.
Eg. Simply playing an audio file from baresip usually works fine from
a pristine state, but might fail if earlier activity caused the messages
to appear. Using "aplay" to play a .wav file might restore a working
state.

From reading [1] and [2] I understand, that mismatched sample rates
might cause such a problem. But pulseaudio should resample as needed
to avoid this. Upstream bug [3] might be related somewhat.

I focused my efforts for analyzing this problem with baresip, because it
has the most straight forward and easy to understand code. I can reproduce
this without any other audio applications running, so it really seems like
pulseaudio is stepping on its own toes. The versions in unstable and
experimental are both affected.

The code in baresip, responsible for handling audio is at:
https://github.com/alfredh/baresip/blob/be4448a54117cfd2cda69d4fc88e1c2802e8a5b6/modules/alsa/alsa_play.c#L53

If the ALSA API immediatly returns an error without blocking at all, this
code turns into a tight loop. Neatly explaining why the system hangs with
100% CPU.

I guess this code should be smarter about handling errors. OTOH I don't
see anything illegal happening there and pulseaudio should resample instead
of throwing errors, so the main problem must be with pulseaudio.

--- begin ---
static void *write_thread(void *arg)
{
        struct auplay_st *st = arg;
        int n;
        int num_frames;

        num_frames = st->prm.srate * st->prm.ptime / 1000;

        while (st->run) {
                const int samples = num_frames;
                void *sampv;

                st->wh(st->sampv, st->sampc, st->arg);

                sampv = st->sampv;

                n = snd_pcm_writei(st->write, sampv, samples);

                if (-EPIPE == n) {
                        snd_pcm_prepare(st->write);

                        n = snd_pcm_writei(st->write, sampv, samples);
                        if (n != samples) {
                                warning("alsa: write error: %s\n",
                                        snd_strerror(n));
                        }
                }
                else if (n < 0) {
                        warning("alsa: write error: %s\n", snd_strerror(n));
                }
                else if (n != samples) {
                        warning("alsa: write: wrote %d of %d samples\n",
                                n, samples);
                }
        }

        snd_pcm_drain(st->write);

        return NULL;
}
--- end ---

I might dig into this further in the coming days, but since I'm very much
not familiar with ALSA, pulseaudio and debugging threaded applications,
some help would be much appreciated.

I'm mostly writing this to tell you, that I can reproduce this issue at
will (mostly, considering I couln't get debug level logs) and can run
any tests you might need. But figuring out how to make pulseaudio
smarter about switching sample rates or how to make the debian package
detect, that alternate sample rates might not be a good idea on any given
system, is probably above my paygrade.

[1] https://pulseaudio-discuss.freedesktop.narkive.com/KCt6OOkP/testing-echo-cancellation-on-an-armhf-omap-phone

[2] https://arunraghavan.net/2011/10/alternate-sample-rates/

[3] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/374

-- 
Es gibt viele Maßnahmen gegen die Klimakrise, die leicht und ohne Verlierer
umsetzbar sind. Das Problem ist immer noch das Desinteresse der etablierten
Parteien.
https://haraldgeyer.at/Klimaschutz.html