Bluetooth handsfree does not work and floods syslog

Bug #211893 reported by Per Heldal
14
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Low
Unassigned

Bug Description

[I'm not sure is this big relates to bluez or alsa or something else . It concerns hardy beta]

First, to get pairing to work I have to use parts of the suggested python-script from the bluez-wiki. To make the PC visible and connectable prior to setting the headset in pairing mode is not enough to trigger the pairing process.

From there it appears normal in the log when the headset is turned on:

With audio sent to the device there is no sound, but syslog is flooded:
mplayer -ao alsa:device=headset /usr/share/sounds/shutdown1.wav

The repeaded log-entry contains:
Apr 4 13:39:34 obelix kernel: [ 460.424359] hci_scodata_packet: hci0 SCO packet for unknown connection handle 46

Output to syslog continues after the mplayer process is terminated. It does not stop until the bt-headset is turned off and gets de-registered from the bt service.

The USB dongle in use works fine with other services (obex,hid etc)

Further details attached.

Revision history for this message
Per Heldal (heldal) wrote :
Revision history for this message
Per Heldal (heldal) wrote :

This relates to a similar bug in gutsy and before, but both bluez and the kernel has changed since so the fixes for those may not apply anymore.

In short this seems to relate to missing or incomplete support for eSCO in the kernel that makes most, if not all, BT<=1.2 headsets fail.

There's a number of patches listed to support this in the kernel listed at http://kernelnewbies.org/Linux_2_6_24#head-efad198ce9f2c533fcc541c306e566fc3a42af91 It seems these are included in the current kernel-source (2.6.24-15).

In addition there is a small patch to make it work listed in http://lkml.org/lkml/diff/2008/2/25/530/1
This has been reported to work with 2.6.24 (http://article.gmane.org/gmane.linux.bluez.user/13682).

Revision history for this message
Brian Murray (brian-murray) wrote :

This bug seems similar to if not a duplicate of bug 198494.

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Low
status: New → Triaged
Revision history for this message
MsTiFtS (mstifts) wrote :

Bug 198494 seems to be another issue. This rather seems to be a duplicate of bug 39414.

Revision history for this message
Per Heldal (heldal) wrote :

@Brian Murray : bug 198494 does indeed cover the pairing issue mentioned, but that's the simple bit.

@MsTiFtS : bug 39414 is similar, but concerns a USB-BT adapter. In this case the adapter works with multiple devices (keyboard, mouse and several phones using obex-transfers and HID). Only BT-audio seems to cause the problem in this case.

Unfortunately my BT-1.2 headset has died so I can't test that one any more. What I've dug out so far pointed to the kernel failing to fall back from eSCO (BT-2.x) to SCO (BT-1.x). I have however tested a BT 2.0 headset (Jabra BT5010) with the same result, so so much for that theory. What remains to be tested is the kernel-patch that others on the bluez-users-list have reported to work.

Revision history for this message
Per Heldal (heldal) wrote :

Grabbed the kernel-source from git, applied the BT patch (http://lkml.org/lkml/diff/2008/2/25/530/1) and built new packages. My BT-2.0 headset works with this new kernel. The sound gets choppy after a few seconds, but there are still more options to explore in the BT-audio config that may change that. There are no more hci_scodata_packet messages is the logs, and everything else on BT still works. It remains to see if anything else could be affected, but it looks good so far.

Revision history for this message
Per Heldal (heldal) wrote :

To be a bit more specific: I'm now running a kernel built from the ubuntu.com git repository, with the specified patch applied. From there I've built and installed binary-generic.

The BT-handsfree-kit works (kind of) with this kernel.

While running with this kernel I've seen bt-audio once end up in a weird state where it repeats the following to syslog:

Apr 12 15:23:57 audio[14838]: Audio API: received BT_STREAMSTART_REQ
Apr 12 15:23:57 audio[14838]: Audio API: sending BT_STREAMSTART_REQ

When this happened mplayer reported the following while trying to open the bt-device:

[AO_ALSA] pcm prepare error: Invalid argument
[AO_ALSA] Write error: Bad file descriptor
[AO_ALSA] Trying to reset soundcard.
[AO_ALSA] alsa-lib: pcm_bluetooth.c:1481:(audioservice_expect) Bogus message BT_STREAMSTART_REQ received while BT_STREAMSTART_RSP was expected

---

Sound tends to break up regardless of the distance between the devices, so I've tried to install the most recent releases from bluez.org (bluez-libs-3.30, bluez-utils-3.30, bluez-firmware-1.2, bluez-hcidump-1.41, bluez-gnome-0.26). Unfortunately that makes no difference to sound quality. (Btw; nor is there yet anything that can help with the previously mentioned pairing issue for headsets). The new packages are built and installed on-top of the standard files from hardy to avoid loosing other bt-tools through dependencies (yes I'm aware of the consequences;). The only significant difference except bug-fixes seem to be that services now are plugins in the form of shared-libs and not separate processes as they used to be.

Next is to check for other kernel-patches. Now I wonder where the actual version of bluez-code in the current hardy-kernel comes from. It doesn't seem to match vanilla 2.6.24 from kernel.org, nor does it match the latest patches from bluez.org. It seems to be something in the middle.

---

I think BT-audio is going to be hard to solve in hardy for several reasons:

- bluez since release 3.26 (the one in hardy) is in a bit of a limbo. This is the first of the 3.x releases that are describes as part of a transition to new architecture in bluez 4.0

- kernel modules for alsa/bluez integration that supposedly are obsolete as of bluez 3.26 are still included in hardy

- then there is the incomplete alsa/pulseaudio transition.

Half-baked is probably an appropriate description.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Revision history for this message
fatski (paul-karnowski) wrote :

This bug remains in the exact same form on kernel 2.6.27 in the Intrepid Ibex RC

Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: kj-triage
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: kj-expired
Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.