Bluetooth headset no longer works [regression]

The 2.6.22 kernel from kernel.org gives me the same error message as above, but applying the flow control patch gives me a working headset. I haven't tried patching the Gutsy kernel, but this suggests that my guess above was right.

I'm seeing this same issue. I had my bluetooth headset working pretty well with the Feisty kernel using headsetd from the bluetooth-alsa project. Now with Gutsy I get the same error message listed above. I'm running amd64 architecture. My bluetooth chipset is a CSR device (from lsusb):
Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

I applied the SCO flow control patch to the gutsy 2.6.22 kernel source and recompiled. I was then able to use my bluetooth headset with headsetd. Unfortunately I'm having trouble rebuilding the restricted-modules package correctly so this isn't a workable solution for me yet.

Johan - please submit a patch to <email address hidden>, copy me on it.

I'm going on vacation in a few hours, so it'd have to wait for 10 days or so. Or you can take a look yourself, it's version 4.2 of the patch at the bluetooth-alsa URL above.

I sent the patch as Tim requested.

commit 5b4efc85b51dc5028e8095ca63a4040922b04ad2

linux-source-2.6.22 (2.6.22-11.32) gutsy; urgency=low

  [Amit Kucheria]

  * Build system: Allow custom builds to comprise multiple patches
  * Move UME to a Custom build and add first setup of thermal framework

  [Ben Collins]

  * ubuntu: Enable CONFIG_BLK_DEV_IO_TRACE
  * bcm203x: Fix firmware loading
    - LP: #85247
  * ubuntu: mtd changes caused module renaming. Ignore
  * rt: Do not patch top level Makefile for SUBLEVEL. Will always end up
    breaking

  [Chuck Short]

  * [USB] Unusual Device support for Gold MP3 Player Energy
    - LP: #125250
  * [SIERRA] Adds support for Onda H600 ZTE MF330
    - LP: #129433
  * [HDAPS] Add Thinkpad T61P to whitelist.
    - LP: #133636
  * [USB] Add support for Toshiba (Novatel Wireless) HSDPA for M400.
    - LP: #133650

  [Kyle McMartin]

  * apparmor 10.3 hooks
  * unionfs 2.1 hooks
  * nuke UNION_FS stuff from fs/{Kconfig,Makefile}

  [Tim Gardner]

  * Paravirt-ops I/O hypercalls
  * Fix lazy vmalloc bug for Gutsy
  * bluetooth headset patch
    - LP: #130870
  * Add the PCI ID of this ICH4 in list of laptops that use short cables.
  * v2.6.22.5 merge
  * Update Xen config options.
    - LP: #132726
  * Remove mtd modules from ABI
  * Support parallel=<n> in DEB_BUILD_OPTIONS
    - LP: #136426

  [Upstream Kernel Changes]

  * hwmon: fix w83781d temp sensor type setting
  * hwmon: (smsc47m1) restore missing name attribute
  * sky2: restore workarounds for lost interrupts
  * sky2: carrier management
  * sky2: check for more work before leaving NAPI
  * sky2: check drop truncated packets
  * revert "x86, serial: convert legacy COM ports to platform devices"
  * ACPICA: Fixed possible corruption of global GPE list
  * ACPICA: Clear reserved fields for incoming ACPI 1.0 FADTs
  * AVR32: Fix atomic_add_unless() and atomic_sub_unless()
  * r8169: avoid needless NAPI poll scheduling
  * forcedeth: fix random hang in forcedeth driver when using netconsole
  * libata: add ATI SB700 device IDs to AHCI driver
  * Hibernation: do not try to mark invalid PFNs as nosave
  * i386: allow debuggers to access the vsyscall page with compat vDSO
  * x86_64: Check for .cfi_rel_offset in CFI probe
  * x86_64: Change PMDS invocation to single macro
  * i386: Handle P6s without performance counters in nmi watchdog
  * i386: Fix double fault handler
  * JFFS2 locking regression fix.
  * [Input]: appletouch - improve powersaving for Geyser3 devices
  * [Input]: add driver for Fujitsu serial touchscreens
  * [sdhci]: add support to ENE-CB714
  * v2.6.22.5
  * [MTD] Makefile fix for mtdsuper
  * ocfs2: Fix bad source start calculation during kernel writes
  * NET: Share correct feature code between bridging and bonding
  * sky2: don't clear phy power bits
  * uml: fix previous request size limit fix
  * i386: fix lazy mode vmalloc synchronization for paravirt
  * signalfd: fix interaction with posix-timers
  * signalfd: make it group-wide, fix posix-timers scheduling
  * DCCP: Fix DCCP GFP_KERNEL allocation in atomic context
  * IPV6: Fix kernel panic while send SCTP data with IP fragments
  * IPv6: Invalid semicolon after if statement
  * Fix soft-fp underflow handling.
  * Netfilter: Missing Kbuild entry for netfil...

