[pulseaudio-discuss] pa_mutex_unlock failed, what to do?

Jim Carter jimc at math.ucla.edu
Sat Oct 13 17:29:52 PDT 2007


On Sat, 13 Oct 2007, Lennart Poettering wrote:

> On Fri, 12.10.07 21:37, Jim Carter (jimc at math.ucla.edu) wrote:
> 
> > pulseaudio dies saying:
> > pulseaudio: pulsecore/mutex-posix.c:98: pa_mutex_unlock: Assertion 
> > `pthread_mutex_unlock(&m->mutex) == 0' failed.

> Upgrade your libltdl to something not-broken. 1.5.24 is fine, 1.5.22
> is borked.

Thanks, that helped a lot.  I'm now able to play music either on the ALSA 
pulse device or the xmms output plugin for PulseAudio and have something 
appear on the Bluetooth headphones.  However...  The sound is recognizable 
but just barely, with lots of noise, and it plays faster than normal.  
It's hard to tell how much faster but comparing the counter on xmms with 
xclock -digital suggests it's close to 2:1.  With pulseaudio shut off, both 
players can play perfectly direct to the Bluetooth ALSA device (in stereo).
Also, PulseAudio says frequently "W: protocol-native.c: Failed to push data 
into queue" (which is no surprise if it's rushing the sink's datarate).

Here's what I did that didn't cure the problem:

Changing aplay's format: -r 48000 rejected (format non-available);
-f S16_BE produced atrocious noise (no surprise); -f U16_LE rejected 
(format non-available).  -c 2 -f S16_LE -r 44100 gave the "best" results.

In daemon.conf I set disable-shm=1 ... No effect.

resample-method = speex-fixed-0 ... No effect.

Here's evidence that everyone agrees on the right format:
I: sink.c: Created sink 1 "bluetooth" with sample spec "s16le 2ch 44100Hz"
I: sink-input.c: Created input 1 "(null)" on bluetooth with sample spec 
	s16le 2ch 44100Hz

Any suggestions on what to try next?

By the way, I had two presumably unrelated problems.  First, the daemon 
complains: "I: main.c: Dude, your kernel stinks! The chef's recommendation 
today is Linux with high-resolution timers enabled!"  I thought it *was* 
enabled.  Isn't this the high resolution timer being referred to:
CONFIG_HPET_TIMER=y
<6>hpet0: 3 64-bit timers, 14318180 Hz
<4>Using HPET for base-timer

Second, PulseAudio would crash on startup with this message:
I: module-suspend-on-idle.c: Source bluetooth.monitor idle for too long, 
	suspending ...
pulseaudio: pulsecore/source.c:273: pa_source_post: Assertion 
	`PA_SOURCE_OPENED(s->thread_info.state)' failed.
(In fact, nobody ever opened that source.)  To cure the problem I omitted 
loading module-suspend-on-idle, but it looks like a nice feature, and is 
there something I might have done / not done to break it?

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc at math.ucla.edu  http://www.math.ucla.edu/~jimc (q.v. for PGP key)



More information about the pulseaudio-discuss mailing list