2008-07-03 00:37:57

by Malte J. Wetz

[permalink] [raw]
Subject: [Bluez-users] Headset not working (was: Belkin USB-Dongle blocks USB subsystem)

Am Montag, 30. Juni 2008 schrieb Martin Mueller:
> I have the same dongle and it's incorrctly indentified as "peagsus
> 100Mbit/s Ethernet". Just add the line:
>
> blacklist pegasus

Thanks for that info. It brought me one step closer to getting the stick to =

work. Now, everything appears to work. But the Belkin dongle behaves =

exactly like the MSI dongle: It does not record or playback anything when =

paired with my bluetooth headset (Jabra BT 205).

With my old Logitech MX 900, I used btsco which emulates a soundcard and =

everthing was fine. With the MSI or Belkin dongles, neither btsco nor the =

newer alsa plugin method work.


Ok, first the "deprecated" method with btsco (with correct BT address of =

course):


root@triton:~# btsco -v -r XX:XX:XX:XX:XX:XX
btsco v0.42
Device is 2:0
Voice setting: 0x0060
RFCOMM channel 1 connected
Using interface hci0

Then I start audacity, select =BBALSA: BT Headset: BT SCO PCM (hw:2,0)=AB a=
ls =

input source. I set the project frequency to 8000 Hz and hit the "Record" =

button. I new audio track appears, but the marker indicating the current =

position does not move. It just stays frozen at 0.0 on the timeline.
The btsco-Output is full of connection timeouts:

i/o needed: connecting sco...
Can't connect SCO audio channel
: Connection timed out
speaker volume: 11 mic volume: 14
recieved AT+VGS=3D11
Sending up speaker change 11
speaker volume: 11 mic volume: 14
i/o needed: connecting sco...
Can't connect SCO audio channel
: Connection timed out
speaker volume: 11 mic volume: 14

The syslog says:

Jul 2 15:49:31 triton kernel: hci_scodata_packet: hci0 SCO packet for =

unknown connection handle 1
Jul 2 15:50:01 triton last message repeated 9996 times


Now the "new" method via alsa:

This is my ~/.asoundrc:

pcm.headset { =

type bluetooth
device XX:XX:XX:XX:XX:XX
profile "sco"
} =

=

ctl.headset { =

type bluetooth =

} =


I also tried "auto" as profile above, doesn't change anything. Now, I want =

to use mplayer to play back a mp3 file using the headset.

mjw@triton:~$ mplayer -ao 'alsa:device=3Dheadset' test.mp3 =
=

