New bluez headset implementation

Hello all, i've been spending most of my spare time in the past month writing an alternative implementation to btsco for headsets support.

Hello all, i've been spending most of my spare time in the past month writing an alternative implementation to btsco for headsets support. The starting point was me being frustrated not to be able to use my laptop for VoIP because of crappy microphones the manufacturers usually put in. So my goal now is to go wireless with bluetooth. :-) So here i am. The software i wrote is now mature enough to be shared with others.

What i'm looking for now is peer review from experienced bluez developpers about it. But that's enough about me, let's talk about the software :-)

So What's In ?

What is implemented is the AG side of the headset profile. Both Headset initiated connections and access gateway initiated connections are supported. It does not support A2DP, as it is another profile, and moreover people here are already working on the subject :-)

The spirit that governed the design was the following:
- be able to handle voice over IP applications well (this means
keeping buffering at a minimum for a reduced latency)
- make it easy to use for open source VoIp apps developpers (the idea
is that it should be very easy for the apps to provide some basic support for bluetooth headsets with no change to the application itself)
- support 100% of bluetooth headset profile (device
connect/disconnect, headset button push)

The architecture is the following:
- 1 daemon, responsible for doing SDP, handling RFCOMM and SCO
channels, parsing AT commands, sending DBUS signals when things happen. The daemon handles application requests (referred to as AG initiated connection in HSP spec) or headset connection requests (referred to as HS initiated connection in HSP spec)
The daemon also handles session caching between PCM open/close.
- 2 ALSA user space IO plugins (1 control, 1 PCM). Both of them
communicate with the daemon using unix sockets. The PCM also has an instance of the SCO socket, so that it can reads/write data directly to it.

Compared to btsco, it differs in the following way:
- it is 100% userspace. No more kernel module.
- all parameters are supplied by the application to the alsa pcm
plugin, that will eventually forward them to the daemon. This will make implementation of user friendly MMI much easier (in particular, there is no need to lauch the daemon separately with a predefined BD address. The gui will thus be able to provide bd address).
- it handles only one active headset at a time
- it supports HS initiated connections as well
- codebase cleaner. It should be possible with minimal pain to support handsfree profile.

Still to be done :
1) more testing
2) DBUS signalling to tell the world about connected /
disconnected / button pushed events.
3) some kind of switching from headset to an alternate sound device
in case the headset is unavailable.
4) interoperability testing against a variety of devices.
5) document the design
6) debug kernel sco support (more on that on a separate e-mail)

I'm likely to do 3), 5), however 1 and 2 might be better handled by somebody else, and 4 is just everybody's work :-)

Where to get the software:
Simple! On my hard disk!! No i'm kidding... but in fact not
completely. ;-)
I don't wanna start a whole open source project for such a small
thing. So for now i will send it by private e-mail to developers interested in giving it a try. Just reply to this e-mail if you are interested.

How to play with the software:
- use standard aplay/arecord tools (not very funny)
- use xmms (a litte more funny :-) )
- use ekiga 2.0.1 (top fun!- however you will need to patch it and
rebuild it)

Fabien

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hello all, i've been spending most of my spare time in the past month writing an alternative implementation to btsco for headsets support. The starting point was me being frustrated not to be able to use my laptop for VoIP because of crappy microphones the manufacturers usually put in. So my goal now is to go wireless with bluetooth. :-) So here i am. The software i wrote is now mature enough to be shared with others.

What i'm looking for now is peer review from experienced bluez developpers about it. But that's enough about me, let's talk about the software :-)

So What's In ?

What is implemented is the AG side of the headset profile. Both Headset initiated connections and access gateway initiated connections are supported. It does not support A2DP, as it is another profile, and moreover people here are already working on the subject :-)

The spirit that governed the design was the following:
- be able to handle voice over IP applications well (this means
keeping buffering at a minimum for a reduced latency)
- make it easy to use for open source VoIp apps developpers (the idea
is that it should be very easy for the apps to provide some basic support for bluetooth headsets with no change to the application itself)
- support 100% of bluetooth headset profile (device
connect/disconnect, headset button push)

The architecture is the following:
- 1 daemon, responsible for doing SDP, handling RFCOMM and SCO
channels, parsing AT commands, sending DBUS signals when things happen. The daemon handles application requests (referred to as AG initiated connection in HSP spec) or headset connection requests (referred to as HS initiated connection in HSP spec)
The daemon also handles session caching between PCM open/close.
- 2 ALSA user space IO plugins (1 control, 1 PCM). Both of them
communicate with the daemon using unix sockets. The PCM also has an instance of the SCO socket, so that it can reads/write data directly to it.

Compared to btsco, it differs in the following way:
- it is 100% userspace. No more kernel module.
- all parameters are supplied by the application to the alsa pcm
plugin, that will eventually forward them to the daemon. This will make implementation of user friendly MMI much easier (in particular, there is no need to lauch the daemon separately with a predefined BD address. The gui will thus be able to provide bd address).
- it handles only one active headset at a time
- it supports HS initiated connections as well
- codebase cleaner. It should be possible with minimal pain to support handsfree profile.

