Kai.Vehmanen at nokia.com wrote: > Hello all, > > this is probably a known issue, but I'm constantly hitting > a deadlock when running Pulseaudio (0.9.7) with SCHED_FIFO > (--high-priority=1). > > I can reproduce it as follows: > > - run pulseaudio (self-compiled, debian stable) with --high-priority=1 > - first client: while [ 1 ] ; do aplay -D pulse foo.wav ; done > - second: while [ 1 ] ; do aplay -D pulse foo.wav ; done > > At some point, pulseaudio gets stuck and backtrace shows its > stuck in memblock.c:pa_memblock_unref() -> memblock_free() > -> pa_mutex_lock(). > > There's a FIXME comment already in the function, so I guess this > is known. > > I made a fix in my local tree which uses pa_mutex_trylock() (a new > funtion implemented using pthread_mutex_trylock()) and nanosleep() > to avoid the priority inversion (spins until it gets the lock). > With this patch, Pulseaudio now survices the above stresstest. > Of course, nanosleeping() in RT context is very, very ugly, > but better than a deadlock, at least. ;) > > Any ideas how to go forward? I could clean up the code and send > a patch, or alternatively try out a different approach. I don't > fully grok all the code in memblock_free() yet, so it's hard to > say how big of a task it would be to make this totally lock-free. > At least doesn't look to be very straighforward... > > br, I'd make a ticket in trac and attach what you have just so it doesn't get lost. Unf. I don't know much about the core of pa so can't really help technically. Col