MPlayer 1.0rc2-4.2.3 (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6400+ (Family: 15, Model: 67, =

Stepping: 3)
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote =

control.

Playing test.mp3.
Audio file file format detected.
Clip info:
Title: =

Artist: =

Album: =

Year: 0
Comment: =

Track: =

Genre: Unknown
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Forced audio codec: mad
Opening audio decoder: [libmad] libmad mpeg audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


And there it remains without anything happening. As you might have guessed, =

the syslog looks similar:

Jul 2 15:53:20 triton kernel: hci_scodata_packet: hci0 SCO packet for =

unknown connection handle 1
Jul 2 15:53:40 triton last message repeated 6565 times
Jul 2 15:53:40 triton kernel: hcid[2999]: segfault at 8 ip b7db5e0e sp =

bfae8090 error 6 in libaudio.so[b7dae000+19000]
Jul 2 15:53:40 triton kernel: hci_scodata_packet: hci0 SCO packet for =

unknown connection handle 1


I checked both dongles under Windows XP. The MSI dongle comes with the =

BlueSoleil stack, the Belkin dongle with the Widcomm stack. Both work =

perfectly. So I think there's nothing wrong with the hardware itself.

I googled for the syslog error above and found this patch: =

http://lkml.org/lkml/2008/2/27/105
It does fix the error message itself, but the headset still does not work. =


Last lines of mplayer-Output:

AO: [alsa] 8000Hz 1ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 1.0 (01.0) of 293.0 (04:53.0) 0.9%

And there it freezes. This time, syslog says for btsco:

Jul 2 16:10:18 triton kernel: snd-bt-sco revision 1.19 $
Jul 2 16:10:18 triton kernel: snd-bt-sco: snd-bt-scod thread starting
Jul 2 16:10:22 triton hcid[6279]: link_key_request (sba=3DYY:YY:YY:YY:YY:Y=
Y, =

dba=3DXX:XX:XX:XX:XX:XX)
Jul 2 16:10:34 triton hcid[6279]: Audio API: received =

BT_GETCAPABILITIES_REQ
Jul 2 16:10:53 triton hcid[6279]: Audio API: sending BT_GETCAPABILITIES_RSP
Jul 2 16:10:53 triton hcid[6279]: Audio API: received =

BT_SETCONFIGURATION_REQ
Jul 2 16:10:53 triton hcid[6279]: config sco - device =3D XX:XX:XX:XX:XX:X=
X =

access_mode =3D 2
Jul 2 16:11:01 triton ntpd[4908]: synchronized to 192.168.0.1, stratum 2
Jul 2 16:11:01 triton ntpd[4908]: kernel time sync status change 0001
Jul 2 16:11:36 triton kernel: snd-bt-sco: playback_open
Jul 2 16:11:36 triton kernel: snd-bt-sco: prepare ok bps: 16000 size: 3276=
8 =

count: 2048
Jul 2 16:11:36 triton kernel: Bluetooth: SCO (Voice Link) ver 0.5
Jul 2 16:11:36 triton kernel: Bluetooth: SCO socket layer initialized
Jul 2 16:11:36 triton kernel: snd-bt-sco: playback_trigger 1
Jul 2 16:11:36 triton kernel: snd-bt-sco: setting playback to bspcm
Jul 2 16:12:38 triton kernel: snd-bt-sco: playback_trigger 0
Jul 2 16:12:38 triton kernel: snd-bt-sco: setting playback to NULL
Jul 2 16:12:38 triton kernel: snd-bt-sco: Disposing of previous socket =

count 3
Jul 2 16:12:38 triton kernel: snd-bt-sco: file_count is 1 (expected 3)


And for the ALSA plugin:

Jul 2 16:16:02 triton hcid[9056]: Audio API: received =

BT_GETCAPABILITIES_REQ
Jul 2 16:16:02 triton hcid[9056]: Audio API: sending BT_GETCAPABILITIES_RSP
Jul 2 16:16:02 triton hcid[9056]: Audio API: received =

BT_SETCONFIGURATION_REQ
Jul 2 16:16:02 triton hcid[9056]: config sco - device =3D XX:XX:XX:XX:XX:X=
X =

access_mode =3D 2
Jul 2 16:16:05 triton hcid[9056]: link_key_request (sba=3DYY:YY:YY:YY:YY:Y=
Y, =

dba=3DXX:XX:XX:XX:XX:XX)
Jul 2 16:16:08 triton hcid[9056]: SCO fd=3D25
Jul 2 16:16:08 triton hcid[9056]: Audio API: sending =

BT_SETCONFIGURATION_RSP
Jul 2 16:16:08 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
Jul 2 16:16:08 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
Jul 2 16:16:08 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
Jul 2 16:17:28 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
Jul 2 16:17:28 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
Jul 2 16:17:28 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
Jul 2 16:18:08 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
Jul 2 16:18:08 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
Jul 2 16:18:08 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
Jul 2 16:18:48 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
Jul 2 16:18:48 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
Jul 2 16:18:48 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND

Note that in the last section, there are always three messages grouped =

together. Everytime one of these triplets is logged, mplayer advances a =

little bit on the playback (steps: 0.1%, 1.2%, 2.4%, and so on) and then =

blocks again until the next triplet shows up.


I would really like to get at least one method working but I don't even hav=
e =

an error message to feed to google. Any ideas on this one?

-- =

Malte J. Wetz <[email protected]>
Homepage: http://www.malte-wetz.de (PGP/GPG Keys available on homepage)

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users


2008-07-07 12:15:59

by Malte J. Wetz

[permalink] [raw]
Subject: Re: [Bluez-users] Headset not working

Am Montag, 7. Juli 2008 schrieb Martin Mueller:
> Hmm, do you have the bluetooth dongle connected via an USB-hub?

Currently, the Belkin dongle is connected directly to my mainboard. But I =

also tried my USB-Hub (active powered). Either way, it does not work.

-- =

Malte J. Wetz <[email protected]>
Homepage: http://www.malte-wetz.de (PGP/GPG Keys available on homepage)

Verhandle nur, wenn Du in jedem Fall Profit davontr=E4gst!
-- Ferengi-Erwerbsregel Nr. 42

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2008-07-07 11:32:58

by Martin Mueller

[permalink] [raw]
Subject: Re: [Bluez-users] Headset not working

Hi,

On Mon, Jul 07, 2008 at 12:55:06PM +0200, Malte J. Wetz wrote:
>
> Well, as I wrote before, I'm already using the SCO/ESCO patch and it
> does not work.

Hmm, do you have the bluetooth dongle connected via an USB-hub? If
yes, try plugging the dongle directly into the mainboard. In my setup
I can't use bt-dongles connected to hub for SCO, even though the rest
like rfcomm, l2ping, etc work.

> The patch proposed by Martin does apply to current kernel (you just
> have to add =BB-F10=AB to your patch command as some line have moved
> beyond the default fuzz). But it does no good. Now, whenever I play
> back something via the headset, the entire kernel freezes and even
> Magic SysRq won't anymore. Only a hard reset gets me out of there.

What a luck I wasn't able to apply it. ;-)

bye
MM
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2008-07-07 10:55:06

by Malte J. Wetz

[permalink] [raw]
Subject: Re: [Bluez-users] Headset not working

Am Sonntag, 6. Juli 2008 schrieb jayjwa:
> On Fri, 4 Jul 2008, Martin Mueller wrote:
> -> You can get the patch from:
> http://bluetooth-alsa.cvs.sourceforge.net/*checkout*/bluetooth-alsa/plugz
>/patches/sco-flowcontrol-v4.4.diff?revision=3D1.1 ->
>
> We seem to be talking about different patches. I am refering to the one
> needed to allow older bluetooth (I think it's 1.2?) headsets to work with
> newer kernels, that deals with SCO/ESCO. The one above modifies another
> file. Below is the one I use, and it's working now even on linux-2.6.25.9
> (kernel.org) that I'm currently using.

Well, as I wrote before, I'm already using the SCO/ESCO patch and it does =

not work.

The patch proposed by Martin does apply to current kernel (you just have to =

add =BB-F10=AB to your patch command as some line have moved beyond the def=
ault =

fuzz). But it does no good. Now, whenever I play back something via the =

headset, the entire kernel freezes and even Magic SysRq won't anymore. Only =

a hard reset gets me out of there.

Log files is insuspicous:

Jul 7 12:41:37 triton hcid[8053]: Audio API: received =

BT_GETCAPABILITIES_REQ
Jul 7 12:41:37 triton hcid[8053]: Audio API: sending BT_GETCAPABILITIES_RSP
Jul 7 12:41:37 triton hcid[8053]: Audio API: received =

BT_SETCONFIGURATION_REQ
Jul 7 12:41:37 triton hcid[8053]: config sco - device =3D 00:13:17:CF:C3:D=
5 =

access_mode =3D 2
Jul 7 12:41:40 triton hcid[8053]: pin_code_request (sba=3D00:0A:3A:81:33:1=
C, =

dba=3D00:13:17:CF:C3:D5)
<freeze here>


hci_usb is loaded with force_scofix=3D1. I cannot see any differences.

Still confused,
Malte

-- =

Malte J. Wetz <[email protected]>
Homepage: http://www.malte-wetz.de (PGP/GPG Keys available on homepage)

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2008-07-04 16:33:13

by Martin Mueller

[permalink] [raw]
Subject: Re: [Bluez-users] Headset not working (was: Belkin USB-Dongle blocks USB subsystem)

Moin,

On Fri, Jul 04, 2008 at 04:17:18PM +0200, Michael Domann wrote:
>
> if i understand it right, i need the patch, but i don't know how can i get the patch. do you have a link for me?

You can get the patch from:

http://bluetooth-alsa.cvs.sourceforge.net/*checkout*/bluetooth-alsa/plugz/patches/sco-flowcontrol-v4.4.diff?revision=1.1

But the following section doesn't apply anymore to my 2.6.25 debian
kernel maybe someone knows how to fix it:

diff -ru linux-2.6.22-mh3/net/bluetooth/hci_conn.c linux-2.6.22-mh3-sco-flowcontrol/net/bluetooth/hci_conn.c
--- linux-2.6.22-mh3/net/bluetooth/hci_conn.c 2007-10-10 15:12:04.000000000 +0200
+++ linux-2.6.22-mh3-sco-flowcontrol/net/bluetooth/hci_conn.c 2007-10-10 14:31:19.000000000 +0200

@@ -208,6 +228,11 @@

skb_queue_head_init(&conn->data_q);

+ hrtimer_init(&conn->tx_timer, CLOCK_MONOTONIC, HRTIMER_NORESTART);
+
+ if(type == SCO_LINK)
+ conn->tx_timer.function = hci_sco_tx_timer;
+
init_timer(&conn->disc_timer);
conn->disc_timer.function = hci_conn_timeout;
conn->disc_timer.data = (unsigned long) conn;
@@ -217,6 +242,7 @@

bye
MM
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2008-07-04 14:17:18

by Michael Domann

[permalink] [raw]
Subject: Re: [Bluez-users] Headset not working (was: Belkin USB-Dongle blocks USB subsystem)

Hi,

sorry for kidnapping your thread. i have also a jabra bt 135

sysiphus:/home/profbunny/source/deluge# hcitool info 00:1A:45:6E:D5:23
Requesting information ...
BD Address: 00:1A:45:6E:D5:23
LMP Version: 2.0 (0x3) LMP Subversion: 0x978
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>

if i understand it right, i need the patch, but i don't know how can i get the patch. do you have a link for me?

thanks micha

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2008-07-04 04:27:18

by jayjwa

[permalink] [raw]
Subject: Re: [Bluez-users] Headset not working (was: Belkin USB-Dongle blocks USB subsystem)



On Thu, 3 Jul 2008, Malte J. Wetz wrote:

-> Thanks for that info. It brought me one step closer to getting the stick to
-> work. Now, everything appears to work. But the Belkin dongle behaves
-> exactly like the MSI dongle: It does not record or playback anything when
-> paired with my bluetooth headset (Jabra BT 205).

I think these are older bluetooth hardware that you will need the kernel patch
for. Mine needs it. Patch kernel & recompile/reinstall modules as it seems
like you already did below.

-> With my old Logitech MX 900, I used btsco which emulates a soundcard and
-> everthing was fine. With the MSI or Belkin dongles, neither btsco nor the
-> newer alsa plugin method work.
->
->
-> Ok, first the "deprecated" method with btsco (with correct BT address of
-> course):

This method is old and my not even work anymore with modern bluez, I don't
know. Try current bluez-utils/libs and current Alsa w/current kernel for best
results.


-> Jul 2 15:53:20 triton kernel: hci_scodata_packet: hci0 SCO packet for
-> unknown connection handle 1
-> Jul 2 15:53:40 triton last message repeated 6565 times

This looks like what happens when you don't use the patch when you need it.
Look at the device and see:

# hcitool info 00:1A:45:01:F9:42

Requesting information ...
BD Address: 00:1A:45:01:F9:42
OUI Company: GN Netcom as (00-1A-45)
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>


When it only says "SCO", you'll need the patch. Never saw an ESCO headset
because I don't own one, but I'd guess it shows things like <eSCO link>?

-> Jul 2 15:53:40 triton kernel: hcid[2999]: segfault at 8 ip b7db5e0e sp
-> bfae8090 error 6 in libaudio.so[b7dae000+19000]


That might be the segfault I hit awhile back and posted about. It's the same
solib, libaudio.so

-> Jul 2 15:53:40 triton kernel: hci_scodata_packet: hci0 SCO packet for
-> unknown connection handle 1


-> Jul 2 16:16:02 triton hcid[9056]: Audio API: received
-> BT_GETCAPABILITIES_REQ
-> Jul 2 16:16:02 triton hcid[9056]: Audio API: sending BT_GETCAPABILITIES_RSP
-> Jul 2 16:16:02 triton hcid[9056]: Audio API: received
-> BT_SETCONFIGURATION_REQ
-> Jul 2 16:16:02 triton hcid[9056]: config sco - device = XX:XX:XX:XX:XX:XX
-> access_mode = 2
-> Jul 2 16:16:05 triton hcid[9056]: link_key_request (sba=YY:YY:YY:YY:YY:YY,
-> dba=XX:XX:XX:XX:XX:XX)
-> Jul 2 16:16:08 triton hcid[9056]: SCO fd=25
-> Jul 2 16:16:08 triton hcid[9056]: Audio API: sending
-> BT_SETCONFIGURATION_RSP
-> Jul 2 16:16:08 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
-> Jul 2 16:16:08 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
-> Jul 2 16:16:08 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
-> Jul 2 16:17:28 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
-> Jul 2 16:17:28 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
-> Jul 2 16:17:28 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
-> Jul 2 16:18:08 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
-> Jul 2 16:18:08 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
-> Jul 2 16:18:08 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND
-> Jul 2 16:18:48 triton hcid[9056]: Audio API: received BT_STREAMSTART_REQ
-> Jul 2 16:18:48 triton hcid[9056]: Audio API: sending BT_STREAMSTART_RSP
-> Jul 2 16:18:48 triton hcid[9056]: Audio API: sending BT_STREAMFD_IND


Last things are the SCO MTU...

# hciconfig -a

hci0: Type: USB
BD Address: 00:0A:3A:7C:5C:74 ACL MTU: 1017:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:4448653 acl:123 sco:87104 events:179 errors:0
TX bytes:4496843 acl:98 sco:88120 commands:80 errors:0
Features: 0xff 0xff 0x8d 0xfe 0x9b 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: '[vdrl] / BT Device 0'
Class: 0x1a0108
Service Classes: Networking, Capturing, Object Transfer
Device Class: Computer, Server
HCI Ver: 2.0 (0x3) HCI Rev: 0x4107 LMP Ver: 2.0 (0x3) LMP Subver: 0x430e
Manufacturer: Broadcom Corporation (15)


If the SCO MTU: 64:8 part has zero's there, it won't work. Mine will do this
without the hci_usb force sco fix param set:

# modinfo hci_usb

filename: /lib/modules/2.6.25.9/kernel/drivers/bluetooth/hci_usb.ko.gz
license: GPL
version: 2.9
description: Bluetooth HCI USB driver ver 2.9
author: Maxim Krasnyansky <[email protected]>, Marcel Holtmann
<[email protected]>
srcversion: DACD9DA7C0F1ECE25CC71EB
alias: usb:v0C10p0000d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0BDBp1002d*dc*dsc*dp*ic*isc*ip*
alias: usb:v044Ep3002d*dc*dsc*dp*ic*isc*ip*
alias: usb:v044Ep3001d*dc*dsc*dp*ic*isc*ip*
alias: usb:v04BFp030Ad*dc*dsc*dp*ic*isc*ip*
alias: usb:v057Cp3800d*dc*dsc*dp*ic*isc*ip*
alias: usb:v*p*d*dcE0dsc01dp01ic*isc*ip*
depends: bluetooth
vermagic: 2.6.25.9 mod_unload PENTIUM4
parm: ignore:Ignore devices from the matching table (bool)
parm: ignore_dga:Ignore devices with id 08fd:0001 (bool)
parm: ignore_csr:Ignore devices with id 0a12:0001 (bool)
parm: ignore_sniffer:Ignore devices with id 0a12:0002 (bool)
parm: disable_scofix:Disable fixup of wrong SCO buffer size (bool)
parm: force_scofix:Force fixup of wrong SCO buffers size (bool)
parm: reset:Send HCI reset command on initialization (bool)
parm: isoc:Set isochronous transfers for SCO over HCI support (int)


Try one of two things if you have this problem:

1.) have no mention of hci_usb any place in modprobe.conf, then manually
insert the module (remove first if needed) with the param on:

modprobe -r hci_usb
sleep 1
modprobe hci_usb force_scofix=1

(then start the bluetooth stuff)

2.) put this in modprobe.conf. Mine is at /etc/modprobe.conf

