Hi all,
I am using bluez 4.51. After much fiddling, I seem to have my audio
headset doing something -- something other than reporting errors anyway.
I can do:
$ aplay /mnt/mp3/bad_mouth.wav -Dplug:bluetoothraw
Playing WAVE '/mnt/mp3/bad_mouth.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
to the device defined as:
pcm.bluetoothraw {
type bluetooth
device 00:1A:45:1B:19:89
}
and aplay appears to be doing something and
$ hcidump -t -X -V
reports lots of:
2009-12-31 00:08:57.233899 > SCO data: handle 1 flags 0x00 dlen 48
0000: fd ff e6 ff af ff 4e ff 41 ff 5a ff 20 ff 53 ff ......N.A.Z. .S.
0010: a0 ff 6b ff 89 ff bc ff 5d ff 85 ff 3c ff d9 fe ..k.....]...<...
0020: 2b ff 28 ff 58 ff 53 ff 1b ff 3c ff 29 ff 49 ff +.(.X.S...<.).I.
2009-12-31 00:08:57.233901 > SCO data: handle 1 flags 0x00 dlen 48
0000: 9b ff b1 ff a2 ff 71 ff b5 ff 9f ff 52 ff fa fe ......q.....R...
0010: 8e fe 4e ff 98 ff ed ff 13 00 88 ff 91 ff f3 fe ..N.............
0020: 2f ff c2 ff 6d ff 95 ff 62 ff d2 fe ec fe 61 ff /...m...b.....a.
2009-12-31 00:08:57.233903 > SCO data: handle 1 flags 0x00 dlen 48
0000: 5e ff 2b ff 26 ff 01 ff a5 ff 9c ff 5a ff 2f ff ^.+.&.......Z./.
0010: 8b fe 1b ff c7 ff fa ff f0 ff 53 ff e1 fe 28 ff ..........S...(.
0020: b7 ff be ff 41 ff 55 ff 16 ff 3f ff de ff fa fe ....A.U...?.....
2009-12-31 00:08:57.233905 > SCO data: handle 1 flags 0x00 dlen 48
0000: 0f ff a1 ff 66 ff f6 ff 06 00 c8 ff 75 ff 16 ff ....f.......u...
0010: f4 fe f0 fe e5 fe d3 fe eb fe 5d ff e5 ff e9 ff ..........].....
0020: 84 ff 7b ff c7 ff de ff ae ff 85 ff a1 ff 58 ff ..{...........X.
2009-12-31 00:08:57.243898 > SCO data: handle 1 flags 0x00 dlen 48
0000: f0 fe 3c fe a6 fe 49 ff 3d ff c0 ff 93 ff 73 ff ..<...I.=.....s.
0010: 41 ff 85 ff c5 ff 67 ff 63 ff 2c ff 1a ff 23 ff A.....g.c.,...#.
0020: 51 ff af ff 28 ff d5 fe 50 ff 83 ff e8 ff e4 ff Q...(...P.......
2009-12-31 00:08:57.243901 > SCO data: handle 1 flags 0x00 dlen 48
0000: 01 ff 15 ff d0 fe ba fe 95 ff a2 ff b7 ff ed ff ................
0010: 7e ff a9 ff a1 ff e5 fe 3b ff 70 ff 63 ff 7f ff ~.......;.p.c...
0020: 3c ff 2b ff be fe ee fe 58 ff 7c ff 40 ff fb fe <.+.....X.|.@...
2009-12-31 00:08:57.243903 > SCO data: handle 1 flags 0x00 dlen 48
0000: 39 ff 34 ff b6 ff c1 ff 7d ff a0 ff 6a ff 79 ff 9.4.....}...j.y.
0010: 37 ff 0c ff 4d ff 15 ff 43 ff 66 ff 3e ff 71 ff 7...M...C.f.>.q.
0020: 8e ff 8c ff 06 ff d4 fe 0e ff 2e ff 8a ff 24 ff ..............$.
2009-12-31 00:08:57.253914 > SCO data: handle 1 flags 0x00 dlen 48
0000: da fe 57 ff b3 ff bf ff 7f ff 49 ff 41 ff ee fe ..W.......I.A...
0010: 08 ff 91 ff a2 ff 9d ff 48 ff da fe 52 ff 55 ff ........H...R.U.
0020: 87 ff 98 ff 25 ff 1d ff 35 ff b9 ff 83 ff b1 ff ....%...5.......
2009-12-31 00:08:57.253918 > SCO data: handle 1 flags 0x00 dlen 48
0000: 7d ff 37 ff 5e ff 40 ff 3b ff 08 ff 01 ff dc fe }.7.^.@.;.......
0010: 15 ff 1c ff 8b ff 8b ff 40 ff 90 ff 3a ff c6 ff ........@...:...
0020: 71 ff 4a ff 88 ff 3c ff bc ff 3e ff e4 fe fe fe q.J...<...>.....
2009-12-31 00:08:57.253920 > SCO data: handle 1 flags 0x00 dlen 48
0000: f9 fe 2c ff a2 ff bb ff 89 ff 65 ff 21 ff 62 ff ..,.......e.!.b.
0010: b9 ff b4 ff 48 ff f4 fe 42 ff 86 ff ad ff 53 ff ....H...B.....S.
0020: 20 ff 00 ff dd fe 71 ff 79 ff 59 ff a6 ff 8f ff .....q.y.Y.....
2009-12-31 00:08:57.263898 > SCO data: handle 1 flags 0x00 dlen 48
0000: 57 ff c2 ff a8 ff d9 fe eb fe 5a ff 89 ff 71 ff W.........Z...q.
0010: 1f ff 1e ff 27 ff 3f ff 3e ff 63 ff 71 ff 26 ff ....'.?.>.c.q.&.
0020: fd fe 03 ff 63 ff 9b ff b6 ff 91 ff 75 ff 79 ff ....c.......u.y.
2009-12-31 00:08:57.263901 > SCO data: handle 1 flags 0x00 dlen 48
0000: 29 ff 51 ff ee fe c9 fe 12 ff 85 ff a6 ff 45 ff ).Q...........E.
0010: 38 ff 52 ff d7 ff f7 ff 96 ff e9 fe 99 fe d5 fe 8.R.............
0020: 5e ff 9c ff 4d ff 1e ff c5 fe 2f ff b8 ff cf ff ^...M...../.....
2009-12-31 00:08:57.263903 > SCO data: handle 1 flags 0x00 dlen 48
0000: f1 ff b2 ff aa ff 82 ff 8a ff 5f ff 47 ff 50 ff .........._.G.P.
0010: 4a ff ad ff 58 ff 1a ff 43 ff 78 ff 44 ff ef fe J...X...C.x.D...
0020: 02 ff 05 ff 42 ff 61 ff bb ff d8 ff cd ff 01 00 ....B.a.........
2009-12-31 00:08:57.263905 > SCO data: handle 1 flags 0x00 dlen 48
0000: 28 ff e5 fe f4 fe f1 fe ad ff 33 ff f6 fe ed fe (.........3.....
0010: 7b fe 45 ff be ff 9c ff ac ff 2b ff 34 ff 7a ff {.E.......+.4.z.
0020: 3e ff af ff d3 ff 00 ff 6f ff 69 ff 26 ff 9d ff >.......o.i.&...
2009-12-31 00:08:57.273899 > SCO data: handle 1 flags 0x00 dlen 48
0000: 7d ff 8e ff 52 ff 36 ff 2a ff fe fe 63 ff d2 ff }...R.6.*...c...
0010: eb ff 92 ff 7a ff 36 ff 22 ff 68 ff d6 ff e0 ff ....z.6.".h.....
0020: 66 ff b8 fe 68 fe f0 fe 3a ff 69 ff 85 ff a5 ff f...h...:.i.....
2009-12-31 00:08:57.273901 > SCO data: handle 1 flags 0x00 dlen 48
0000: 72 ff 2d ff ae ff d2 ff 74 ff 24 ff 29 ff 05 ff r.-.....t.$.)...
0010: e2 fe e1 fe 2f ff f5 fe cd fe 73 ff 85 ff cc ff ..../.....s.....
0020: 8c ff 68 ff 8a ff 9f ff 28 00 80 ff 37 ff 29 ff ..h.....(...7.).
2009-12-31 00:08:57.273903 > SCO data: handle 1 flags 0x00 dlen 48
0000: 12 ff 70 ff 46 ff 20 ff 47 ff 75 ff 8f ff ab ff ..p.F. .G.u.....
0010: 4f ff 59 ff 80 ff d1 fe d2 fe 84 ff dd ff 77 ff O.Y...........w.
0020: a7 fe 7c fe 27 ff 7f ff 6c ff 55 ff 1d ff 3a ff ..|.'...l.U...:.
2009-12-31 00:08:57.283898 > SCO data: handle 1 flags 0x00 dlen 48
0000: 6a ff 8e ff d6 ff 9c ff 89 ff ac ff 80 ff ab ff j...............
0010: 3c ff e9 fe e1 fe 22 ff cd ff 7c ff 1e ff 9d fe <....."...|.....
0020: 09 ff eb ff d6 ff 97 ff 1b ff 38 ff 61 ff cb ff ..........8.a...
2009-12-31 00:08:57.283901 > SCO data: handle 1 flags 0x00 dlen 48
0000: f4 ff 70 ff 87 ff 9d ff 29 00 1f 00 8e ff 4b ff ..p.....).....K.
0010: f6 fe 0b ff ea fe c1 fe e1 fe 1a ff 06 ff fb fe ................
0020: 3e ff 5f ff a8 ff c4 ff a5 ff 8a ff 4c ff 1b ff >._.........L...
2009-12-31 00:08:57.283903 > SCO data: handle 1 flags 0x00 dlen 48
0000: 02 ff 14 ff 03 ff 5d ff 9b ff 1d ff 29 ff 53 ff ......].....).S.
0010: 95 ff c5 ff af ff 3d ff e6 fe 4a ff 7a ff 7a ff ......=...J.z.z.
0020: de ff cb ff 4f ff 4a ff cc ff fd ff d7 ff 60 ff ....O.J.......`.
2009-12-31 00:08:57.293896 > SCO data: handle 1 flags 0x00 dlen 48
0000: ab ff bf ff 0f ff 09 ff d9 fe fc fe 22 ff 0b ff ............"...
0010: 24 ff b5 fe 44 ff a6 ff 8d ff b7 ff 69 ff 21 ff $...D.......i.!.
0020: f1 fe e0 fe 3d ff 78 ff 55 ff fb fe b0 fe 41 ff ....=.x.U.....A.
2009-12-31 00:08:57.293898 > SCO data: handle 1 flags 0x00 dlen 48
0000: c2 ff 95 ff 55 ff 78 ff 22 00 07 00 f3 ff 7f ff ....U.x.".......
0010: fb fe 1e ff 27 ff 84 ff 13 ff 17 ff 50 ff 75 ff ....'.......P.u.
0020: fb ff cc ff 82 ff 70 ff 60 ff d3 ff bf ff 29 ff ......p.`.....).
2009-12-31 00:08:57.293900 > SCO data: handle 1 flags 0x00 dlen 48
0000: 4b ff fe fe 03 ff 18 ff c7 fe 64 ff 9e ff 6b ff K.........d...k.
0010: 50 ff 3e ff 71 ff 38 ff 52 ff 8d ff 3f ff d0 ff P.>.q.8.R...?...
0020: 00 00 be ff a3 ff 51 ff 8c ff 22 ff 14 ff 3f ff ......Q..."...?.
2009-12-31 00:08:57.293902 > SCO data: handle 1 flags 0x00 dlen 48
0000: 1d ff 5e ff 15 ff fe fe 45 ff 28 ff fa fe fe fe ..^.....E.(.....
0010: b5 ff 85 00 ea ff 2d ff 0c ff 75 ff d4 ff a4 ff ......-...u.....
0020: b9 ff 3a ff 65 ff 96 ff e0 fe ea fe fc fe 8b ff ..:.e...........
2009-12-31 00:08:57.303898 > SCO data: handle 1 flags 0x00 dlen 48
0000: 95 ff 38 ff 69 ff 85 ff a8 ff 76 ff 55 ff f8 fe ..8.i.....v.U...
0010: 24 ff 90 ff e4 fe fb fe 77 ff 5d ff 60 ff 66 ff $.......w.].`.f.
0020: 42 ff 4a ff 51 ff 13 ff f4 fe 44 ff a5 ff ea ff B.J.Q.....D.....
2009-12-31 00:08:57.303901 > SCO data: handle 1 flags 0x00 dlen 48
0000: c9 ff 28 ff e7 fe 21 ff dc fe b7 fe 0e ff 76 ff ..(...!.......v.
0010: ab ff a5 ff 6f ff 8a ff a3 ff f1 ff be ff 6c ff ....o.........l.
0020: 76 ff 4a ff a9 ff 5f ff 2c ff 38 ff a2 fe eb fe v.J..._.,.8.....
2009-12-31 00:08:57.303903 > SCO data: handle 1 flags 0x00 dlen 48
0000: ed ff 88 ff 58 ff bd ff ba ff 86 ff f4 fd fd fe ....X...........
0010: 71 00 f4 fe 4e fe f9 ff a4 00 9a fd b4 ff 61 00 q...N.........a.
0020: 20 fe a9 00 75 ff 92 fe 3f fe af fe f7 00 30 ff ...u...?.....0.
2009-12-31 00:08:57.313896 > SCO data: handle 1 flags 0x00 dlen 48
0000: 15 ff c2 ff 59 ff 6a fe 5a ff 4a 00 30 ff 68 ff ....Y.j.Z.J.0.h.
0010: 30 ff 17 ff 20 00 73 00 4a ff 8d ff 2e ff 72 fe 0... .s.J.....r.
0020: 9a ff a5 fe 0a ff 31 ff af fe d0 00 c1 ff cf fe ......1.........
2009-12-31 00:08:57.313898 > SCO data: handle 1 flags 0x00 dlen 48
0000: 9d ff 2d ff 60 ff f1 ff d8 ff aa fe 13 ff 87 ff ..-.`...........
0010: 2e ff 51 ff fb fe 15 00 94 ff 6f ff 4c 00 c8 fe ..Q.......o.L...
0020: 75 fe 95 ff 55 ff 76 ff 65 ff fe fe d7 fe f4 fe u...U.v.e.......
like traffic and bluetoothd reports:
Dec 31 00:06:04 pc bluetoothd[16063]: Accepted new client connection on unix socket (fd=23)
Dec 31 00:06:04 pc bluetoothd[16063]: Audio API: BT_REQUEST <- BT_GET_CAPABILITIES
Dec 31 00:06:04 pc bluetoothd[16063]: Audio API: BT_RESPONSE -> BT_GET_CAPABILITIES
Dec 31 00:06:04 pc bluetoothd[16063]: Audio API: BT_REQUEST <- BT_OPEN
Dec 31 00:06:04 pc bluetoothd[16063]: open sco - object=ANY source=ANY destination=00:1A:45:1B:19:89 lock=write
Dec 31 00:06:04 pc bluetoothd[16063]: Audio API: BT_RESPONSE -> BT_OPEN
Dec 31 00:06:04 pc bluetoothd[16063]: Audio API: BT_REQUEST <- BT_SET_CONFIGURATION
Dec 31 00:06:04 pc bluetoothd[16063]: Audio API: BT_RESPONSE -> BT_SET_CONFIGURATION
Dec 31 00:06:04 pc bluetoothd[16063]: Audio API: BT_REQUEST <- BT_START_STREAM
Dec 31 00:06:04 pc bluetoothd[16063]: State changed /org/bluez/16062/hci0/dev_00_1A_45_1B_19_89: HEADSET_STATE_CONNECTED -> HEADSET_STATE_PLAY_IN_PROGRESS
Dec 31 00:06:05 pc bluetoothd[16063]: SCO socket opened for headset /org/bluez/16062/hci0/dev_00_1A_45_1B_19_89
Dec 31 00:06:05 pc bluetoothd[16063]: SCO fd=24
Dec 31 00:06:05 pc bluetoothd[16063]: Audio API: BT_RESPONSE -> BT_START_STREAM
Dec 31 00:06:05 pc bluetoothd[16063]: Audio API: BT_INDICATION -> BT_NEW_STREAM
Dec 31 00:06:05 pc bluetoothd[16063]: State changed /org/bluez/16062/hci0/dev_00_1A_45_1B_19_89: HEADSET_STATE_PLAY_IN_PROGRESS -> HEADSET_STATE_PLAYING
And the headset beeps when I interrupt the aplay.
I just don't actually get any audio in the headset.
I have tested the headset with a phone and it works perfectly. The
headset details are:
# hcitool info 00:1A:45:1B:19:89
Requesting information ...
BD Address: 00:1A:45:1B:19:89
Device Name: Jabra BT125
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>
and the dongle details are:
# hciconfig -a
hci0: Type: USB
BD Address: 00:0D:18:01:3B:9B ACL MTU: 1017:8 SCO MTU: 64:0
UP RUNNING PSCAN ISCAN
RX bytes:7769227 acl:146 sco:152180 events:231 errors:0
TX bytes:3729 acl:132 sco:0 commands:102 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: 'pc-0'
Class: 0x0a0104
Service Classes: Networking, Capturing
Device Class: Computer, Desktop workstation
HCI Ver: 2.0 (0x3) HCI Rev: 0x4000 LMP Ver: 2.0 (0x3) LMP Subver: 0x430e
Manufacturer: Broadcom Corporation (15)
Any ideas?
b.
On Fri, 2010-01-29 at 13:42 -0800, Gunn, Brian wrote:
>
> Don't know if this will help you guys or not, but I get garbled audio unless I specify a 48 byte buffer.
Sadly, no, this does not help. :-(
> Here's the command I use to send audio to headsets:
>
> aplay -D bluetooth -f S16_LE --buffer-size=48 test.wav
>
> For me though, without the "--buffer-size=48", I get audio; it's just really garbled.
I've never got garbled. Just always get the beep before and after the
audio is supposed to be playing.
b.
PiA+ICQgYXBsYXkgLUQgczgwNSA4ay53YXYNCj4gPiAgIFBsYXlpbmcgV0FWRSAnOGsud2F2JyA6
IFVuc2lnbmVkIDggYml0LCBSYXRlIDgwMDAgSHosIE1vbm8NCj4NCj4gV2hlbiBJIHVzZSBzb3gg
dG8gcHJvdmlkZSB0aGUgc2FtZSBraW5kIG9mIGlucHV0LCBJIGdldCBubyBsdWNrOg0KPg0KPiAk
IHNveCAvbW50L21wMy9iYWRfbW91dGgud2F2IC1jIDEgLWIgOCAtciA4ayAtdCB3YXYgLSB8IGFw
bGF5IC1EIGJsdWV0b290aGZvbw0KPiBQbGF5aW5nIFdBVkUgJ3N0ZGluJyA6IFVuc2lnbmVkIDgg
Yml0LCBSYXRlIDgwMDAgSHosIE1vbm8NCj4NCj4gSSBzdGlsbCBnZXQgbm90aGluZyBleGNlcHQg
dGhlIGhlYWRzZXQgYmVlcHMgd2hlbiB0aGUgc3RyZWFtIHN0YXJ0cyBhbmQgdGhlbg0KPiBlbmRz
Lg0KDQpEb24ndCBrbm93IGlmIHRoaXMgd2lsbCBoZWxwIHlvdSBndXlzIG9yIG5vdCwgYnV0IEkg
Z2V0IGdhcmJsZWQgYXVkaW8gdW5sZXNzIEkgc3BlY2lmeSBhIDQ4IGJ5dGUgYnVmZmVyLiAgSGVy
ZSdzIHRoZSBjb21tYW5kIEkgdXNlIHRvIHNlbmQgYXVkaW8gdG8gaGVhZHNldHM6DQoNCmFwbGF5
IC1EIGJsdWV0b290aCAtZiBTMTZfTEUgLS1idWZmZXItc2l6ZT00OCB0ZXN0Lndhdg0KDQpGb3Ig
bWUgdGhvdWdoLCB3aXRob3V0IHRoZSAiLS1idWZmZXItc2l6ZT00OCIsIEkgZ2V0IGF1ZGlvOyBp
dCdzIGp1c3QgcmVhbGx5IGdhcmJsZWQuDQoNCkJyaWFuDQoNCg==
On Thu, 2010-01-28 at 21:50 -0600, [email protected] wrote:
>
> Good point. I set up a debug environment (again), created some 8k Hz audio
> files, and confirmed that you are correct.
>
> But the 8k mono file worked in my environment.
Unfortunately it doesn't in my environment. :-(
> I put the S805 headset into HFP mode and did this:
Hrm. I don't know that I have to or know how to do this with my
headset. Can you elaborate?
> $ aplay -D s805 8k.wav
> Playing WAVE '8k.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
When I use sox to provide the same kind of input, I get no luck:
$ sox /mnt/mp3/bad_mouth.wav -c 1 -b 8 -r 8k -t wav - | aplay -D bluetoothfoo
Playing WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
I still get nothing except the headset beeps when the stream starts and
then ends. FWIW, my alsa configuration for bluetoothfoo:
pcm.bluetoothraw {
type bluetooth
device 00:1A:45:1B:19:89
#profile "auto" #optional, supported profiles are: auto, hifi and
voice
#profile "voice" #optional, supported profiles are: auto, hifi and
voice
}
pcm.bluetoothfoo {
type plug
slave {
pcm bluetoothraw
}
}
Trying to use bluetoothraw directly doesn't work either:
$ sox /mnt/mp3/bad_mouth.wav -c 1 -b 8 -r 8k -t wav - | aplay -D bluetoothraw
Playing WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
aplay: set_params:979: Sample format non available
> and verified that I was using the SCO path (HSP/HFP) by firing up hcidump
> during playback:
>
> # hcidump -x
Me too:
> [snip]
> SCO data: handle 1 flags 0x00 dlen 48
DD FF 2C 00 B9 FD 86 FF 5D FF 06 FE 52 FF 89 FD F6 FE 55 FF
77 FD 4A FF 84 FF 4C FE FA FE ED FF 6C 00 D6 FF 43 FE 20 00
E1 00 E3 FF FD 00 03 00
> SCO data: handle 1 flags 0x00 dlen 48
CB FE C0 FE 24 FE 77 FE 39 FF A3 FD B6 FF A9 FF 32 FD 6C 01
B5 FE E5 FD DD 00 4A FE 2F 01 C1 FF C0 FD B2 00 05 00 61 FF
FE FF CF FF F3 FF 03 FF
> SCO data: handle 1 flags 0x00 dlen 48
3A 00 71 00 3E FF 4D 00 59 FF D7 FF 1C 00 E7 FE 3B FF E9 FF
2A FE 2E FF BC FF 7E FC AC FE 1A FF 70 FE 30 FF A8 FD 58 FF
69 FF 68 FE 76 FF 4E 00
> The bluetooth USB computer dongle:
>
> # hciconfig -a
> hci0: Type: USB
> BD Address: AA:BB:CC:DD:EE:FF ACL MTU: 1021:7 SCO MTU: 64:1
> UP RUNNING PSCAN
> RX bytes:64829124 acl:41 sco:1271103 events:139 errors:0
> TX bytes:3077 acl:43 sco:0 commands:85 errors:0
> Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x79 0x83
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy: RSWITCH HOLD SNIFF PARK
> Link mode: SLAVE ACCEPT
> Name: 'atom-0'
> Class: 0x4a0104
> Service Classes: Networking, Capturing, Telephony
> Device Class: Computer, Desktop workstation
> HCI Ver: 2.1 (0x4) HCI Rev: 0x5332 LMP Ver: 2.1 (0x4) LMP Subver: 0x420e
> Manufacturer: Broadcom Corporation (15)
Just for contrast, here's mine:
$ hciconfig -a
hci0: Type: USB
BD Address: 00:0D:18:01:3B:9B ACL MTU: 1017:8 SCO MTU: 64:0
UP RUNNING PSCAN ISCAN
RX bytes:3679050 acl:84 sco:72118 events:143 errors:13
TX bytes:2177 acl:75 sco:0 commands:59 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: 'pc-0'
Class: 0x0a0104
Service Classes: Networking, Capturing
Device Class: Computer, Desktop workstation
HCI Ver: 2.0 (0x3) HCI Rev: 0x4000 LMP Ver: 2.0 (0x3) LMP Subver: 0x430e
Manufacturer: Broadcom Corporation (15)
Interestingly enough, both are Broadcom dongles.
> Keep me posted (maybe privately???)
Please, to the list, so that everyone can benefit.
> if you find any good nuggets.
b.
On Wed, 27 Jan 2010 11:28:54 +0800 Chao Deng <[email protected]> wrote:
> On Tue, Jan 26, 2010 at 9:23 AM, <[email protected]> wrote:
> > On Sun, 24 Jan 2010 23:21:56 -0500 "Brian J. Murrell"
> > <[email protected]> wrote:
> >
> >> On Mon, 2010-01-25 at 12:13 +0800, Chao Deng wrote:
> >> > Hi, Brain,
> >> >
> >> > I have the same problem like you. Do you find the root cause of it?
> >>
> >> Nope, not a clue. Unfortunately my posting here didn't get any ideas of
> >> why or what I should do to debug either. I kinda gave up, yet again, as
> >> I have done many times in the last 2-3 years of simply trying to get a
> >> Bluetooth headset working on Linux. Sadly it always seems like the
> >> answer is "next [kernel|bluez] release -- it should work great".
> >>
> >> > The kernel I used is 2.6.31, and the bluez is 4.51
> >>
> >> Seems we are in the same boat.
> >>
> >> Sorry I don't have better answers for you.
> >>
> >> b.
> >>
> >
> > Yep. It's unfortunate that no one responded. I've spent many hours digging
> > into this bug, and was hoping that others my have some valid
> > pointers/directions.
> >
> > Anyway, I'm not a Bluez developer, nor do I speak fluent "Bluetooth", but
> > here's what I've found so far...
> >
> > This is not a new bug. Galaha Shine found the crux of the problem back in
> > 2008:
> >
> > http://mailman.alsa-project.org/pipermail/alsa-devel/2008-September/010721.html
> >
> > and after firing up my debugger, this still seems to be the same issue today
> > (at least when I looked at the previous releases).
> >
> > As you may know, headsets can have different bluetooth capabilities
> > described in their profiles. There's the HSP/HFP profiles for doing things
> > like talking on the phone, and then there's the A2DP profile for listening
> > in stereo. And there are others.
> >
> > Brian, you don't state which profile you're using when it fails, but from
> > looking at your hcidump info, it appears like it's HSP or HFP because your
> > data packets are 48 bytes long... which is the MTU size in Bluez for
> > HSP/HFP. When using the A2DP profile (if supported by your headset), the
> > data packets are much larger.
> >
> > Chao, I have 2 sets of Motorola S805's also, and it can do both of those
> > "types" of profiles. If the headset is put into HFP mode, then you
> > experience the joy of this problem. In A2DP mode, it (mostly) works if you
> > only want to listen in stereo.
> >
> > The root cause of the problem (at least from my debugging experience) is
> > that if you are using HSP or HFP mode... and your application is talking
> > directly to ALSA (like "aplay" does)... then your audio data eventually
> > makes it's way to the snd_pcm_rate_commit_area() function in ALSA in 48
> > byte (MTU sized) "chunks". But, if this function receives less than a
> > "slave_size" amount of data, it simply drops it by calling the
> > snd_pcm_rewind() function.
> >
> > To super simplify the problem description, Bluez keeps sending 48 byte
> > "chunks" of audio data, that ALSA happily ignores... nice.
> >
> > Just like Galaha, I'm stuck trying finding a solution. I tried his Bluez
> > patch, but it doesn't work. And so far, I've not been able to get my head
> > wrapped around even a "big picture" of the Bluez SCO data path to find an
> > acceptable alternative. With the goal being to create a (hopefully
> > suitable) patch to some component, somewhere... anywhere. Or possibly
> > there's another solution??? Any help would be appreciated.
> >
> > It *appears* that others *may* be having some success using PulseAudio for
> > this, but I prefer not to go there... just call me stubborn.
> > --
>
> You are right that I want to test the HSP/HFP profile, and A2DP works
> well for me.
> Thank you for your suggestions for debugging.
>
> Maybe you don't use 8000Hz mono stream to test, so it needs to
> resample the stream
> to 8Khz to send. But I use a 8khz stream, the program don't go to function
> snd_pcm_rate_commit_area. I trace the calling procedure like following:
> aplay--->playback (aplay.c)--->pcm_write(aplay.c)--->snd_pcm_writei(pcm.c)
> --->snd_pcm_ioplug_writei(pcm_ioplug.c)--->snd_pcm_write_areas(pcm.c)--->
> ioplug_priv_transfer_areas(pcm_ioplug.c)--->bluetooth_hsp_write(pcm_bluetooth.c)
> --->send
> I think that the audio date has been sent by bluetooth, but still no sound.
> Do you have any ideas?
> --
Good point. I set up a debug environment (again), created some 8k Hz audio
files, and confirmed that you are correct. The code path doesn't go thru the
ALSA snd_pcm_rate_commit_area() function if the audio doesn't need to be
resampled.
But the 8k mono file worked in my environment.
I put the S805 headset into HFP mode and did this:
$ aplay -D s805 8k.wav
Playing WAVE '8k.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
and verified that I was using the SCO path (HSP/HFP) by firing up hcidump
during playback:
# hcidump -x
[snip]
< SCO data: handle 1 flags 0x00 dlen 48
00 21 00 2E 00 30 00 1A 00 00 00 FB 00 F1 00 E3 00 E6 00 E4
00 DA 00 D0 00 DA 00 E4 00 E8 00 00 00 13 00 0C 00 F8 00 F0
00 07 00 28 00 3F 00 54
< SCO data: handle 1 flags 0x00 dlen 48
00 38 00 07 00 E4 00 E2 00 05 00 20 00 05 00 E0 00 C5 00 B6
00 D3 00 F8 00 0E 00 04 00 E3 00 F0 00 18 00 32 00 4A 00 4C
00 2C 00 01 00 F0 00 01
[snip]
It also worked with a 8k Hz, S16_LE, 2 channel audio file:
$ aplay -D s805 big8k.wav
Playing WAVE 'big8k.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo
This got me excited enough to try this:
$ arecord -D s805 junk.wav
Recording WAVE 'junk.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
But alas, playing back 'junk.wav' thru a known good audio card only produced a
"ticking" sound. I haven't dug any deeper into this yet.
It also still failed to play a 44.1k Hz, S16_LE, 2 channel audio file. The
debugger showed that it's still the same problem Galaha found (i.e. resampling
doesn't work).
Not sure why 8k Hz mono is failing for you.
I put a breakpoint at bluetooth_hsp_write(), then played the 8K Hz mono file,
and here's the stack trace on my box:
(gdb) where
#0 bluetooth_hsp_write (io=0x805fb08, areas=0x80568c0, offset=0, size=1000)
at audio/pcm_bluetooth.c:906
#1 0xb7f83d09 in ioplug_priv_transfer_areas (pcm=0x8060cd0, areas=0x80568c0,
offset=0, size=1000) at pcm_ioplug.c:546
#2 0xb7f84328 in snd_pcm_ioplug_mmap_commit (pcm=0x8060cd0, offset=0,
size=1000) at pcm_ioplug.c:615
#3 0xb7f355e7 in snd_pcm_mmap_commit (pcm=0x8060cd0, offset=0, frames=1000)
at pcm.c:6490
#4 0xb7f4565b in snd_pcm_plugin_write_areas (pcm=0x8061ed8, areas=0xbffff650,
offset=0, size=1000) at pcm_plugin.c:290
#5 0xb7f359f5 in snd1_pcm_write_areas (pcm=0x8061ed8, areas=0xbffff650,
offset=0, size=1000, func=0xb7f45505 <snd_pcm_plugin_write_areas>)
at pcm.c:6656
#6 0xb7f45a26 in snd_pcm_plugin_writei (pcm=0x8061ed8, buffer=0x8060f50,
size=1000) at pcm_plugin.c:361
#7 0xb7f2ca75 in _snd_pcm_writei (pcm=0x8060e28, buffer=0x8060f50, size=1000)
at pcm_local.h:516
#8 0xb7f2df29 in snd_pcm_writei (pcm=0x8060e28, buffer=0x8060f50, size=1000)
at pcm.c:1247
#9 0x0804f30d in pcm_write (
data=0x8060f50 "\200", '\177' <repeats 11 times>"\200,
\200\200\177\177\177\177\200\200\177\177\200\200\200\200\177\200\201\202\177|\200\201\177~\177\202\201~~\205\203x}\205\200{z\201\205}z\202\203\177~\200\204\204\201}{~~}y{\202\202||\205\211\203z\200\211\204z}\206\204}w}\206\177x\200\205\200}~\203\203|z}|uux{{y~\203\205\211\216\223\226\224\214\206\203{rnnpv{}\204\204\206\213\213\206\203~xtlknmpxz|\201\213\226\244\242\212\224\230\205k\\nqXYx\201v\177\232\266\240x\213\235\205e\\mo_\\ouoz\222\227\206y}\223\262\271\214w\226\232|W[\203uRf\212"...,
count=1000) at aplay.c:1529 #10 0x08051790 in playback_go (fd=9, loaded=0,
count=45898, rtype=2, name=0xbffffbb9 "./8k.wav") at aplay.c:2272
#11 0x08051b30 in playback (name=0xbffffbb9 "./8k.wav") at aplay.c:2332
#12 0x0804bd96 in main (argc=4, argv=0xbffffa24) at aplay.c:659
It's pretty much the same path you describe, execpt that it includes the
*_mmap_commit() calls.
Here's my setup:
>From ~/.asoundrc:
pcm.s805 {
type plug
slave {
pcm {
type bluetooth
device AA:BB:CC:DD:EE:FF
profile "auto"
}
}
hint {
show on
description "Motorola S805 bluetooth headset"
}
}
Everything is commented out in /etc/bluetooth/audio.conf except for these:
[General]
SCORouting=HCI
[Headset]
HFP=true
MaxConnected=3
I haven't changed any of other config files in /etc/bluetooth/*.
Version Levels:
alsa-lib 1.0.22
alsa-utils 1.0.22
bluez 4.59
The bluetooth USB computer dongle:
# hciconfig -a
hci0: Type: USB
BD Address: AA:BB:CC:DD:EE:FF ACL MTU: 1021:7 SCO MTU: 64:1
UP RUNNING PSCAN
RX bytes:64829124 acl:41 sco:1271103 events:139 errors:0
TX bytes:3077 acl:43 sco:0 commands:85 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x79 0x83
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'atom-0'
Class: 0x4a0104
Service Classes: Networking, Capturing, Telephony
Device Class: Computer, Desktop workstation
HCI Ver: 2.1 (0x4) HCI Rev: 0x5332 LMP Ver: 2.1 (0x4) LMP Subver: 0x420e
Manufacturer: Broadcom Corporation (15)
Keep me posted (maybe privately???) if you find any good nuggets.
On Tue, Jan 26, 2010 at 9:23 AM, <[email protected]> wrote:
> On Sun, 24 Jan 2010 23:21:56 -0500 "Brian J. Murrell" <[email protected]>
> wrote:
>
>> On Mon, 2010-01-25 at 12:13 +0800, Chao Deng wrote:
>> > Hi, Brain,
>> >
>> > I have the same problem like you. Do you find the root cause of it?
>>
>> Nope, not a clue. ?Unfortunately my posting here didn't get any ideas of
>> why or what I should do to debug either. ?I kinda gave up, yet again, as
>> I have done many times in the last 2-3 years of simply trying to get a
>> Bluetooth headset working on Linux. ?Sadly it always seems like the
>> answer is "next [kernel|bluez] release -- it should work great".
>>
>> > The kernel I used is 2.6.31, and the bluez is 4.51
>>
>> Seems we are in the same boat.
>>
>> Sorry I don't have better answers for you.
>>
>> b.
>>
>
> Yep. It's unfortunate that no one responded. I've spent many hours digging into
> this bug, and was hoping that others my have some valid pointers/directions.
>
> Anyway, I'm not a Bluez developer, nor do I speak fluent "Bluetooth", but
> here's what I've found so far...
>
> This is not a new bug. Galaha Shine found the crux of the problem back in 2008:
>
> http://mailman.alsa-project.org/pipermail/alsa-devel/2008-September/010721.html
>
> and after firing up my debugger, this still seems to be the same issue today
> (at least when I looked at the previous releases).
>
> As you may know, headsets can have different bluetooth capabilities described
> in their profiles. There's the HSP/HFP profiles for doing things like talking on
> the phone, and then there's the A2DP profile for listening in stereo. And there
> are others.
>
> Brian, you don't state which profile you're using when it fails, but from
> looking at your hcidump info, it appears like it's HSP or HFP because your data
> packets are 48 bytes long... which is the MTU size in Bluez for HSP/HFP. When
> using the A2DP profile (if supported by your headset), the data packets are
> much larger.
>
> Chao, I have 2 sets of Motorola S805's also, and it can do both of those
> "types" of profiles. If the headset is put into HFP mode, then you experience
> the joy of this problem. In A2DP mode, it (mostly) works if you only want to
> listen in stereo.
>
> The root cause of the problem (at least from my debugging experience) is that if
> you are using HSP or HFP mode... and your application is talking directly to
> ALSA (like "aplay" does)... then your audio data eventually makes it's way to
> the snd_pcm_rate_commit_area() function in ALSA in 48 byte (MTU sized) "chunks".
> But, if this function receives less than a "slave_size" amount of data, it
> simply drops it by calling the snd_pcm_rewind() function.
>
> To super simplify the problem description, Bluez keeps sending 48 byte "chunks"
> of audio data, that ALSA happily ignores... nice.
>
> Just like Galaha, I'm stuck trying finding a solution. I tried his Bluez patch,
> but it doesn't work. And so far, I've not been able to get my head wrapped
> around even a "big picture" of the Bluez SCO data path to find an acceptable
> alternative. With the goal being to create a (hopefully suitable) patch to some
> component, somewhere... anywhere. Or possibly there's another solution??? Any
> help would be appreciated.
>
> It *appears* that others *may* be having some success using PulseAudio for
> this, but I prefer not to go there... just call me stubborn.
> --
You are right that I want to test the HSP/HFP profile, and A2DP works
well for me.
Thank you for your suggestions for debugging.
Maybe you don't use 8000Hz mono stream to test, so it needs to
resample the stream
to 8Khz to send. But I use a 8khz stream, the program don't go to function
snd_pcm_rate_commit_area. I trace the calling procedure like following:
aplay--->playback (aplay.c)--->pcm_write(aplay.c)--->snd_pcm_writei(pcm.c)
--->snd_pcm_ioplug_writei(pcm_ioplug.c)--->snd_pcm_write_areas(pcm.c)--->
ioplug_priv_transfer_areas(pcm_ioplug.c)--->bluetooth_hsp_write(pcm_bluetooth.c)
--->send
I think that the audio date has been sent by bluetooth, but still no sound.
Do you have any ideas?
On Sun, 24 Jan 2010 23:21:56 -0500 "Brian J. Murrell" <[email protected]>
wrote:
> On Mon, 2010-01-25 at 12:13 +0800, Chao Deng wrote:
> > Hi, Brain,
> >
> > I have the same problem like you. Do you find the root cause of it?
>
> Nope, not a clue. Unfortunately my posting here didn't get any ideas of
> why or what I should do to debug either. I kinda gave up, yet again, as
> I have done many times in the last 2-3 years of simply trying to get a
> Bluetooth headset working on Linux. Sadly it always seems like the
> answer is "next [kernel|bluez] release -- it should work great".
>
> > The kernel I used is 2.6.31, and the bluez is 4.51
>
> Seems we are in the same boat.
>
> Sorry I don't have better answers for you.
>
> b.
>
Yep. It's unfortunate that no one responded. I've spent many hours digging into
this bug, and was hoping that others my have some valid pointers/directions.
Anyway, I'm not a Bluez developer, nor do I speak fluent "Bluetooth", but
here's what I've found so far...
This is not a new bug. Galaha Shine found the crux of the problem back in 2008:
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-September/010721.html
and after firing up my debugger, this still seems to be the same issue today
(at least when I looked at the previous releases).
As you may know, headsets can have different bluetooth capabilities described
in their profiles. There's the HSP/HFP profiles for doing things like talking on
the phone, and then there's the A2DP profile for listening in stereo. And there
are others.
Brian, you don't state which profile you're using when it fails, but from
looking at your hcidump info, it appears like it's HSP or HFP because your data
packets are 48 bytes long... which is the MTU size in Bluez for HSP/HFP. When
using the A2DP profile (if supported by your headset), the data packets are
much larger.
Chao, I have 2 sets of Motorola S805's also, and it can do both of those
"types" of profiles. If the headset is put into HFP mode, then you experience
the joy of this problem. In A2DP mode, it (mostly) works if you only want to
listen in stereo.
The root cause of the problem (at least from my debugging experience) is that if
you are using HSP or HFP mode... and your application is talking directly to
ALSA (like "aplay" does)... then your audio data eventually makes it's way to
the snd_pcm_rate_commit_area() function in ALSA in 48 byte (MTU sized) "chunks".
But, if this function receives less than a "slave_size" amount of data, it
simply drops it by calling the snd_pcm_rewind() function.
To super simplify the problem description, Bluez keeps sending 48 byte "chunks"
of audio data, that ALSA happily ignores... nice.
Just like Galaha, I'm stuck trying finding a solution. I tried his Bluez patch,
but it doesn't work. And so far, I've not been able to get my head wrapped
around even a "big picture" of the Bluez SCO data path to find an acceptable
alternative. With the goal being to create a (hopefully suitable) patch to some
component, somewhere... anywhere. Or possibly there's another solution??? Any
help would be appreciated.
It *appears* that others *may* be having some success using PulseAudio for
this, but I prefer not to go there... just call me stubborn.
On Mon, 2010-01-25 at 12:13 +0800, Chao Deng wrote:
> Hi, Brain,
>
> I have the same problem like you. Do you find the root cause of it?
Nope, not a clue. Unfortunately my posting here didn't get any ideas of
why or what I should do to debug either. I kinda gave up, yet again, as
I have done many times in the last 2-3 years of simply trying to get a
Bluetooth headset working on Linux. Sadly it always seems like the
answer is "next [kernel|bluez] release -- it should work great".
> The kernel I used is 2.6.31, and the bluez is 4.51
Seems we are in the same boat.
Sorry I don't have better answers for you.
b.
Hi, Brain,
I have the same problem like you. Do you find the root cause of it?
The kernel I used is 2.6.31, and the bluez is 4.51. I use Motorola
S805 for testing.
>>Hi all,
>
>>
>>I am using bluez 4.51. After much fiddling, I seem to have my audio
>>headset doing something -- something other than reporting errors anyway.
>>
>>I can do:
>>
>>$ aplay /mnt/mp3/bad_mouth.wav -Dplug:bluetoothraw
>
>>Playing WAVE '/mnt/mp3/bad_mouth.wav' : Signed 16 bit Little Endian, Rate
>> 44100 Hz, \
>>Stereo
>
>>to the device defined as:
>
>>pcm.bluetoothraw {
>
>> type bluetooth
>> device 00:1A:45:1B:19:89
>>}
>
>>and aplay appears to be doing something and
>
>>$ hcidump -t -X -V
>
>>reports lots of:
>
> 2009-12-31 00:08:57.233899 > SCO data: handle 1 flags 0x00 dlen 48
>
>
> 0000: fd ff e6 ff af ff 4e ff 41 ff 5a ff 20 ff 53 ff ......N.A.Z. .S.
> 0010: a0 ff 6b ff 89 ff bc ff 5d ff 85 ff 3c ff d9 fe ..k.....]...<...
> 0020: 2b ff 28 ff 58 ff 53 ff 1b ff 3c ff 29 ff 49 ff +.(.X.S...<.).I.
>
>
> 2009-12-31 00:08:57.233901 > SCO data: handle 1 flags 0x00 dlen 48
> 0000: 9b ff b1 ff a2 ff 71 ff b5 ff 9f ff 52 ff fa fe ......q.....R...
> 0010: 8e fe 4e ff 98 ff ed ff 13 00 88 ff 91 ff f3 fe ..N.............
>
>
> 0020: 2f ff c2 ff 6d ff 95 ff 62 ff d2 fe ec fe 61 ff /...m...b.....a.
> 2009-12-31 00:08:57.233903 > SCO data: handle 1 flags 0x00 dlen 48
> 0000: 5e ff 2b ff 26 ff 01 ff a5 ff 9c ff 5a ff 2f ff ^.+.&.......Z./.
>
>
> 0010: 8b fe 1b ff c7 ff fa ff f0 ff 53 ff e1 fe 28 ff ..........S...(.
> 0020: b7 ff be ff 41 ff 55 ff 16 ff 3f ff de ff fa fe ....A.U...?.....
> 2009-12-31 00:08:57.233905 > SCO data: handle 1 flags 0x00 dlen 48
>
>
> 0000: 0f ff a1 ff 66 ff f6 ff 06 00 c8 ff 75 ff 16 ff ....f.......u...
> 0010: f4 fe f0 fe e5 fe d3 fe eb fe 5d ff e5 ff e9 ff ..........].....
> 0020: 84 ff 7b ff c7 ff de ff ae ff 85 ff a1 ff 58 ff ..{...........X.
>
>
> 2009-12-31 00:08:57.243898 > SCO data: handle 1 flags 0x00 dlen 48
> 0000: f0 fe 3c fe a6 fe 49 ff 3d ff c0 ff 93 ff 73 ff ..<...I.=.....s.
> 0010: 41 ff 85 ff c5 ff 67 ff 63 ff 2c ff 1a ff 23 ff A.....g.c.,...#.
>
>
> 0020: 51 ff af ff 28 ff d5 fe 50 ff 83 ff e8 ff e4 ff Q...(...P.......
> 2009-12-31 00:08:57.243901 > SCO data: handle 1 flags 0x00 dlen 48
> 0000: 01 ff 15 ff d0 fe ba fe 95 ff a2 ff b7 ff ed ff ................
>
>
> 0010: 7e ff a9 ff a1 ff e5 fe 3b ff 70 ff 63 ff 7f ff ~.......;.p.c...
> 0020: 3c ff 2b ff be fe ee fe 58 ff 7c ff 40 ff fb fe <.+.....X.|.@...
> 2009-12-31 00:08:57.243903 > SCO data: handle 1 flags 0x00 dlen 48
>
>
> 0000: 39 ff 34 ff b6 ff c1 ff 7d ff a0 ff 6a ff 79 ff 9.4.....}...j.y.
> 0010: 37 ff 0c ff 4d ff 15 ff 43 ff 66 ff 3e ff 71 ff 7...M...C.f.>.q.
> 0020: 8e ff 8c ff 06 ff d4 fe 0e ff 2e ff 8a ff 24 ff ..............$.
>
>
> 2009-12-31 00:08:57.253914 > SCO data: handle 1 flags 0x00 dlen 48
> 0000: da fe 57 ff b3 ff bf ff 7f ff 49 ff 41 ff ee fe ..W.......I.A...
> 0010: 08 ff 91 ff a2 ff 9d ff 48 ff da fe 52 ff 55 ff ........H...R.U.
>
>
> 0020: 87 ff 98 ff 25 ff 1d ff 35 ff b9 ff 83 ff b1 ff ....%...5.......
> 2009-12-31 00:08:57.253918 > SCO data: handle 1 flags 0x00 dlen 48
> 0000: 7d ff 37 ff 5e ff 40 ff 3b ff 08 ff 01 ff dc fe }.7.^.@.;.......
>
>
> 0010: 15 ff 1c ff 8b ff 8b ff 40 ff 90 ff 3a ff c6 ff ........@...:...
> 0020: 71 ff 4a ff 88 ff 3c ff bc ff 3e ff e4 fe fe fe q.J...<...>.....
> 2009-12-31 00:08:57.253920 > SCO data: handle 1 flags 0x00 dlen 48
>
>
> 0000: f9 fe 2c ff a2 ff bb ff 89 ff 65 ff 21 ff 62 ff ..,.......e.!.b.
> 0010: b9 ff b4 ff 48 ff f4 fe 42 ff 86 ff ad ff 53 ff ....H...B.....S.
> 0020: 20 ff 00 ff dd fe 71 ff 79 ff 59 ff a6 ff 8f ff .....q.y.Y.....
>
>
> 2009-12-31 00:08:57.263898 > SCO data: handle 1 flags 0x00 dlen 48
> 0000: 57 ff c2 ff a8 ff d9 fe eb fe 5a ff 89 ff 71 ff W.........Z...q.
> 0010: 1f ff 1e ff 27 ff 3f ff 3e ff 63 ff 71 ff 26 ff ....'.?.>.c.q.&.
>
>
> 0020: fd fe 03 ff 63 ff 9b ff b6 ff 91 ff 75 ff 79 ff ....c.......u.y.
> 2009-12-31 00:08:57.263901 > SCO data: handle 1 flags 0x00 dlen 48
> 0000: 29 ff 51 ff ee fe c9 fe 12 ff 85 ff a6 ff 45 ff ).Q...........E.
>
>
> 0010: 38 ff 52 ff d7 ff f7 ff 96 ff e9 fe 99 fe d5 fe 8.R.............
> 0020: 5e ff 9c ff 4d ff 1e ff c5 fe 2f ff b8 ff cf ff ^...M...../.....
> 2009-12-31 00:08:57.263903 > SCO data: handle 1 flags 0x00 dlen 48
>
>
> 0000: f1 ff b2 ff aa ff 82 ff 8a ff 5f ff 47 ff 50 ff .........._.G.P.
> 0010: 4a ff ad ff 58 ff 1a ff 43 ff 78 ff 44 ff ef fe J...X...C.x.D...
> 0020: 02 ff 05 ff 42 ff 61 ff bb ff d8 ff cd ff 01 00 ....B.a.........
>
>
> 2009-12-31 00:08:57.263905 > SCO data: handle 1 flags 0x00 dlen 48
> 0000: 28 ff e5 fe f4 fe f1 fe ad ff 33 ff f6 fe ed fe (.........3.....
> 0010: 7b fe 45 ff be ff 9c ff ac ff 2b ff 34 ff 7a ff {.E.......+.4.z.
>
>
> 0020: 3e ff af ff d3 ff 00 ff 6f ff 69 ff 26 ff 9d ff >.......o.i.&...
> 2009-12-31 00:08:57.273899 > SCO data: handle 1 flags 0x00 dlen 48
> 0000: 7d ff 8e ff 52 ff 36 ff 2a ff fe fe 63 ff d2 ff }...R.6.*...c...
>
>
> 0010: eb ff 92 ff 7a ff 36 ff 22 ff 68 ff d6 ff e0 ff ....z.6.".h.....
> 0020: 66 ff b8 fe 68 fe f0 fe 3a ff 69 ff 85 ff a5 ff f...h...:.i.....
>>............
>
>
>
BRs,
/Chao