[pulseaudio-discuss] Playback via alsa sink in pulseaudio 15 fails with assert failed
Sean Greenslade
sean at seangreenslade.com
Sat Jul 16 19:03:38 UTC 2022
>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
More information about the pulseaudio-discuss
mailing list