The assertion problem was my fault. I kept missing the fact that my threaded main loop start was one line earlier - bad paste job.
The hanging issue now shows up frequently even in the non-simple api. It may be a configuration issue. Paplay hangs also if it is started after the hang occurs and our project is still running. Paplay doesn't hang if started before I see the issue in our project (passing the same sink name with -d). Using the sound setting tools, if I set the output to dummy, the call unblocks, but obviously there is no sound output. The sink is alsa. The sink name is alsa_output.pci-0000_00_1b.0.analog-stereo. For the non-simple api, the data ready callback gets called once, then no matter how much data is written, never gets called again. -----Original Message----- From: Tanu Kaskinen [mailto:[email protected]] Sent: Wednesday, August 06, 2014 6:27 AM To: Stossel, Darrell (Insight/CSBU/RGS/Tucker) Cc: [email protected] Subject: Re: [pulseaudio-discuss] pa_simple_write blocks too long 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 _______________________________________________ pulseaudio-discuss mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