Still to be done :
1) more testing
2) DBUS signalling to tell the world about connected /
disconnected / button pushed events.
3) some kind of switching from headset to an alternate sound device
in case the headset is unavailable.
4) interoperability testing against a variety of devices.
5) document the design
6) debug kernel sco support (more on that on a separate e-mail)

I'm likely to do 3), 5), however 1 and 2 might be better handled by somebody else, and 4 is just everybody's work :-)

Where to get the software:
Simple! On my hard disk!! No i'm kidding... but in fact not
completely. ;-)
I don't wanna start a whole open source project for such a small
thing. So for now i will send it by private e-mail to developers interested in giving it a try. Just reply to this e-mail if you are interested.

How to play with the software:
- use standard aplay/arecord tools (not very funny)
- use xmms (a litte more funny :-) )
- use ekiga 2.0.1 (top fun!- however you will need to patch it and
rebuild it)

Fabien

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Fabien,

here you are a first report on your headset support. I have a
Motorola HS850 and use it in conjunction with a Thinkpad X40 with bluetooth-modem integrated adapter.

I have patched and compiled ekiga and selected the bluetooth headset device. Everithing works fine in general (nice work) but:

- if I close and reopen the headset then ekiga no longer finds the audio device

- if I change the device in the preferences and then put back the bluetooth headset ekiga no longer finds the bluetooth device.

In both cases the only solution is to close and reopen ekiga.

Woth xmms instad the beahviour is *quite* bizarre. When I select the headset in the alsa plugin the music is played about 4 times faster and the console prints repeatedly the following warning.

** WARNING **: alsa_mmap_audio(): snd_pcm_mmap_commit returned 24, expected 104

As soon as I change de device (e.g. to default) or pass to OSS then this weird behavior completely desappears and the song is played correctly.

I guess that you already know it but
- pressing the headset button has no visible effect

- the device does not appear in the alsa mixer

Quoted 2 lines

- if I close and reopen the headset then ekiga no longer finds the audio device

Do you mean ending a call by closing the headset ??

Quoted 3 lines

- if I change the device in the preferences and then put back the bluetooth headset ekiga no longer finds the bluetooth device.

Hmmm... strange. Could you please be a little more precise on that ?

Quoted 5 lines

In both cases the only solution is to close and reopen ekiga.

Woth xmms instad the beahviour is *quite* bizarre. When I select the headset in the alsa plugin the music is played about 4 times faster and the console prints repeatedly the following warning.

** WARNING **: alsa_mmap_audio(): snd_pcm_mmap_commit returned 24, expected 104

I would even say 104 / 24 = 4,3333 time faster.

That's weird as xmms works really perfectly on my box. :-(
COuld you give me details about your software configuration (xmms version, alsa version, OS version..) ?

Could you also try to remove line 322 in file pcm_bluez_headset, and see if it works better ?

Quoted 1 line

- the device does not appear in the alsa mixer

You're wrong on this one.
If you launch 'alsamixer -Dheadset' you will see your headset controls,
and if you play with volume controls while in a middle of a call you should ear the difference.

Quoted 6 lines · Fabien Chevalier

Quoted 2 lines

- if I close and reopen the headset then ekiga no longer finds the audio device

Do you mean ending a call by closing the headset ??

Yes, exactly. If I close the headset during a conversation then ekiga completely freezes.

Quoted 8 lines

Quoted 6 lines

- if I change the device in the preferences and then put back the bluetooth headset ekiga no longer finds the bluetooth device.

Hmmm... strange. Could you please be a little more precise on that ?

Even stranger, I can no longer reproduce it. Well.

Quoted 5 lines

Quoted 5 lines

In both cases the only solution is to close and reopen ekiga.

Woth xmms instad the beahviour is *quite* bizarre. When I select the headset in the alsa plugin the music is played about 4 times faster and the console prints repeatedly the following warning.

Quoted 8 lines

Quoted 1 line

** WARNING **: alsa_mmap_audio(): snd_pcm_mmap_commit returned 24, expected 104

I would even say 104 / 24 = 4,3333 time faster.

That's weird as xmms works really perfectly on my box. :-(
COuld you give me details about your software configuration (xmms version, alsa version, OS version..) ?

alsa-lib-1.0.11-3.rc2.2
alsa-utils-1.0.11-4.rc2
alsa-lib-devel-1.0.11-3.rc2.2
xmms-1.2.10-23.fc5
xmms-mp3-1.2.10-16.fc5
xmms-libs-1.2.10-23.fc5
Linux mirto 2.6.17-rc4 #1 Tue May 16 17:58:16 CEST 2006 i686 i686 i386 GNU/Linux[

Quoted 3 lines

Could you also try to remove line 322 in file pcm_bluez_headset, and see if it works better ?

Done, and yes indeed it works.

But the sound is not perfect. I hear some frying sound (un petit gresillement), not very disturbing though but it is absent when I use it with Ekiga.

