Hi,
I'm currently trying to get my "Logitech Mobile Pro II" headset connected
to my Debian box using the new and shiny headsetd. It seems that I get a
connection between my notebook and the headset when starting a test run
of aplay (the speaker of the headset is activated and emits some quiet
static sounds) but that's all that happens. Aplay will just kind of
freezes and that's it.
But now the information in more order (my CVS checkouts are from today):
root@washu:~ # hciconfig -a
hci0: Type: USB
BD Address: 00:02:78:3D:18:DD ACL MTU: 1017:8 SCO MTU: 64:0
UP RUNNING PSCAN
RX bytes:397591 acl:21 sco:7760 events:50 errors:0
TX bytes:806 acl:21 sco:0 commands:30 errors:0
Features: 0xff 0xff 0x8d 0xfe 0x9b 0xfd 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'washu'
Class: 0x3e0100
Service Classes: Networking, Rendering, Capturing, Object
Transfer, Audio
Device Class: Computer, Uncategorized
HCI Ver: 2.0 (0x3) HCI Rev: 0x20dc LMP Ver: 2.0 (0x3) LMP Subver:
0x415c
Manufacturer: Broadcom Corporation (15)
florian@washu:~ # /opt/bluetooth-alsa/bin/headsetd -n
headsetd[1808]: Bluetooth headset daemon version 0.5
[*** headset switched on ***]
headsetd[1808]: Incoming RFCOMM hs connection from 00:0D:44:5C:A7:69
accepted
headsetd[1808]: Changing state: Idle-->Connected
[*** aplay started ***]
headsetd[1808]: Changing state: Connected-->Ready
headsetd[1808]: Changing state: Ready-->Opening
headsetd[1808]: SCO channel opened handle=0x0001 mtu=64
headsetd[1808]: Changing state: Opening-->Streaming
[*** this is where aplay hangs ***]
florian@washu:~ # aplay -B 1000000 -Dheadset
/usr/share/sounds/alsa/Front_Left.wav
DEBUG(pid=1897): _snd_pcm_sco_open: Starting pcm_sco_headset plugin.
DEBUG(pid=1897): _snd_pcm_sco_open: Open mode is for Playback.
DEBUG(pid=1897): _snd_pcm_sco_open: opened as ioplug=0x805c778,
pcm=0x805c8b0, i
oplug->callback = 0xb7acc7e0
Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
Endian, R
ate 48000 Hz, Mono
Warning: rate is not accurate (requested = 48000Hz, got = 8000Hz)
please, try the plug plugin (-Dplug:headset)
DEBUG(pid=1897): sco_headset_hw_params: period_count = 200
DEBUG(pid=1897): sco_headset_prepare: Preparing with io->period_size =
24, io->b
uffer_size = 4800
DEBUG(pid=1897): sco_headset_pointer: returning bt_headset->hw_ptr=0
DEBUG(pid=1897): sco_headset_write: areas->step=16, areas->first=0,
offset=0, si
ze=24, io->nonblock=0
DEBUG(pid=1897): sco_headset_write: returning 24
DEBUG(pid=1897): sco_headset_pointer: returning bt_headset->hw_ptr=24
DEBUG(pid=1897): sco_headset_write: areas->step=16, areas->first=0,
offset=0, si
ze=24, io->nonblock=0
DEBUG(pid=1897): sco_headset_write: returning 24
DEBUG(pid=1897): sco_headset_pointer: returning bt_headset->hw_ptr=48
DEBUG(pid=1897): sco_headset_write: areas->step=16, areas->first=0,
offset=0, si
ze=24, io->nonblock=0
[*** many more of those lines ***]
DEBUG(pid=1897): sco_headset_write: returning 24
DEBUG(pid=1897): sco_headset_pointer: returning bt_headset->hw_ptr=4776
DEBUG(pid=1897): sco_headset_write: areas->step=16, areas->first=0,
offset=0, si
ze=24, io->nonblock=0
DEBUG(pid=1897): sco_headset_write: returning 24
DEBUG(pid=1897): sco_headset_pointer: returning bt_headset->hw_ptr=0
DEBUG(pid=1897): sco_headset_write: areas->step=16, areas->first=0,
offset=0, si
ze=24, io->nonblock=0
[*** this is where aplay hangs ***]
Here I here, that the speaker has been switched on, but all I hear is
static.
root@washu:~ # hcidump -X -V
[*** shows a lot of stuff all the time similar to: ***]
> SCO data: handle 1 dlen 48
0000: f1 ff 57 ff 39 ff bb ff bb ff 28 ff 0d ff 83 ff
..W.9.....(.....
0010: c0 ff 72 ff 4d ff b3 ff 1b 00 0e 00 cc ff 13 00
..r.M...........
0020: 7e 00 37 01 3d 01 30 01 46 01 59 01 37 02 00 02
~.7.=.0.F.Y.7...
The output of hcidump continued even after aplay didn't do anything
anymore.
I already tried to use the btsco method: Slightly different debug output,
but the same net result.
Any ideas?
Ciao
Florian
Hi Florian,
Could you give me the output of
'hciconfig -a' once you have done the
'modprobe hci_usb force_scofix' ?
Cheers,
Fabien
> root@washu:~ # hciconfig hci0 revision
> hci0: Type: USB
> BD Address: 00:02:78:3D:18:DD ACL MTU: 1017:8 SCO MTU: 64:0
> Firmware 220.65 / 92
>
> I already tried to load hci_usb via "modprobe hci_usb force_scofix" as
> advised by the contact website but that didn't change anything. I'm using
> linux kernel 2.6.19 with the "plugz/patches/sco-flowcontrol-v3.0.diff"
> patches here.
>
> Does anyone have positive or negative experiences with this Broadcom
> adapter?
> Anything else I might try?
>
> Ciao
> Florian
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad
On Sun, 28 Jan 2007 10:12:30 -0700, Brad Midgley said:
> > Yes, it is. Therefore I' prefer not to buy and attach an external one.
> > Would somehow beat the purpose of using a bt headset...
>
> I can understand this. As far as I know broadcom hasn't helped Marcel
> and that's part of the reason it's hit-or-miss with different revs of
> their hardware.
Somehow I still don't want to give up --- yet. What are the symptoms with
those revs that won't work? Is this counting down of the
bt_headset->hw_ptr to zero with a stall afterward typical?
I've read about some patches for the 2.6.20 kernel. Is there anything in
there that might be helpful?
> > What patch do you mean? I'm using a vanilla 2.6.19 with just the
> > sco-flowcontrol-v3.0 patch from the bluetooth-alsa cvs. Is there anything
> > else I should try?
>
> that's the right one. It doesn't help your broadcom issue though.
Seemingly.
Ciao
Florian
Florian
> Yes, it is. Therefore I' prefer not to buy and attach an external one.
> Would somehow beat the purpose of using a bt headset...
I can understand this. As far as I know broadcom hasn't helped Marcel
and that's part of the reason it's hit-or-miss with different revs of
their hardware.
> What patch do you mean? I'm using a vanilla 2.6.19 with just the
> sco-flowcontrol-v3.0 patch from the bluetooth-alsa cvs. Is there anything
> else I should try?
that's the right one. It doesn't help your broadcom issue though.
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
On Sun, 28 Jan 2007 07:53:52 -0700, Brad Midgley said:
> > I already tried to load hci_usb via "modprobe hci_usb force_scofix" as
> > advised by the contact website but that didn't change anything. I'm using
> > linux kernel 2.6.19 with the "plugz/patches/sco-flowcontrol-v3.0.diff"
> > patches here.
> >
> > Does anyone have positive or negative experiences with this Broadcom
> > adapter?
> > Anything else I might try?
>
> you've tried with and without force_scofix then?
Yep. As far as I could see absolutely nothing changed by this.
> There are still some broadcom adapters that no one has gotten to work. I
> haven't been keeping track... it would be nice if we had a list.
>
> Is this an internal adapter you're stuck with?
Yes, it is. Therefore I' prefer not to buy and attach an external one.
Would somehow beat the purpose of using a bt headset...
> btw did you apply the flow control kernel patch?
What patch do you mean? I'm using a vanilla 2.6.19 with just the
sco-flowcontrol-v3.0 patch from the bluetooth-alsa cvs. Is there anything
else I should try?
Ciao
Florian
Florian
> I already tried to load hci_usb via "modprobe hci_usb force_scofix" as
> advised by the contact website but that didn't change anything. I'm using
> linux kernel 2.6.19 with the "plugz/patches/sco-flowcontrol-v3.0.diff"
> patches here.
>
> Does anyone have positive or negative experiences with this Broadcom
> adapter?
> Anything else I might try?
you've tried with and without force_scofix then?
There are still some broadcom adapters that no one has gotten to work. I
haven't been keeping track... it would be nice if we had a list.
Is this an internal adapter you're stuck with?
btw did you apply the flow control kernel patch?
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
OK, so I'll start and reply to myself a bit...
On Sat, 27 Jan 2007 19:39:37 +0100, Florian Schaefer said:
> I'm currently trying to get my "Logitech Mobile Pro II" headset connected
> to my Debian box using the new and shiny headsetd. It seems that I get a
> connection between my notebook and the headset when starting a test run
> of aplay (the speaker of the headset is activated and emits some quiet
> static sounds) but that's all that happens. Aplay will just kind of
> freezes and that's it.
>
> But now the information in more order (my CVS checkouts are from today):
>
> root@washu:~ # hciconfig -a
> hci0: Type: USB
> BD Address: 00:02:78:3D:18:DD ACL MTU: 1017:8 SCO MTU: 64:0
> UP RUNNING PSCAN
> RX bytes:397591 acl:21 sco:7760 events:50 errors:0
> TX bytes:806 acl:21 sco:0 commands:30 errors:0
> Features: 0xff 0xff 0x8d 0xfe 0x9b 0xfd 0x00 0x80
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy: RSWITCH HOLD SNIFF PARK
> Link mode: SLAVE ACCEPT
> Name: 'washu'
> Class: 0x3e0100
> Service Classes: Networking, Rendering, Capturing, Object
> Transfer, Audio
> Device Class: Computer, Uncategorized
> HCI Ver: 2.0 (0x3) HCI Rev: 0x20dc LMP Ver: 2.0 (0x3) LMP Subver:
> 0x415c
> Manufacturer: Broadcom Corporation (15)
Reading the bluetooth-alsa website once again, this USB-adapter seems to
be responsible:
root@washu:~ # hciconfig hci0 revision
hci0: Type: USB
BD Address: 00:02:78:3D:18:DD ACL MTU: 1017:8 SCO MTU: 64:0
Firmware 220.65 / 92
I already tried to load hci_usb via "modprobe hci_usb force_scofix" as
advised by the contact website but that didn't change anything. I'm using
linux kernel 2.6.19 with the "plugz/patches/sco-flowcontrol-v3.0.diff"
patches here.
Does anyone have positive or negative experiences with this Broadcom
adapter?
Anything else I might try?
Ciao
Florian
Hi everybody!
On Sun, 28 Jan 2007 19:44:06 +0100, Florian Schaefer said:
[...]
> On Sun, 28 Jan 2007 10:12:30 -0700, Brad Midgley said:
>
> > > Yes, it is. Therefore I' prefer not to buy and attach an external one.
> > > Would somehow beat the purpose of using a bt headset...
> >
> > I can understand this. As far as I know broadcom hasn't helped Marcel
> > and that's part of the reason it's hit-or-miss with different revs of
> > their hardware.
>
> Somehow I still don't want to give up --- yet. What are the symptoms with
> those revs that won't work? Is this counting down of the
> bt_headset->hw_ptr to zero with a stall afterward typical?
>
> I've read about some patches for the 2.6.20 kernel. Is there anything in
> there that might be helpful?
Just for the record: It turned out that my Broadcom bluetooth does work
after all. I just had to make sure, that the hci_usb modules gets loaded
with the force_scofix option the _first time_ it gets loaded after a new
system start.
This old btsco method works fine then. The newer headsetd doesn't work
that good however. All I get to hear is a rather deep distorted,
disrupted sound, as if is is played with a much too low sample rate.
However, those sounds don't seem to depend on the file I play, therefore
I rule a frequency problem out.
Ciao
Florian