This is not a kernel issue. The SCO flow control patch was never approved by upstream and actually the new audio service from bluez-utils doesn't require this patch at all. Using some old btsco or plugz package might fail. Go with the audio support that is supported by the upstream BlueZ community.

I've tried the bluez audio service and it works for sending audio to my headset, but I can't get it to work for doing bidirectional sound, i.e. acting as both speaker and microphone. I've just sent an e-mail about this to the bluez-users mailing list.

headsetd is nice and works fine here, but I haven't got it to work with 32-bit applications on my 64-bit system. I need to find all relevant alsa plugins and related libraries and install them into the 32-bit area to run Skype, for example. btsco is a lot easier currently.

Unfortunately, it doesn't seem like this patch fixed the problem for me. The current Gutsy 2.6.22-12 kernel still won't work with my headset. I still get the same error message from mplayer.

Stock 2.6.23 with the SCO flow control patch doesn't work either.

Bumping from tribe-6 (!) to later. Please retarget as appropriate.

Retry this with Hardy.

I already have, and it doesn't work. The SCO flow control patch doesn't appear to have been applied to the Hardy kernel, so headsetd doesn't work (same error from mplayer as in my original report). And the bluez audio service does not work, either, see http://permalink.gmane.org/gmane.linux.bluez.user/13230 for a so-far ignored bug report.

The SCO flow control patch would probably make headsetd work. Why the bluez audio service doesn't work, I don't know.

I guess I misunderstood - that remark was directed at yourself. Never mind. :)

I'll try again when a patched kernel has been uploaded.

I recently tried the bluez audio service in gutsy and it is working fine for
me. I put the following in my ~/.asoundrc:

pcm.headset_hw {
   type bluetooth
   device bdaddrs
}

ctl.headset {
   type bluetooth
   device bdaddrs
}

pcm.headset {
    type plug
    slave.pcm "headset_hw"
}

# This specifies the OSS emulation to also use the
# desired mixed sound stuff for the headset.
pcm.dsp1 pcm.headset

Replace bdaddrs with the BD address of your headset. I'm not sure that the
ctl.headset section is needed, but it doesn't seem to hurt.

On Dec 14, 2007 6:49 PM, Johan Brannlund <email address hidden>
wrote:

> I guess I misunderstood - that remark was directed at yourself. Never
> mind. :)
>
> I'll try again when a patched kernel has been uploaded.
>
> --
> Bluetooth headset no longer works [regression]
> https://bugs.launchpad.net/bugs/130870
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Robert W. Brewer

Sadly, that .asoundrc doesn't get me a working bluetooth audio service. I still get the same errors that are described in the gmane link I posted earlier.

Finally I now *almost* have it working. Adding the line

options hci_usb force_scofix=1

to /etc/modprobe.d/bluez gets me a perfectly working headsetd from bluetooth-alsa. Also, the bluez audio service works somewhat better than before. I can now play back audio using mplayer for instance. However, using the headset in duplex mode with the audio service does not work. Twinkle can open the device *once* but it actually seems to want to open the device three times (for speaker, ringtone and microphone).