Quoted 7 lines

Quoted 1 line

- the device does not appear in the alsa mixer

You're wrong on this one.
If you launch 'alsamixer -Dheadset' you will see your headset controls,
and if you play with volume controls while in a middle of a call you should ear the difference.

Right. Just a couple of questions then. How can I have it appear in gnome volume control.

And how to use the headset with, say, skype?

Quoted 2 lines

Yes, exactly. If I close the headset during a conversation then ekiga completely freezes.

For now this is not supported :-)

In the long run it should be possible to tell ekiga that the headset has closed, however this would require some king of communication between headsetd and ekiga -- i'm not there yet :-(

Quoted 3 lines

But the sound is not perfect. I hear some frying sound (un petit gresillement), not very disturbing though but it is absent when I use it with Ekiga.

I noticed that. It's not perfect yet.
I'm currently working on improving voice quality in general, but i looks it will end up with a kernel patch.

Quoted 1 line

Quoted 1 line

Quoted 1 line

- the device does not appear in the alsa mixer

this is only going to work if egika will listen for dbus events to that effect. alsa provides nothing for signaling.

Quoted 10 lines

Quoted 5 lines

But the sound is not perfect. I hear some frying sound (un petit gresillement), not very disturbing though but it is absent when I use it with Ekiga.

I noticed that. It's not perfect yet.
I'm currently working on improving voice quality in general, but i looks it will end up with a kernel patch.

We've had quality problems that might be attributed to improperly pacing the data sent through sco. I am not sure what the kernel provides--if anything--in terms of timing.

What kind of kernel patch you are looking into?

alsa has two ways to look for devices. plugins do not show up using the api everyone is used to unfortunately.

Brad

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Quoted 5 lines

We've had quality problems that might be attributed to improperly pacing the data sent through sco. I am not sure what the kernel provides--if anything--in terms of timing.

Could you provide further information on these other quality problems ? Just out of curiosity ;-)

Fabien

Quoted 6 lines

Quoted 5 lines

We've had quality problems that might be attributed to improperly pacing the data sent through sco. I am not sure what the kernel provides--if anything--in terms of timing.

Quoted 2 lines

Could you provide further information on these other quality problems ? Just out of curiosity ;-)

the high and lo bytes sometimes get out of sync so we are reading part of the previous sample and part of the next one when capturing from the mic. the result is noise.

the output sometimes gets stuck in a mode in which it generates only static that might be a similar problem.

HCI Event: Command Status (0x0f) plen 4

HCI Event: Connect Complete (0x03) plen 11

HCI Event: Command Status (0x0f) plen 4

HCI Event: Command Complete (0x0e) plen 6

HCI Event: Number of Completed Packets (0x13) plen 5

ACL data: handle 1 flags 0x02 dlen 16

ACL data: handle 1 flags 0x02 dlen 16

HCI Event: Number of Completed Packets (0x13) plen 5

HCI Event: Number of Completed Packets (0x13) plen 5

ACL data: handle 1 flags 0x02 dlen 14

HCI Event: Number of Completed Packets (0x13) plen 5

ACL data: handle 1 flags 0x02 dlen 8

HCI Event: Number of Completed Packets (0x13) plen 5

ACL data: handle 1 flags 0x02 dlen 18

HCI Event: Number of Completed Packets (0x13) plen 5

HCI Event: PIN Code Request (0x16) plen 6

HCI Event: Command Complete (0x0e) plen 10

HCI Event: Link Key Notification (0x18) plen 23

ACL data: handle 1 flags 0x02 dlen 8

HCI Event: Number of Completed Packets (0x13) plen 5

HCI Event: Number of Completed Packets (0x13) plen 5

HCI Event: Number of Completed Packets (0x13) plen 5

ACL data: handle 1 flags 0x02 dlen 12

ACL data: handle 1 flags 0x02 dlen 12

ACL data: handle 1 flags 0x02 dlen 9

HCI Event: Number of Completed Packets (0x13) plen 5

Hello all, i've been spending most of my spare time in the past month writing an alternative implementation to btsco for headsets support. The starting point was me being frustrated not to be able to use my laptop for VoIP because of crappy microphones the manufacturers usually put in. So my goal now is to go wireless with bluetooth. :-) So here i am. The software i wrote is now mature enough to be shared with others.

What i'm looking for now is peer review from experienced bluez developpers about it. But that's enough about me, let's talk about the software :-)

So What's In ?

What is implemented is the AG side of the headset profile. Both Headset initiated connections and access gateway initiated connections are supported. It does not support A2DP, as it is another profile, and moreover people here are already working on the subject :-)

The spirit that governed the design was the following:
- be able to handle voice over IP applications well (this means
keeping buffering at a minimum for a reduced latency)
- make it easy to use for open source VoIp apps developpers (the idea
is that it should be very easy for the apps to provide some basic support for bluetooth headsets with no change to the application itself)
- support 100% of bluetooth headset profile (device
connect/disconnect, headset button push)

The architecture is the following:
- 1 daemon, responsible for doing SDP, handling RFCOMM and SCO
channels, parsing AT commands, sending DBUS signals when things happen. The daemon handles application requests (referred to as AG initiated connection in HSP spec) or headset connection requests (referred to as HS initiated connection in HSP spec)
The daemon also handles session caching between PCM open/close.
- 2 ALSA user space IO plugins (1 control, 1 PCM). Both of them
communicate with the daemon using unix sockets. The PCM also has an instance of the SCO socket, so that it can reads/write data directly to it.

Compared to btsco, it differs in the following way:
- it is 100% userspace. No more kernel module.
- all parameters are supplied by the application to the alsa pcm
plugin, that will eventually forward them to the daemon. This will make implementation of user friendly MMI much easier (in particular, there is no need to lauch the daemon separately with a predefined BD address. The gui will thus be able to provide bd address).
- it handles only one active headset at a time
- it supports HS initiated connections as well
- codebase cleaner. It should be possible with minimal pain to support handsfree profile.

Still to be done :
1) more testing
2) DBUS signalling to tell the world about connected /
disconnected / button pushed events.
3) some kind of switching from headset to an alternate sound device
in case the headset is unavailable.
4) interoperability testing against a variety of devices.
5) document the design
6) debug kernel sco support (more on that on a separate e-mail)

I'm likely to do 3), 5), however 1 and 2 might be better handled by somebody else, and 4 is just everybody's work :-)

Where to get the software:
Simple! On my hard disk!! No i'm kidding... but in fact not
completely. ;-)
I don't wanna start a whole open source project for such a small
thing. So for now i will send it by private e-mail to developers interested in giving it a try. Just reply to this e-mail if you are interested.

How to play with the software:
- use standard aplay/arecord tools (not very funny)
- use xmms (a litte more funny :-) )
- use ekiga 2.0.1 (top fun!- however you will need to patch it and
rebuild it)

Fabien

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Fabien,

I was testing this application (basichspd) with two headsets. But it seems that I am able to connect on RFCOMM but there is no SCO connection establishment taking place.
On the application side, it says SCO connected but when I see the hcidump logs, there is no SetupSynchronousConnection Command going out.

Please suggest what is the problem.

hciconfig -a shows:

hci0: Type: UART

        BD Address: XX:XX:XX:XX:XX:XX ACL MTU: 1021:7  SCO MTU: 64:0
        UP RUNNING PSCAN ISCAN AUTH ENCRYPT
        RX bytes:4740 acl:108 sco:0 events:238 errors:0
        TX bytes:2923 acl:117 sco:0 commands:55 errors:0
        Features: 0xff 0xeb 0x8d 0xfe 0x9b 0xe9 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: ''
        Class: 0x000000
        Service Classes: Unspecified
        Device Class: Miscellaneous,
        HCI Ver: n/a (0x3) HCI Rev: 0x402 LMP Ver: n/a (0x3) LMP Subver:

0x520

hciconfig hci0 features shows:

hci0: Type: UART

        BD Address: XX:XX:XX:XX:XX:XX ACL MTU: 1021:7  SCO MTU: 64:0
        Features: 0xff 0xeb 0x8d 0xfe 0x9b 0xe9 0x00 0x00
                <3-slot packets> <5-slot packets> <encryption> <slot

offset>
<timing accuracy> <role switch> <hold mode> <sniff mode> <park state> <RSSI> <SCO link> <HV3 packets> <u-law log> <A-law log> <CVSD> <power control> <transparent SCO> <broadcast encrypt> <EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan> <interlaced iscan> <interlaced pscan> <inquiry with RSSI> <extended SCO> <EV4 packets> <EV5
packets>
<AFH cap. slave> <AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL> <AFH cap. master> <EDR eSCO 2 Mbps> <EDR eSCO 3 Mbps> <3-slot EDR eSCO>

hciconfig hci0 revision does not print anything about SCO mapping :(

The hcidump -X shows:

HCI sniffer - Bluetooth packet analyzer ver 1.30
device: hci0 snap_len: 1028 filter: 0xffffffff < HCI Command: Create Connection (0x01|0x0005) plen 13
0000: d3 52 23 89 03 00 18 cc 00 00 00 00 01 .R#..........

Quoted 1 line

HCI Event: Command Status (0x0f) plen 4

0000: 00 01 05 04 ....

Quoted 1 line

HCI Event: Connect Complete (0x03) plen 11

0000: 00 01 00 d3 52 23 89 03 00 01 00 ....R#.....

Quoted 1 line

HCI Event: Command Status (0x0f) plen 4

0000: 00 02 00 00 ....
< ACL data: handle 1 flags 0x02 dlen 12

    L2CAP(s): Connect req: psm 3 scid 0x0040

< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
0000: 01 00 0f 00 ....

Quoted 1 line

HCI Event: Command Complete (0x0e) plen 6

0000: 02 0d 08 00 01 00 ......

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5

0000: 01 01 00 01 00 .....

Quoted 1 line

ACL data: handle 1 flags 0x02 dlen 16

    L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0040 result 0 status 0
      Connection successful
< ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
      MTU 1024

Quoted 1 line

ACL data: handle 1 flags 0x02 dlen 16

    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
      MTU 328
< ACL data: handle 1 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
      Success

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5

0000: 01 01 00 01 00 .....

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5

0000: 01 01 00 01 00 .....

Quoted 1 line

ACL data: handle 1 flags 0x02 dlen 14

    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
      Success
< ACL data: handle 1 flags 0x02 dlen 8
    L2CAP(d): cid 0x0041 len 4 [psm 3]
      RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5

0000: 01 01 00 01 00 .....

Quoted 1 line

ACL data: handle 1 flags 0x02 dlen 8

    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7

< ACL data: handle 1 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8 dlci 4 frame_type 0 credit_flow 15 pri 0 ack_timer 0 frame_size 323 max_retrans 0 credits 7

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5

0000: 01 01 00 01 00 .....

Quoted 1 line

ACL data: handle 1 flags 0x02 dlen 18

L2CAP(d): cid 0x0040 len 14 [psm 3]
RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8 dlci 4 frame_type 0 credit_flow 14 pri 0 ack_timer 0 frame_size 100 max_retrans 0 credits 3
< ACL data: handle 1 flags 0x02 dlen 8

    L2CAP(d): cid 0x0041 len 4 [psm 3]
      RFCOMM(s): SABM: cr 1 dlci 4 pf 1 ilen 0 fcs 0x96

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5

0000: 01 01 00 01 00 .....

Quoted 1 line

HCI Event: PIN Code Request (0x16) plen 6

0000: d3 52 23 89 03 00 .R#...
< HCI Command: PIN Code Request Reply (0x01|0x000d) plen 23
0000: d3 52 23 89 03 00 04 30 30 30 30 00 00 00 00 00 .R#....0000.....
0010: 00 00 00 00 00 00 00 .......

Quoted 1 line

HCI Event: Command Complete (0x0e) plen 10

0000: 02 0d 04 00 d3 52 23 89 03 00 .....R#...

Quoted 1 line

HCI Event: Link Key Notification (0x18) plen 23

0000: d3 52 23 89 03 00 52 71 66 24 06 e6 dd 31 f8 66 .R#...Rqf$...1.f
0010: ee cc a2 e5 46 4e 00 ....FN.

Quoted 1 line

ACL data: handle 1 flags 0x02 dlen 8

    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 4 pf 1 ilen 0 fcs 0x5d
< ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(d): cid 0x0041 len 8 [psm 3]
      RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
      dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10
< ACL data: handle 1 flags 0x02 dlen 9
    L2CAP(d): cid 0x0041 len 5 [psm 3]
      RFCOMM(d): UIH: cr 1 dlci 4 pf 1 ilen 0 fcs 0x79 credits 33
< ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(d): cid 0x0041 len 8 [psm 3]
      RFCOMM(d): UIH: cr 1 dlci 4 pf 0 ilen 4 fcs 0x65
      0000: 52 49 4e 47                                       RING

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5

0000: 01 01 00 01 00 .....

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5

0000: 01 01 00 01 00 .....

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5

0000: 01 01 00 01 00 .....

Quoted 1 line

ACL data: handle 1 flags 0x02 dlen 12

    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
      dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10

Quoted 1 line

ACL data: handle 1 flags 0x02 dlen 12

    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
      dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10
< ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(d): cid 0x0041 len 8 [psm 3]
      RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
      dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10

Quoted 1 line

ACL data: handle 1 flags 0x02 dlen 9

    L2CAP(d): cid 0x0040 len 5 [psm 3]
      RFCOMM(d): UIH: cr 0 dlci 4 pf 1 ilen 0 fcs 0xa3 credits 1

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5

0000: 01 01 00 01 00 .....

Thanks.

Regards,
Mayank

Quoted 103 lines · Fabien Chevalier

Hello all, i've been spending most of my spare time in the past month writing an alternative implementation to btsco for headsets support.
The starting point was me being frustrated not to be able to use my laptop for VoIP because of crappy microphones the manufacturers usually put in. So my goal now is to go wireless with bluetooth. :-) So here i am. The software i wrote is now mature enough to be shared with others.

What i'm looking for now is peer review from experienced bluez developpers about it. But that's enough about me, let's talk about the software :-)

So What's In ?

What is implemented is the AG side of the headset profile. Both Headset initiated connections and access gateway initiated connections are supported. It does not support A2DP, as it is another profile, and moreover people here are already working on the subject :-)

The spirit that governed the design was the following:
- be able to handle voice over IP applications well (this means
keeping buffering at a minimum for a reduced latency)
- make it easy to use for open source VoIp apps developpers (the idea
is that it should be very easy for the apps to provide some basic support for bluetooth headsets with no change to the application itself)
- support 100% of bluetooth headset profile (device
connect/disconnect, headset button push)

The architecture is the following:
- 1 daemon, responsible for doing SDP, handling RFCOMM and SCO
channels, parsing AT commands, sending DBUS signals when things happen. The daemon handles application requests (referred to as AG initiated connection in HSP spec) or headset connection requests (referred to as HS initiated connection in HSP spec)
The daemon also handles session caching between PCM open/close.
- 2 ALSA user space IO plugins (1 control, 1 PCM). Both of them
communicate with the daemon using unix sockets. The PCM also has an instance of the SCO socket, so that it can reads/write data directly to it.

Compared to btsco, it differs in the following way:
- it is 100% userspace. No more kernel module.
- all parameters are supplied by the application to the alsa pcm
plugin, that will eventually forward them to the daemon. This will make implementation of user friendly MMI much easier (in particular, there is no need to lauch the daemon separately with a predefined BD address. The gui will thus be able to provide bd address).
- it handles only one active headset at a time
- it supports HS initiated connections as well
- codebase cleaner. It should be possible with minimal pain to support handsfree profile.

Still to be done :
1) more testing
2) DBUS signalling to tell the world about connected /
disconnected / button pushed events.
3) some kind of switching from headset to an alternate sound device
in case the headset is unavailable.
4) interoperability testing against a variety of devices.
5) document the design
6) debug kernel sco support (more on that on a separate e-mail)

I'm likely to do 3), 5), however 1 and 2 might be better handled by somebody else, and 4 is just everybody's work :-)

Where to get the software:
Simple! On my hard disk!! No i'm kidding... but in fact not
completely. ;-)
I don't wanna start a whole open source project for such a small
thing. So for now i will send it by private e-mail to developers interested in giving it a try. Just reply to this e-mail if you are interested.

How to play with the software:
- use standard aplay/arecord tools (not very funny)
- use xmms (a litte more funny :-) )
- use ekiga 2.0.1 (top fun!- however you will need to patch it and
rebuild it)

Fabien

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Fabien/Brad,

Any suggestions on the mail below?

Regards,
Mayank

On 7/7/06, *Mayank Batra* <[email protected]
<mailto:[email protected]>> wrote:

    Hi Fabien,
     
    I was testing this application (basichspd) with two headsets.
    But it seems that I am able to connect on RFCOMM but there is no SCO
    connection establishment taking place.
    On the application side, it says SCO connected but when I see the
    hcidump logs, there is no SetupSynchronousConnection Command going out.
     
    Please suggest what is the problem.
     
    hciconfig -a shows:
     
    hci0:   Type: UART
            BD Address: XX:XX:XX:XX:XX:XX ACL MTU: 1021:7  SCO MTU: 64:0
            UP RUNNING PSCAN ISCAN AUTH ENCRYPT
            RX bytes:4740 acl:108 sco:0 events:238 errors:0
            TX bytes:2923 acl:117 sco:0 commands:55 errors:0
            Features: 0xff 0xeb 0x8d 0xfe 0x9b 0xe9 0x00 0x00
            Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV3
            Link policy: RSWITCH HOLD SNIFF PARK
            Link mode: SLAVE ACCEPT
            Name: ''
            Class: 0x000000
            Service Classes: Unspecified
            Device Class: Miscellaneous,
            HCI Ver: n/a (0x3) HCI Rev: 0x402 LMP Ver: n/a (0x3) LMP
    Subver: 0x520
     
    hciconfig hci0 features shows:
     
    hci0:   Type: UART
            BD Address: XX:XX:XX:XX:XX:XX ACL MTU: 1021:7  SCO MTU: 64:0
            Features: 0xff 0xeb 0x8d 0xfe 0x9b 0xe9 0x00 0x00
                    <3-slot packets> <5-slot packets> <encryption> <slot
    offset>
                    <timing accuracy> <role switch> <hold mode> <sniff
    mode>
                    <park state> <RSSI> <SCO link> <HV3 packets> <u-law
    log>
                    <A-law log> <CVSD> <power control> <transparent SCO>
                    <broadcast encrypt> <EDR ACL 2 Mbps> <EDR ACL 3 Mbps>
                    <enhanced iscan> <interlaced iscan> <interlaced pscan>
                    <inquiry with RSSI> <extended SCO> <EV4 packets>
    <EV5 packets>
                    <AFH cap. slave> <AFH class. slave> <3-slot EDR ACL>
                    <5-slot EDR ACL> <AFH cap. master> <EDR eSCO 2 Mbps>
                    <EDR eSCO 3 Mbps> <3-slot EDR eSCO>
     

    hciconfig hci0 revision does not print anything about SCO mapping :(
     
    The hcidump -X shows:
     
    HCI sniffer - Bluetooth packet analyzer ver 1.30
    device: hci0 snap_len: 1028 filter: 0xffffffff
    < HCI Command: Create Connection (0x01|0x0005) plen 13
      0000: d3 52 23 89 03 00 18 cc  00 00 00 00 01           .R#..........
     > HCI Event: Command Status (0x0f) plen 4
      0000: 00 01 05 04                                       ....
     > HCI Event: Connect Complete (0x03) plen 11
      0000: 00 01 00 d3 52 23 89 03  00 01 00                 ....R#.....
     > HCI Event: Command Status (0x0f) plen 4
      0000: 00 02 00 00                                       ....
    < ACL data: handle 1 flags 0x02 dlen 12
        L2CAP(s): Connect req: psm 3 scid 0x0040
    < HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
      0000: 01 00 0f 00                                       ....
     > HCI Event: Command Complete (0x0e) plen 6
      0000: 02 0d 08 00 01 00                                 ......
     > HCI Event: Number of Completed Packets (0x13) plen 5
      0000: 01 01 00 01 00                                    .....
     > ACL data: handle 1 flags 0x02 dlen 16
        L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0040 result 0 status 0
          Connection successful
    < ACL data: handle 1 flags 0x02 dlen 16
        L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
          MTU 1024
     > ACL data: handle 1 flags 0x02 dlen 16
        L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
          MTU 328
    < ACL data: handle 1 flags 0x02 dlen 14
        L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
          Success
     > HCI Event: Number of Completed Packets (0x13) plen 5
      0000: 01 01 00 01 00                                    .....
     > HCI Event: Number of Completed Packets (0x13) plen 5
      0000: 01 01 00 01 00                                    .....
     > ACL data: handle 1 flags 0x02 dlen 14
        L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
          Success
    < ACL data: handle 1 flags 0x02 dlen 8
        L2CAP(d): cid 0x0041 len 4 [psm 3]
          RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
     > HCI Event: Number of Completed Packets (0x13) plen 5
      0000: 01 01 00 01 00                                    .....
     > ACL data: handle 1 flags 0x02 dlen 8
        L2CAP(d): cid 0x0040 len 4 [psm 3]
          RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
    < ACL data: handle 1 flags 0x02 dlen 18
        L2CAP(d): cid 0x0041 len 14 [psm 3]
          RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
          dlci 4 frame_type 0 credit_flow 15 pri 0 ack_timer 0
          frame_size 323 max_retrans 0 credits 7
     > HCI Event: Number of Completed Packets (0x13) plen 5
      0000: 01 01 00 01 00                                    .....
     > ACL data: handle 1 flags 0x02 dlen 18
        L2CAP(d): cid 0x0040 len 14 [psm 3]
          RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
          dlci 4 frame_type 0 credit_flow 14 pri 0 ack_timer 0
          frame_size 100 max_retrans 0 credits 3
    < ACL data: handle 1 flags 0x02 dlen 8
        L2CAP(d): cid 0x0041 len 4 [psm 3]
          RFCOMM(s): SABM: cr 1 dlci 4 pf 1 ilen 0 fcs 0x96
     > HCI Event: Number of Completed Packets (0x13) plen 5
      0000: 01 01 00 01 00                                    .....
     > HCI Event: PIN Code Request (0x16) plen 6
      0000: d3 52 23 89 03 00                                 .R#...
    < HCI Command: PIN Code Request Reply (0x01|0x000d) plen 23
      0000: d3 52 23 89 03 00 04 30  30 30 30 00 00 00 00 00 
    .R#....0000.....
      0010: 00 00 00 00 00 00 00                              .......
     > HCI Event: Command Complete (0x0e) plen 10
      0000: 02 0d 04 00 d3 52 23 89  03 00                    .....R#...
     > HCI Event: Link Key Notification (0x18) plen 23
      0000: d3 52 23 89 03 00 52 71  66 24 06 e6 dd 31 f8 66 
    .R#...Rqf$...1.f
      0010: ee cc a2 e5 46 4e 00                              ....FN.
     > ACL data: handle 1 flags 0x02 dlen 8
        L2CAP(d): cid 0x0040 len 4 [psm 3]
          RFCOMM(s): UA: cr 1 dlci 4 pf 1 ilen 0 fcs 0x5d
    < ACL data: handle 1 flags 0x02 dlen 12
        L2CAP(d): cid 0x0041 len 8 [psm 3]
          RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
          dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10
    < ACL data: handle 1 flags 0x02 dlen 9
        L2CAP(d): cid 0x0041 len 5 [psm 3]
          RFCOMM(d): UIH: cr 1 dlci 4 pf 1 ilen 0 fcs 0x79 credits 33
    < ACL data: handle 1 flags 0x02 dlen 12
        L2CAP(d): cid 0x0041 len 8 [psm 3]
          RFCOMM(d): UIH: cr 1 dlci 4 pf 0 ilen 4 fcs 0x65
          0000: 52 49 4e 47                                       RING
     > HCI Event: Number of Completed Packets (0x13) plen 5
      0000: 01 01 00 01 00                                    .....
     > HCI Event: Number of Completed Packets (0x13) plen 5
      0000: 01 01 00 01 00                                    .....
     > HCI Event: Number of Completed Packets (0x13) plen 5
      0000: 01 01 00 01 00                                    .....
     > ACL data: handle 1 flags 0x02 dlen 12
        L2CAP(d): cid 0x0040 len 8 [psm 3]
          RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
          dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10
     > ACL data: handle 1 flags 0x02 dlen 12
        L2CAP(d): cid 0x0040 len 8 [psm 3]
          RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
          dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10
    < ACL data: handle 1 flags 0x02 dlen 12
        L2CAP(d): cid 0x0041 len 8 [psm 3]
          RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
          dlci 4 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 10
     > ACL data: handle 1 flags 0x02 dlen 9
        L2CAP(d): cid 0x0040 len 5 [psm 3]
          RFCOMM(d): UIH: cr 0 dlci 4 pf 1 ilen 0 fcs 0xa3 credits 1
     > HCI Event: Number of Completed Packets (0x13) plen 5
      0000: 01 01 00 01 00                                    .....
     
     
    Thanks.
     
    Regards,
    Mayank
     

     
    On 5/19/06, *Fabien Chevalier* < [email protected]
    <mailto:[email protected]>> wrote:


        Hello all, i've been spending most of my spare time in the past
        month writing an alternative implementation to btsco for
        headsets support.
        The starting point was me being frustrated not to be able to use my
        laptop for VoIP because of crappy microphones the manufacturers
        usually
        put in. So my goal now is to go wireless with bluetooth. :-)
        So here i am. The software i wrote is now mature enough to be
        shared
        with others.

        What i'm looking for now is peer review from experienced bluez
        developpers about it. But that's enough about me, let's talk
        about the
        software :-)

        So What's In ?

        What is implemented is the AG side of the headset profile. Both
        Headset
        initiated connections and access gateway initiated connections are
        supported. It does not support A2DP, as it is another profile, and
        moreover people here are already working on the subject :-)

        The spirit that governed the design was the following:
          - be able to handle voice over IP applications well (this means
        keeping buffering at a minimum for a reduced latency)
          - make it easy to use for open source VoIp apps developpers
        (the idea
        is that it should be very easy for the apps to provide some basic
        support for bluetooth headsets with no change to the application
        itself)
          - support 100% of bluetooth headset profile (device
        connect/disconnect, headset button push)

        The architecture is the following:
          - 1 daemon, responsible for doing SDP, handling RFCOMM and SCO
        channels, parsing AT commands, sending DBUS signals when things
        happen.
        The daemon handles application requests (referred to as AG initiated
        connection in HSP spec) or headset connection requests (referred
        to as
        HS initiated connection in HSP spec)
        The daemon also handles session caching between PCM open/close.
          - 2 ALSA user space IO plugins (1 control, 1 PCM). Both of them
        communicate with the daemon using unix sockets. The PCM also has an
        instance of the SCO socket, so that it can reads/write data
        directly to it.

        Compared to btsco, it differs in the following way:
          - it is 100% userspace. No more kernel module.
          - all parameters are supplied by the application to the alsa pcm
        plugin, that will eventually forward them to the daemon. This
        will make
        implementation of user friendly MMI much easier (in particular,
        there
        is no need to lauch the daemon separately with a predefined BD
        address.
        The gui will thus be able to provide bd address).
          - it handles only one active headset at a time
          - it supports HS initiated connections as well
          - codebase cleaner. It should be possible with minimal pain to
            support handsfree profile.

        Still to be done :
          1) more testing
          2) DBUS signalling to tell the world about connected /
        disconnected / button pushed events.
          3) some kind of switching from headset to an alternate sound
        device
        in case the headset is unavailable.
          4) interoperability testing against a variety of devices.
          5) document the design
          6) debug kernel sco support (more on that on a separate e-mail)

        I'm likely to do 3), 5), however 1 and 2 might be better handled
        by somebody else, and 4 is just everybody's work :-)

        Where to get the software:
          Simple! On my hard disk!!   No i'm kidding... but in fact not
        completely. ;-)
          I don't wanna start a whole open source project for such a small
        thing. So for now i will send it by private e-mail to developers
        interested in giving it a try. Just reply to this e-mail if you are
        interested.

        How to play with the software:
          - use standard aplay/arecord tools (not very funny)
          - use xmms (a litte more funny :-) )
          - use ekiga 2.0.1 (top fun!- however you will need to patch it and
        rebuild it)


        Fabien






        -------------------------------------------------------
        Using Tomcat but need to do more? Need to support web services,
        security?
        Get stuff done quickly with pre-integrated technology to make
        your job easier
        Download IBM WebSphere Application Server v.1.0.1 based on
        Apache Geronimo
        http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
        <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
        _______________________________________________
        Bluez-devel mailing list
        [email protected]
        <mailto:[email protected]>
        https://lists.sourceforge.net/lists/listinfo/bluez-devel
        <https://lists.sourceforge.net/lists/listinfo/bluez-devel>

------------------------------------------------------------------------

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

------------------------------------------------------------------------

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel