2009-02-24 16:14:14

by jayjwa

[permalink] [raw]
Subject: BT headset stops working



I upgraded from bluez-3.x to bluez-4.30 and found my headset no longer works.

I figured out pairing:

# simple-agent hci0 00:1A:45:01:F9:42

RequestPinCode (/org/bluez/18088/hci0/dev_00_1A_45_01_F9_42)
Enter PIN Code: 0000
Release
New device (/org/bluez/18088/hci0/dev_00_1A_45_01_F9_42)


but when playback should start, I see these familiar messages:


# sox -t mp3 sound_test.mp3 -t alsa pcm.bluetooth

ALSA lib pcm_bluetooth.c:1563:(audioservice_expect) BT_START_STREAM failed : Success(0)
ALSA lib pcm_bluetooth.c:1531:(audioservice_recv) Bogus message type 5 - name received from audio service
sox soxio: Can't open output file `pcm.bluetooth': cannot prepare audio interface for use

btusb_isoc_complete: hci0 corrupted SCO packet

hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
hci_scodata_packet: hci0 SCO packet for unknown connection handle 0

(many of these scrolling off the screen)

It's the same headset that's always worked before (after patching the kernel
to put back the ripped out SCO functionality vs ESCO link patch):


Requesting information ...
BD Address: 00:1A:45:01:F9:42
OUI Company: GN Netcom as (00-1A-45)
Device Name: Jabra BT135
LMP Version: 2.0 (0x3) LMP Subversion: 0xbfa
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xfc 0xfe 0x0b 0x00 0x08 0x08 0x00 0x00
<encryption> <slot offset> <timing accuracy> <role switch>
<hold mode> <sniff mode> <RSSI> <channel quality> <SCO link>
<HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD>
<paging scheme> <transparent SCO> <AFH cap. slave>
<AFH cap. master>

Pan doesn't appear to work either, but one problem at a time. Apologies if
this is the wrong list; I was under the impression this list was the successor
to the bluez-users list at Source Forge, as stated on http://www.bluez.org, but since
arriving here it appears to be bluetooth equal to the linux-kernel list
(development).






2009-02-24 18:31:17

by jayjwa

[permalink] [raw]
Subject: Re: BT headset stops working


On Tue, 24 Feb 2009, Johan Hedberg wrote:

>> ALSA lib pcm_bluetooth.c:1563:(audioservice_expect) BT_START_STREAM failed : Success(0)
>> ALSA lib pcm_bluetooth.c:1531:(audioservice_recv) Bogus message type 5 - name received from audio service
>
> The most common cause of messages like this is a mismatch between the
> bluetooth alsa plugin and bluetoothd. Make sure they are both from the
> same bluez version (hint: the alsa plugin is typically in
> /usr/lib/alsa-lib).

Are they not generated from the same source? Both dates match to the
install/build date.


>> btusb_isoc_complete: hci0 corrupted SCO packet
>>
>> hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
>> hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
>> hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
>> hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
>> hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
>
> These look like kernel issues to me.

This kernel, 2.6.28.7, worked with old bluez-*-3.36. At the update to
bluez-4.30 is when it stopped. 4.30 is the decisive point.



2009-02-24 17:00:10

by Johan Hedberg

[permalink] [raw]
Subject: Re: BT headset stops working

Hi,

On Tue, Feb 24, 2009, jayjwa wrote:
> ALSA lib pcm_bluetooth.c:1563:(audioservice_expect) BT_START_STREAM failed : Success(0)
> ALSA lib pcm_bluetooth.c:1531:(audioservice_recv) Bogus message type 5 - name received from audio service

The most common cause of messages like this is a mismatch between the
bluetooth alsa plugin and bluetoothd. Make sure they are both from the
same bluez version (hint: the alsa plugin is typically in
/usr/lib/alsa-lib).

> btusb_isoc_complete: hci0 corrupted SCO packet
>
> hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
> hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
> hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
> hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
> hci_scodata_packet: hci0 SCO packet for unknown connection handle 0

These look like kernel issues to me.

Johan