Oh well, it's getting there. Robert, can you use your headset to do VoIP, for instance with Twinkle?

Ok... my bluetooth dongle has a CSR chipset which I believe is the best
supported for SCO on linux. I'm on my second or third dongle since I began
my own journey. :) I have used my headset in full duplex with a small
python app I'm developing. The app uses the ALSA APIs to open the device.
The way the direct ALSA API works is the device is opened once for capture
and once for playback. Before giving up on bluez audio I would try a test
with running aplay and arecord at the same time in different windows with
the same sampling rate, etc. to see if that works. I don't have time to
find an example commandline right now.

I have tried to layer dmix and dsnoop on top of the bluetooth device (via
the .asoundrc) to no avail. dmix balks that the bluetooth plugin is not the
right type of slave device or something. That would have allowed multiple
apps to open the bluetooth device at the same time and would have simplified
some things in my app. Perhaps Twinkle is trying to do that. At some point
I'm hoping that switching to pulseaudio will solve this. It's the next-gen
audio daemon and sounds like it can replace dmix and dsnoop.

On Dec 21, 2007 5:35 PM, Johan Brannlund <email address hidden>
wrote:

> Finally I now *almost* have it working. Adding the line
>
> options hci_usb force_scofix=1
>
> to /etc/modprobe.d/bluez gets me a perfectly working headsetd from
> bluetooth-alsa. Also, the bluez audio service works somewhat better than
> before. I can now play back audio using mplayer for instance. However,
> using the headset in duplex mode with the audio service does not work.
> Twinkle can open the device *once* but it actually seems to want to open
> the device three times (for speaker, ringtone and microphone).
>
> Oh well, it's getting there. Robert, can you use your headset to do
> VoIP, for instance with Twinkle?
>
> --
> Bluetooth headset no longer works [regression]
> https://bugs.launchpad.net/bugs/130870
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Robert W. Brewer

Using the bluez audio service and the .asoundrc that Robert posted, I can get aplay and arecord to work simultaneously (doing "aplay -f S16_LE -Ddevicename test.wav" and the corresponding command line for arecord). However, voip apps still don't work for some reason. Twinkle gives an error at startup about not being able to configure the microphone and ekiga gives choppy playback and no recording.

Also, pulseaudio does not seem to help. If anything, there the results are even worse: extremely choppy playback and no recording.

As before, everything works correctly with headsetd.

ALSA 1.0.16 is released in Hardy l-u-m. Change the bug status if it doesn't fix the problem.

With the force_scofix option mentioned above, the headset now works as well as it ever has. For the most part, it works okay with headsetd but the bluez audio service still doesn't work with voip apps. However, that's probably not a kernel bug - I'll open a separate bug for that.

I'm trying to make my BT headset to work in Hardy x86_64, so far without any luck.

The "old" module+btsco solution hangs the applications that try to use them, the bluez audio service doesn't work and the bluetooth-alsa's headsetd prints following when attempting to play a file:

$ headsetd -n
headsetd[7529]: Bluetooth headset daemon version 0.5
headsetd[7529]: Incoming RFCOMM hs connection from 00:0D:44:5D:29:2C accepted
headsetd[7529]: Changing state: Idle-->Connected
headsetd[7529]: Changing state: Connected-->Ready
headsetd[7529]: Changing state: Ready-->Opening
headsetd[7529]: unable to open SCO channel to headset: Connection timed out
headsetd[7529]: Changing state: Opening-->ZombieAppl
headsetd[7529]: Appli closed socket

At the same time the kernel log is flooded with messages like these:

[ 315.190720] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1
[ 315.190725] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1
[ 315.200696] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1

It seems BT headset support is completely broken in Hardy beta.

Fedor, you're being affected by bug #39414.

Great, thanks!

Applying the fix from the following comment in that bug fixes the issue for me:

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/39414/comments/57