[pulseaudio-discuss] pa_mutex_unlock failed, what to do?
lennart at poettering.net
Tue Oct 16 10:05:25 PDT 2007
On Sat, 13.10.07 17:29, Jim Carter (jimc at math.ucla.edu) wrote:
> > 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).
Apparently the bluetooth plugin for ALSA is not compatible with
PA. Several people reported this already. I guess I should get myself
some kind of BT headphones so that I can actually test that. My
assumption is that
> 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:
> <6>hpet0: 3 64-bit timers, 14318180 Hz
> <4>Using HPET for base-timer
hpet support and hrtimer support is not the same. Also, this is not
going to fix your BT problems.
To have this message go away you should enable CONFIG_HIGH_RES_TIMERS
and CONFIG_HPET_TIMER. An unpatched kernel can do this on x86 only
right now. (not even amd64)
> 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.
Uh oh. That shouldn't happen. Is that the most recent SVN snapshot? I
am quite sure I fixed a bug like that a couple of days ago.
> (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?
module-suspend-on-idle will suspend all unused drivers after a while,
so if noone opened that device before then is this exactly the reason why
it is being suspended.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss