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
