[pulseaudio-discuss] pa_simple_write blocks too long

Tanu Kaskinen tanu.kaskinen at linux.intel.com
Wed Aug 6 05:27:05 PDT 2014


On Thu, 2014-07-31 at 19:46 +0000, Stossel, Darrell
(Insight/CSBU/RGS/Tucker) wrote:
> I’ve been tasked with migrating our project from using two different
> sound libraries to use only pulse.
> 
> I’m stuck with 0.9.21 on RHEL6 as the release because too many
> customers are on this version to force a migration.
> 
>  
> 
> With this version, the asynchronous version I’ve found to be too
> unreliable. Asserts get thrown about 5% of the time for conditions
> that should not be true, even when using example code on the pulse
> site.

Can you point out which example code is crashing, and what is the
failing assertion?

> So, I’ve gone to the simple api. Outside of our product, I’ve gotten
> both the record and play versions to work. Inside our product, the
> record part works fine. However, the playback version blocks in
> pa_simple_write (the first write when the buffer is made small, once
> full in a large buffer) with no sound ever being played. I’ve tried
> setting the buffer attributes to different settings with no success.
> Using pacmd, both the sink and the sink input are shown in the running
> state. No other applications are using audio at the same time.

If you do try to play to the same sink with some other application, for
example paplay, while your own application is stuck in
pa_simple_write(), does that other application work? I don't see any
other reason for pa_simple_write() getting stuck on a running sink than
the sink getting stuck. What kind of sink is it? Alsa?

-- 
Tanu




More information about the pulseaudio-discuss mailing list