options hci_usb force_scofix=1

...and refresh the modules (depmod -e -F /boot/System.map). It must point to
the current System.map

Make sure the module is out:

modprobe -r hci_usb

Then start bluetooth stuff as usual and modprobe will handle the param for you
for now on so you can forget about it after this if you go this route.


Also make sure the right files are installed for alsa-lib to do bluetooth
(there's a few extra in my setup, like the speex ones):

/usr/lib/alsa-lib:

# ls -1

libasound_module_ctl_bluetooth.so*
libasound_module_ctl_dsp_ctl.so*
libasound_module_ctl_oss.so*
libasound_module_pcm_alsa_dsp.so*
libasound_module_pcm_bluetooth.so*
libasound_module_pcm_oss.so*
libasound_module_pcm_upmix.so*
libasound_module_pcm_vdownmix.so*
libasound_module_rate_speexrate_best.so@
libasound_module_rate_speexrate_medium.so@
libasound_module_rate_speexrate.so*
smixer/

-> I would really like to get at least one method working but I don't even have
-> an error message to feed to google. Any ideas on this one?
->

>>From the start w/above fixes in mind:

Some headsets like mine won't show themselves unless they are put in visible
mode. On this one, that is turn it off, then back on, holding the button
awhile. The light stays lit and you can scan it. If you know its address
already you don't need to do that.

# hcitool scan

Scanning ...
00:1A:45:01:F9:42 Jabra BT135


# cat /etc/asound.conf

## Alsa Sound Config
##
## Extra configurations for Alsa
## (/usr/share/alsa/alsa.conf)
##

pcm.oss {
type oss
device /dev/dsp
}

pcm.bluetooth {
type bluetooth
device "00:1A:45:01:F9:42"
profile "auto"
}

ctl.bluetooth {
type bluetooth
device "00:1A:45:01:F9:42"
}

pcm.bt_slave {
type plug
slave {
pcm "bluetooth"
}
}



You don't need the first and last stanzas, they are for other stuff.

/usr/bin/dbus-daemon --system
hcid -s -f /etc/bluetooth/hcid.conf

Some times removing the persistant info in /var/lib/bluetooth/* helps clear up
odd errors. Your dir may be in another place.

passkey-agent --default 0000 00:1A:45:01:F9:42 & (passkey-agent --default <PIN> <Remote BT address>
auth-agent & (or whatever you are using to pair with)


Turn on the headset. Mine looks for the computer and connects to it, not the
other way around. When nothings being sent it disconnects. You don't have to
worry about manually connecting it. Pressing the button on the side of it
makes it do the same. Mine is the same company as yours, similar model so they
might work similarly.

If you built your kernel with auto kmod load you don't need to worry about
loading modules outside of the hci_usb thing above because of the special
parameter.

Send some sound. Not all players I've tried work, but I know sox does. And the
standard Alsa stuff.

sox -t ogg ./sound_file.ogg -t alsa pcm.bluetooth <-- Name in asound.conf


That should be it. Recording I've done w/sox the same way, just opposite
direction. You may see a few errors in syslog but it should work.

linux-2.6.25.9
alsa-*-1.0.16
bluez-utils-3.34
bluez-libs-3.34
sox-14.0.1


I posted a few times on headsets. You might look in the list archive for some
older posts.



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users