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

[Lennart Poettering]

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:
> CONFIG_HPET_TIMER=y
> <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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4