>On Fri, Jul 15, 2022 at 05:39:22PM +0800, Velicheti Sita wrote: >> On Fri, Jul 15, 2022 at 02:30:05PM +0800, Velicheti Sita wrote: >> >> > We are running pulseaudio 15 and during playback through paplay, pulseaudio is >> > exiting with assertion failed. >> > >> > >> > Error is like below: >> > >> > D: [alsa-sink-Swmixer7 playback Pulse audio pcm6-6] alsa-sink.c: >> > snd_pcm_writei: Resource temporarily unavailable >> > >> > E: [alsa-sink-Swmixer7 playback Pulse audio pcm6-6] alsa-sink.c: Assertion 'err >> > != -11' failed at ../git/src/modules/alsa/alsa-sink.c:512, function try_recover >> > (). Aborting. >> > >> > Aborted >> > >> > >> > This error exists even after adjusting the fragment size and fragments. >> > >> > >> > It's working normally in pulseaudio version 9. >> > >> > >> > FYI after commenting the assert in alsa-sink.c line no 512, playback and all >> > other functionality works fine. >> > >> > >> > module-alsa-sink is loaded in system.pa as below: >> > >> > load-module module-alsa-sink device=hw:0,6 mmap=0 sink_name=pcm_output >> > fragment_size=4096 tsched=0 fragments=2 >> >> Can you describe more about what your platform / OS / hardware is? There >> was another post on this list recently comparing pulse version 9 to 15 >> from someone with an email at the same domain. I'm guessing that more >> than just the pulse version has changed in your comparison. >> >> I had a look at the assertion that's firing, and none of the code >> in that area has changed between pulse version 9 and 15. What seems >> to be happening in the code is that ALSA reports that sufficient buffer >> space is available, then returns EAGAIN when pulse tries to write into >> that buffer. This shouldn't happen, hence the assertion. >> >> Can you try running pulse with the log level set to debug and report the >> output? There's a condition in the code where a buffer size is guessed >> at instead of trusting the returned value from ALSA, and there should be >> a corresponding log message for this. > Please find attached logs for reference. Just as I suspected, this is present in your logs: > E: [alsa-sink-Swmixer8 playback Pulse audio pcm7-7] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write. > E: [alsa-sink-Swmixer8 playback Pulse audio pcm7-7] alsa-sink.c: Most likely this is a bug in the ALSA driver 'mlp_alsa'. Please report this issue to the ALSA developers. > E: [alsa-sink-Swmixer8 playback Pulse audio pcm7-7] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. This is probably a bug in the ALSA driver for your particular sound device. As the above message suggests, you should probably take this issue to an ALSA mailing list. --Sean
