Hi, On 18 Dec 2007, Lennart Poettering wrote: >> - 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 > >Uh, doesn't happen here. maybe contents of foo.wav makes a difference. For me, the most reliable way to reproduce the bug is: - run pulseaudio at 48kHz - pick foo.wav of 44.1kHz - replace second client with paplay Oh well, it seems like a rare corner case, as it seems to occurs with only certain combinations even in my setup. >Could you please paste the whole backtrace somwhere? I added traces to the ticket: http://www.pulseaudio.org/ticket/195 >> I made a fix in my local tree which uses pa_mutex_trylock() (a new >> funtion implemented using pthread_mutex_trylock()) and nanosleep() > >Uh? That mutex does priority inheritance anyway. If you get a >lockup than there's something wrong with the locking order, >it's most likely not a prio inversion problem. Aa, ok, I hadn't realized that PTHREAD_PRIO_INHERIT is now available on Linux (and used by PA code). In the traces, the SCHED_FIFO thread is blocked on pthread_mutex_lock() while the SCHED_OTHER thread is blocked on sem_wait() (called from pa_asyncmsgq_send()). br, -- first.surname at nokia.com (Kai Vehmanen)
