Re: Playback via alsa sink in pulseaudio 15 fails with assert failed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please find attached logs for reference.

---------- Original Message ----------

From : "Sean Greenslade" <sean@xxxxxxxxxxxxxxxxxx>
To : "General PulseAudio Discussion" <pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx>
Cc : Velicheti Sita Research Engineer(velicheti.sita)
Date : 2022/07/15 13:19:13 [GMT+05:30]
Subject : Re: [pulseaudio-discuss] Playback via alsa sink in pulseaudio 15 fails with assert failed


On Fri, Jul 15, 2022 at 02:30:05PM +0800, Velicheti Sita wrote:
> Hi,
> 
> 
> 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.

--Sean


Attachment: PA_LOGS.txt
Description: Binary data


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux