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
