[Bluez-devel] snd-bt-sco problem

[Bluez-devel] snd-bt-sco problem

[Chris Boyle]

Hi, I can't get snd-bt-sco (bluetooth-alsa) to work and was told this
was the best place to ask for help:

The problem is, btsco starts up successfully, the device indicates a
connection has been made, but no audio can be read or written, and after
maybe a minute the device indicates the connection has been dropped.
There is no noticeable difference on the host side at this point, i.e.
audio apps directed at the headset still just hang, and btsco is still
there. The mixer produces output from btsco, but has no effect on the
device.

Driver version: bluetooth-alsa CVS checked out 02/12/2004
Kernel: 2.6.9 debian (presence / absence of hci_usb patch seems to make
no difference)
Host bluetooth adapter: Trust BT180 USB
http://www.trust.com/home/default.htm?viewpage=service/sss/preview.htm%3Fartnr%3D13853
Headset: Logitech Mobile Bluetooth Headset
http://www.thinkgeek.com/computing/speakers/headsets/65ff/
Also tested: Nokia 6310i, various channels (this functionality works
under windows)

I'd be grateful for any hints you can give me.

Thanks,
-- 
Chris Boyle - http://cmb.is-a-geek.org/
GPG: B7D86E0F, MSN: shortcipher@hotmail.com, ICQ: 24151961,
AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on irc.uwcs.co.uk


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Re: snd-bt-sco problem

[Sebastian Roth]

Hi Chris,

I'm new to this bluetooth things so please don't mind if my suggestions 
are not completely correct.

I've had some problems with my bluetooth headsets too.
The first problem was the dongle. I've used an usb-dongle from Anycom 
(Transilica chip). Exchanging the dongle with a D-Link DBT-120 
(Cambridge Silicon Radio chip) helped me because this chip routes the 
SCO data over HCI.
Please post the ouput of `hciconfig hci0 revision'

The second issue was that all "sound-apps" were blocking (hanging) 
without playing any sound. My headsets (both from Anycom) must be 
activated with the switch to recieve the sound. Just like answer the 
telephone.

Everone, please feel free to correct me if I'm wrong!

Best regards,
Sebastian



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] snd-bt-sco problem

[Marcel Holtmann]

Hi Chris,

> I can't get snd-bt-sco (bluetooth-alsa) to work and was told this
> was the best place to ask for help:
> 
> The problem is, btsco starts up successfully, the device indicates a
> connection has been made, but no audio can be read or written, and after
> maybe a minute the device indicates the connection has been dropped.
> There is no noticeable difference on the host side at this point, i.e.
> audio apps directed at the headset still just hang, and btsco is still
> there. The mixer produces output from btsco, but has no effect on the
> device.
> 
> Driver version: bluetooth-alsa CVS checked out 02/12/2004
> Kernel: 2.6.9 debian (presence / absence of hci_usb patch seems to make
> no difference)

why don't you try 2.6.9-mh5 or 2.6.10-rc3 ?

> Host bluetooth adapter: Trust BT180 USB
> http://www.trust.com/home/default.htm?viewpage=service/sss/preview.htm%3Fartnr%3D13853
> Headset: Logitech Mobile Bluetooth Headset
> http://www.thinkgeek.com/computing/speakers/headsets/65ff/
> Also tested: Nokia 6310i, various channels (this functionality works
> under windows)

what is the output of "hciconfig -a" and "hcitool info ..." for these
devices. And include "/proc/bus/usb/devices".

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: snd-bt-sco problem

[Marcel Holtmann]

Hi Sebastian,

> The first problem was the dongle. I've used an usb-dongle from Anycom 
> (Transilica chip).

what does "/proc/bus/usb/device" show for the Anycom dongle?

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Problems with anycom usb dongle (was: snd-bt-sco problem)

[Sebastian Roth]

Hi Marcel,


> what does "/proc/bus/usb/device" show for the Anycom dongle?

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  4 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=16 #Cfgs=  1
P:  Vendor=0f4d ProdID=1000 Rev= 4.01
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 26mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
E:  Ad=84(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=05(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
E:  Ad=84(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=05(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
E:  Ad=84(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=05(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
E:  Ad=84(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=05(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
E:  Ad=84(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=05(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
E:  Ad=84(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=05(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms


With the anycom dongle I can see SCO data using hcidump but no sound
is playing. When btsco is stopped it seems to me the connection isn't
really closed.
hcidump:
...
 > SCO data: handle 0x0000 dlen 0
 > SCO data: handle 0x0000 dlen 0
...

syslog:
...
kernel: cket: hci0 SCO packet for unknown connection handle 0
kernel: hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
last message repeated 229 times
...

I have to stop hcid shutdown hic0 and unload all the modules to stop it
flooding my syslog!

Best regards,
Sebastian



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Problems with anycom usb dongle (was: snd-bt-sco problem)

[Marcel Holtmann]

Hi Sebastian,

> > what does "/proc/bus/usb/device" show for the Anycom dongle?
> 
> T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  4 Spd=12  MxCh= 0
> D:  Ver= 1.10 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=16 #Cfgs=  1
> P:  Vendor=0f4d ProdID=1000 Rev= 4.01
> C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 26mA
> I:  If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
> E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
> E:  Ad=82(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
> E:  Ad=03(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
> I:  If#= 1 Alt= 0 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
> E:  Ad=84(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> E:  Ad=05(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> I:  If#= 1 Alt= 1 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
> E:  Ad=84(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> E:  Ad=05(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> I:  If#= 1 Alt= 2 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
> E:  Ad=84(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> E:  Ad=05(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> I:  If#= 1 Alt= 3 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
> E:  Ad=84(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> E:  Ad=05(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> I:  If#= 1 Alt= 4 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
> E:  Ad=84(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> E:  Ad=05(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> I:  If#= 1 Alt= 5 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=hci_usb
> E:  Ad=84(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
> E:  Ad=05(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

at least it has the ISOC endpoints.

> With the anycom dongle I can see SCO data using hcidump but no sound
> is playing. When btsco is stopped it seems to me the connection isn't
> really closed.
> hcidump:
> ...
>  > SCO data: handle 0x0000 dlen 0
>  > SCO data: handle 0x0000 dlen 0
> ...
> 
> syslog:
> ...
> kernel: cket: hci0 SCO packet for unknown connection handle 0
> kernel: hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
> last message repeated 229 times
> ...

The dongle keeps sending SCO packet, but the kernel already terminated
the SCO connection. However I am not sure if connection handle 0 is a
valid handle. What does "hcitool con" show when both (ACL + SCO) links
were open?

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Re: Problems with anycom usb dongle

[Sebastian Roth]

Hi Marcel,

sorry for this long post here!

 > The dongle keeps sending SCO packet, but the kernel already terminated
 > the SCO connection.
I figured out that `hciconfig hci0 down' stops the flood. No `up' is
possible afterwards. I have to replug the dongle.


 > What does "hcitool con" show when both (ACL + SCO) links were open?

(btsco's last line is RFCOMM channel 1 connected)
# hcitool con
Connections:
         < ACL 00:08:1B:00:FF:33 handle 1 state 1 lm MASTER

(pressing the button at my headset starts the SCO stream)
# hcitool con
Connections:
         < SCO 00:08:1B:00:FF:33 handle 1025 state 1 lm SLAVE
         < ACL 00:08:1B:00:FF:33 handle 1 state 1 lm MASTER



I've tested the anycom dongle with both headsets once again.
Here is a (heavy striped) output of hcidump while testing one of those:

< HCI Command: Create Connection (0x01|0x0005) plen 13
   0000: 33 ff 00 1b 08 00 18 cc  02 00 00 00 01
... (normal connect)
 > HCI Event: Connect Complete (0x03) plen 11
   0000: 00 01 04 33 ff 00 1b 08  00 00 01
 > SCO data: handle 0x0000 dlen 0
... (a lot of those packets)
 > SCO data: handle 0x0000 dlen 0
(I guess, here was my first button press)
 > SCO data: handle 0x0401 dlen 48
     0000: 58 00 60 ff f0 ff a0 ff  7c ff 98 ff d8 00 38 00
     0010: 68 00 48 ff d0 ff 6c ff  5c ff a8 ff f0 00 50 00
     0020: 70 00 38 ff c8 ff 7c ff  88 ff c0 00 20 00 70 00
... (a lot of those packets)
 > SCO data: handle 0x0401 dlen 48
     0000: f0 ff f0 ff f8 ff f8 ff  f0 ff f0 ff f0 ff f8 ff
     0010: f8 ff f8 ff f0 ff f0 ff  f8 ff f8 ff f8 ff f0 ff
     0020: f0 ff f8 ff f8 ff f8 ff  f0 ff f0 ff f8 ff f8 ff
(the second button press)
 > ACL data: handle 0x0001 flags 0x01 dlen 4
     L2CAP(d): cid 0x0041 len 17 [psm 3]
       RFCOMM(d): UIH: cr 0 dlci 2 pf 1 ilen 12 fcs 0x5c credits 1
       0000: 41 54 2b 43 4b 50 44 3d  32 30 30 0d
**
< ACL data: handle 0x0001 flags 0x02 dlen 14
     L2CAP(d): cid 0x01c3 len 10 [psm 3]
       RFCOMM(d): UIH: cr 1 dlci 2 pf 0 ilen 6 fcs 0x9a
       0000: 0d 0a 4f 4b 0d 0a
**
 > HCI Event: Number of Completed Packets (0x13) plen 5
   0000: 01 01 00 01 00
< HCI Command: Disconnect (0x01|0x0006) plen 3
   0000: 01 04 13
**
 > HCI Event: Command Status (0x0f) plen 4
   0000: 00 01 06 04
**
 > HCI Event: Disconn Complete (0x05) plen 4
   0000: 00 01 04 13
 > HCI Event: Max Slots Change (0x1b) plen 3
   0000: 01 00 05
 > SCO data: handle 0x0000 dlen 0
 > SCO data: handle 0x0000 dlen 0
... flood ;)

** means between the HCI and ACL packets there was some SCO data
with a useful handle (> SCO data: handle 0x0401 dlen 48)

The SCO data between the two button presses seems ok, I think.
Nevertheless I can't hear any sound when trying to play.


Best regards,
Sebastian



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Problems with anycom usb dongle

[Marcel Holtmann]

Hi Sebastian,

>  > What does "hcitool con" show when both (ACL + SCO) links were open?
> 
> (btsco's last line is RFCOMM channel 1 connected)
> # hcitool con
> Connections:
>          < ACL 00:08:1B:00:FF:33 handle 1 state 1 lm MASTER
> 
> (pressing the button at my headset starts the SCO stream)
> # hcitool con
> Connections:
>          < SCO 00:08:1B:00:FF:33 handle 1025 state 1 lm SLAVE
>          < ACL 00:08:1B:00:FF:33 handle 1 state 1 lm MASTER

using handle 1025 is weird. I've never seen this before.

> I've tested the anycom dongle with both headsets once again.
> Here is a (heavy striped) output of hcidump while testing one of those:
> 
> < HCI Command: Create Connection (0x01|0x0005) plen 13
>    0000: 33 ff 00 1b 08 00 18 cc  02 00 00 00 01
> ... (normal connect)

There must be "SCO add" in between.

>  > HCI Event: Connect Complete (0x03) plen 11
>    0000: 00 01 04 33 ff 00 1b 08  00 00 01

This is handle 1025 after the "SCO add" and this is fine.

>  > SCO data: handle 0x0000 dlen 0
> ... (a lot of those packets)
>  > SCO data: handle 0x0000 dlen 0

And this is broken hardware. You can't send something for handle 0 with
zero data if no connection handle is available.

> (I guess, here was my first button press)
>  > SCO data: handle 0x0401 dlen 48
>      0000: 58 00 60 ff f0 ff a0 ff  7c ff 98 ff d8 00 38 00
>      0010: 68 00 48 ff d0 ff 6c ff  5c ff a8 ff f0 00 50 00
>      0020: 70 00 38 ff c8 ff 7c ff  88 ff c0 00 20 00 70 00
> ... (a lot of those packets)
>  > SCO data: handle 0x0401 dlen 48
>      0000: f0 ff f0 ff f8 ff f8 ff  f0 ff f0 ff f0 ff f8 ff
>      0010: f8 ff f8 ff f0 ff f0 ff  f8 ff f8 ff f8 ff f0 ff
>      0020: f0 ff f8 ff f8 ff f8 ff  f0 ff f0 ff f8 ff f8 ff
> (the second button press)
>  > ACL data: handle 0x0001 flags 0x01 dlen 4
>      L2CAP(d): cid 0x0041 len 17 [psm 3]
>        RFCOMM(d): UIH: cr 0 dlci 2 pf 1 ilen 12 fcs 0x5c credits 1
>        0000: 41 54 2b 43 4b 50 44 3d  32 30 30 0d
> **
> < ACL data: handle 0x0001 flags 0x02 dlen 14
>      L2CAP(d): cid 0x01c3 len 10 [psm 3]
>        RFCOMM(d): UIH: cr 1 dlci 2 pf 0 ilen 6 fcs 0x9a
>        0000: 0d 0a 4f 4b 0d 0a
> **
>  > HCI Event: Number of Completed Packets (0x13) plen 5
>    0000: 01 01 00 01 00
> < HCI Command: Disconnect (0x01|0x0006) plen 3
>    0000: 01 04 13
> **
>  > HCI Event: Command Status (0x0f) plen 4
>    0000: 00 01 06 04
> **
>  > HCI Event: Disconn Complete (0x05) plen 4
>    0000: 00 01 04 13
>  > HCI Event: Max Slots Change (0x1b) plen 3
>    0000: 01 00 05
>  > SCO data: handle 0x0000 dlen 0
>  > SCO data: handle 0x0000 dlen 0
> ... flood ;)

The SCO part of this dongle seem totally broken. Should I mark it as
broken in hci_usb driver? Or should I simply drop SCO packets with no
data on handle 0 in the HCI core? Is handle 0 a valid handle?

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Re: Problems with anycom usb dongle

[Sebastian Roth]

Hi Marcel,

as I mentioned in my first post I'm new to blueooth. So I think I'm not
the one who can really answer your questions but let's give it a try.

 > Should I mark it as broken in hci_usb driver?
The dongle seems broken but IMO it's better to have an acknowledgment
of someone else who have tested it.

 > Or should I simply drop SCO packets with no data on handle 0 in the
 > HCI core? Is handle 0 a valid handle?
 From my bluetooth spec, page 226 (bluetooth_1_1_vol1)
"The SCO handle zero is never used."



 > There must be "SCO add" in between.
Yes you are right!

(this should be the first button press AT+CKPD=200)
 > ACL data: handle 0x0001 flags 0x02 dlen 17
 > ACL data: handle 0x0001 flags 0x01 dlen 3
     L2CAP(d): cid 0x0041 len 16 [psm 3]
       RFCOMM(d): UIH: cr 0 dlci 2 pf 0 ilen 12 fcs 0x40
       0000: 41 54 2b 43 4b 50 44 3d  32 30 30 0d              AT+CKPD=200.
< ACL data: handle 0x0001 flags 0x02 dlen 14
     L2CAP(d): cid 0x01c3 len 10 [psm 3]
       RFCOMM(d): UIH: cr 1 dlci 2 pf 0 ilen 6 fcs 0x9a
       0000: 0d 0a 4f 4b 0d 0a                                 ..OK..
< HCI Command: Add SCO Connection (0x01|0x0007) plen 4
   0000: 01 00 e0 00                                       ....
 > HCI Event: Command Status (0x0f) plen 4
   0000: 00 01 07 04                                       ....
 > HCI Event: Number of Completed Packets (0x13) plen 5
   0000: 01 01 00 01 00                                    .....
 > HCI Event: Connect Complete (0x03) plen 11
   0000: 00 01 04 33 ff 00 1b 08  00 00 01                 ...3.......
 > SCO data: handle 0x0000 dlen 0
... (a lot of those packets)
 > SCO data: handle 0x0000 dlen 0
 > SCO data: handle 0x0401 dlen 48
     0000: 58 00 60 ff f0 ff a0 ff  7c ff 98 ff d8 00 38 00
     0010: 68 00 48 ff d0 ff 6c ff  5c ff a8 ff f0 00 50 00
     0020: 70 00 38 ff c8 ff 7c ff  88 ff c0 00 20 00 70 00

I was wrong.
The first button press was _before_ the SCO data with handle 0!


Best regards,
Sebastian



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Problems with anycom usb dongle

[Marcel Holtmann]

Hi Sebastian,

>  > Should I mark it as broken in hci_usb driver?
> The dongle seems broken but IMO it's better to have an acknowledgment
> of someone else who have tested it.

I have no problem to mark buggy hardware as broken.

>  > Or should I simply drop SCO packets with no data on handle 0 in the
>  > HCI core? Is handle 0 a valid handle?
>  From my bluetooth spec, page 226 (bluetooth_1_1_vol1)
> "The SCO handle zero is never used."

As far as I know this speaks about the LMP handle and this is different
from the HCI handle.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] snd-bt-sco problem

[Brad Midgley]

Chris,

Did it start working when you clicked the 'connect' button on the 
headset? Sebastian pointed out that this was something one might miss so 
I highlighted it recently in the docs.

Brad

Chris Boyle wrote:
> Hi, I can't get snd-bt-sco (bluetooth-alsa) to work and was told this
> was the best place to ask for help:
> 
> The problem is, btsco starts up successfully, the device indicates a
> connection has been made, but no audio can be read or written, and after
> maybe a minute the device indicates the connection has been dropped.
> There is no noticeable difference on the host side at this point, i.e.
> audio apps directed at the headset still just hang, and btsco is still
> there. The mixer produces output from btsco, but has no effect on the
> device.
> 
> Driver version: bluetooth-alsa CVS checked out 02/12/2004
> Kernel: 2.6.9 debian (presence / absence of hci_usb patch seems to make
> no difference)
> Host bluetooth adapter: Trust BT180 USB
> http://www.trust.com/home/default.htm?viewpage=service/sss/preview.htm%3Fartnr%3D13853
> Headset: Logitech Mobile Bluetooth Headset
> http://www.thinkgeek.com/computing/speakers/headsets/65ff/
> Also tested: Nokia 6310i, various channels (this functionality works
> under windows)
> 
> I'd be grateful for any hints you can give me.
> 
> Thanks,


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Re: Problems with anycom usb dongle

[Sebastian Roth]

Hi Marcel,

the point about link manager isn't really clear to me.
In the spec on page 572 about HCI - Add_SCO_Connection the description
starts with this phrase "This command will cause the link manager to
create a SCO connection ...". Does this mean LMP?
I've scaned the spec and search the internet but can't find an explicit
answer. Do LMP and L2CAP work "hand-in-hand" or are they alternative?
If they are cooperating the mentioned part (page 226) does matter I
think.

> > > Or should I simply drop SCO packets with no data on handle 0 in the
> > > HCI core? Is handle 0 a valid handle?
 > >
> > From my bluetooth spec, page 226 (bluetooth_1_1_vol1)
> > "The SCO handle zero is never used."
> 
> As far as I know this speaks about the LMP handle and this is different
> from the HCI handle.
> 

Best regards,
Sebastian



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Problems with anycom usb dongle

[Marcel Holtmann]

Hi Sebastian,

> the point about link manager isn't really clear to me.
> In the spec on page 572 about HCI - Add_SCO_Connection the description
> starts with this phrase "This command will cause the link manager to
> create a SCO connection ...". Does this mean LMP?
> I've scaned the spec and search the internet but can't find an explicit
> answer. Do LMP and L2CAP work "hand-in-hand" or are they alternative?
> If they are cooperating the mentioned part (page 226) does matter I
> think.

the link manager runs on the chip and L2CAP is part of the host protocol
stack. And in between we have the HCI. As far as I know, the connection
handle from the link manager must not be the same connection handle used
on the HCI. Feel free to correct me, because I never really looked under
the HCI layer in that detail.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] CVS doubles

[suche.org]

Hi,

since i wan't to test sdptool with HF (Handsfree) i found some ugly points.
1. On the webside there is no more link to bluez-sdp
2. In CVS bluez/dsp contain sdptool AND bluez/utils contain sdptoll
but bluez/utils depends on bluez/dsp for (libdsp)

Cu Thomas


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] CVS doubles

[Marcel Holtmann]

Hi Thomas,

> since i wan't to test sdptool with HF (Handsfree) i found some ugly points.
> 1. On the webside there is no more link to bluez-sdp
> 2. In CVS bluez/dsp contain sdptool AND bluez/utils contain sdptoll
> but bluez/utils depends on bluez/dsp for (libdsp)

the bluez-pan and bluez-sdp packages were deprecated a long time ago and
I will delete the CVS repositories once I checked that we don't any code
from them anymore. Use bluez-libs and bluez-utils. Everything you need
is in there.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] snd-bt-sco problem

[Chris Boyle]

On Tue, Dec 07, 2004 at 08:57:23AM +0100, Marcel Holtmann wrote:
> why don't you try 2.6.9-mh5 or 2.6.10-rc3 ?

I might do that later, this machine is used for quite a lot of different
things...

> > Host bluetooth adapter: Trust BT180 USB
> > http://www.trust.com/home/default.htm?viewpage=service/sss/preview.htm%3Fartnr%3D13853
> > Headset: Logitech Mobile Bluetooth Headset
> > http://www.thinkgeek.com/computing/speakers/headsets/65ff/
> > Also tested: Nokia 6310i, various channels (this functionality works
> > under windows)
> 
> what is the output of "hciconfig -a" and "hcitool info ..." for these
> devices. And include "/proc/bus/usb/devices".

zeus:~# hciconfig -a 
hci0:	Type: USB
	BD Address: 00:0B:0D:40:6C:63 ACL MTU: 120:20  SCO MTU: 64:0
	UP RUNNING PSCAN ISCAN 
	RX bytes:7475162 acl:256 sco:276593 events:309 errors:0
	TX bytes:4578 acl:216 sco:0 commands:48 errors:0
	Features: 0xff 0xff 0x05 0x00 0x00 0x00 0x00 0x00
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: RSWITCH HOLD SNIFF PARK 
	Link mode: SLAVE ACCEPT 
	Name: 'zeus'
	Class: 0x000100
	Service Classes: Unspecified
	Device Class: Computer, Uncategorized
	HCI Ver: 1.1 (0x1) HCI Rev: 0x0 LMP Ver: 1.1 (0x1) LMP Subver: 0x757
	Manufacturer: Silicon Wave (11)

zeus:~# hcitool info 00:0D:44:00:36:41  # headset
Requesting information ...
	BD Address:  00:0D:44:00:36:41
	Device Name: Logitech HS01
	LMP Version: 1.1 (0x1) LMP Subversion: 0x32b
	Manufacturer: Cambridge Silicon Radio (10)
	Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
		<3-slot packets> <5-slot packets> <encryption> <slot offset> 
		<timing accuracy> <role switch> <hold mode> <sniff mode> 
		<park state> <RSSI> <channel quality> <SCO link> <HV2 packets> 
		<HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme> 
		<power control> <transparent SCO> 

zeus:~# hcitool info 00:02:EE:65:EB:27  # phone
Requesting information ...
	BD Address:  00:02:EE:65:EB:27
	Device Name: cmb's phone
	LMP Version: 1.1 (0x1) LMP Subversion: 0x226
	Manufacturer: Nokia Mobile Phones (1)
	Features: 0xbf 0x28 0x21 0x00 0x00 0x00 0x00 0x00
		<3-slot packets> <5-slot packets> <encryption> <slot offset> 
		<timing accuracy> <role switch> <sniff mode> <SCO link> 
		<HV3 packets> <CVSD> 

zeus:~# cat /proc/bus/usb/devices 

T:  Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc= 25/900 us ( 3%), #Int=  1, #Iso=  2
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.9 uhci_hcd
S:  Product=VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2)
S:  SerialNumber=0000:01:07.1
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

[snip FM radio]

T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  5 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0c10 ProdID=0000 Rev=15.00
S:  Manufacturer=SiW
S:  Product=SiW
S:  SerialNumber=636C400D0B00
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 50mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

T:  Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.9 uhci_hcd
S:  Product=VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
S:  SerialNumber=0000:01:07.0
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 4
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.9 ehci_hcd
S:  Product=VIA Technologies, Inc. USB 2.0
S:  SerialNumber=0000:01:07.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 6
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.9 ehci_hcd
S:  Product=nVidia Corporation nForce2 USB Controller
S:  SerialNumber=0000:00:02.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

[snip memory card reader]

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 3
B:  Alloc= 29/900 us ( 3%), #Int=  3, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.9 ohci_hcd
S:  Product=nVidia Corporation nForce2 USB Controller (#2)
S:  SerialNumber=0000:00:02.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

[snip keyboard & mouse]

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 3
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.9 ohci_hcd
S:  Product=nVidia Corporation nForce2 USB Controller
S:  SerialNumber=0000:00:02.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

[snip joystick & webcam]

-- 
Chris Boyle - http://cmb.is-a-geek.org/
GPG: B7D86E0F, MSN: shortcipher@hotmail.com, ICQ: 24151961,
AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on irc.uwcs.co.uk


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] snd-bt-sco problem

[Chris Boyle]

On Tue, Dec 07, 2004 at 08:10:33PM -0700, Brad Midgley wrote:
> Did it start working when you clicked the 'connect' button on the 
> headset? Sebastian pointed out that this was something one might miss so 
> I highlighted it recently in the docs.

Almost, but not quite. btsco looked more successful, and with hcidump I
could see a lot of SCO data flowing, but still audio apps would hang. I
could however press the volume buttons on the headset and see the mixer
change, so there was definitely a connection.

-- 
Chris Boyle - http://cmb.is-a-geek.org/
GPG: B7D86E0F, MSN: shortcipher@hotmail.com, ICQ: 24151961,
AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on irc.uwcs.co.uk


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] CVS doubles

[suche.org]

>the bluez-pan and bluez-sdp packages were deprecated a long time ago and
>I will delete the CVS repositories once I checked that we don't any code
>from them anymore. Use bluez-libs and bluez-utils. Everything you need
>is in there.
>  
>
Hi,
ok i done an error with libdsp installed i run configure and before 
running make i delete the old.
And so he seek for it. Maybe bluez-utils should remove the check for 
libsdp ? Becasue as you say
it in compleate in libbluez now.

Cu Thomas


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: snd-bt-sco problem

[Chris Boyle]

On Tue, Dec 07, 2004 at 08:37:56AM +0100, Sebastian Roth wrote:
> Please post the ouput of `hciconfig hci0 revision'

zeus:~# hciconfig hci0 revision
hci0:	Type: USB
	BD Address: 00:0B:0D:40:6C:63 ACL MTU: 120:20  SCO MTU: 64:0
	Unsupported manufacturer

> The second issue was that all "sound-apps" were blocking (hanging) 
> without playing any sound. My headsets (both from Anycom) must be 
> activated with the switch to recieve the sound. Just like answer the 
> telephone.

As mentioned in reply to Brad Midgley, this established a successful
connection (pressing the volume buttons affected alsamixer), but I
still couldn't actually get any audio to flow in either direction,
despite continuous SCO data packets seen with hcidump, although only in
one direction.

"> SCO data: handle 0x0100 dlen 24"

-- 
Chris Boyle - http://cmb.is-a-geek.org/
GPG: B7D86E0F, MSN: shortcipher@hotmail.com, ICQ: 24151961,
AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on irc.uwcs.co.uk


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Re[2]: snd-bt-sco problem

[suche.org]

>As mentioned in reply to Brad Midgley, this established a successful
>connection (pressing the volume buttons affected alsamixer), but I
>still couldn't actually get any audio to flow in either direction,
>despite continuous SCO data packets seen with hcidump, although only in
>one direction.
>  
>
Hi,
i had the same problem in the first.
Possible options:
a) Other soundcards
b) Insufficent rights on /dev/dsp*  /dev/audio* /dev/sound* or /dev/snd/*

Cu Thomas


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] CVS doubles

[Marcel Holtmann]

Hi Thomas,

> ok i done an error with libdsp installed i run configure and before 
> running make i delete the old.
> And so he seek for it. Maybe bluez-utils should remove the check for 
> libsdp ? Becasue as you say
> it in compleate in libbluez now.

the check will go away once I finished bluez.m4, but for now the check
must to show people how to deal with it if they don't need special
features from newer Bluetooth library versions.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Problems with anycom usb dongle

[Steven Singer]

Marcel Holtmann wrote:
> Sebastian wrote:
>>                         "This command will cause the link manager to
>> create a SCO connection ...". Does this mean LMP?

The Link Manager or LM is the entity - the code that performs the tasks.
Two link managers communicate with each other over the air using the
Link Manager Protocol or LMP.

Strictly speaking the P in L2CAP means protocol so really you should
talk about the L2CA layer but no one ever does.

> the link manager runs on the chip and L2CAP is part of the host protocol
> stack. And in between we have the HCI.

Or, if you prefer, L2CAP issues the commands, the LM processes the
commands.

The host talks to the link manager on the local device using HCI.
The local link manager talks to the remote link manager using LMP.

>                                        As far as I know, the connection
> handle from the link manager must not be the same connection handle used

I think you mean 'need not' not 'must not'.

> on the HCI. Feel free to correct me, because I never really looked under
> the HCI layer in that detail.

Correct. The LMP SCO handle is an 8 bit number in the range 1 to 255.
The HCI SCO handle is a 12 bit number in the range 0 to 0x0eff.

LMP SCO handles are unique per piconet and are assigned by the master.
If a device is a participant in multiple piconets then it may see the
same LMP handle on different networks. The LM must distinguish SCO
links using the (piconet, handle) pair.

HCI SCO handles are unique per host<->controller link. However, the
same HCI SCO handle may be being used by different devices in a
piconet to refer to different SCO links.

The LMP SCO handle is shared between the two devices in a SCO link
(this allows the devices to distinguish multiple SCO links so that they
agree on which link is to disconnect, for example).

The HCI SCO handles are not shared between the two devices. The two
hosts may see different handles.

	- Steven



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Re: Problems with anycom usb dongle

[Sebastian Roth]

Hi Marcel,

 > the link manager runs on the chip and L2CAP is part of the host protocol
 > stack. And in between we have the HCI. As far as I know, the connection
 > handle from the link manager must not be the same connection handle used
 > on the HCI. Feel free to correct me, because I never really looked under
 > the HCI layer in that detail.

I've had a closer look at this but can't find out anything more detailed
about the differences of the handles.

 > Or should I simply drop SCO packets with no data on handle 0 in the
 > HCI core? Is handle 0 a valid handle?
So I can't give you an answer to this. Sorry.

Best regards,
Sebastian



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Problems with anycom usb dongle

[Marcel Holtmann]

Hi Steven,

> >                                        As far as I know, the connection
> > handle from the link manager must not be the same connection handle used
> 
> I think you mean 'need not' not 'must not'.

oh yes, right. Germans (especially I) tend to translate this wrong :)

> > on the HCI. Feel free to correct me, because I never really looked under
> > the HCI layer in that detail.
> 
> Correct. The LMP SCO handle is an 8 bit number in the range 1 to 255.
> The HCI SCO handle is a 12 bit number in the range 0 to 0x0eff.
> 
> LMP SCO handles are unique per piconet and are assigned by the master.
> If a device is a participant in multiple piconets then it may see the
> same LMP handle on different networks. The LM must distinguish SCO
> links using the (piconet, handle) pair.
> 
> HCI SCO handles are unique per host<->controller link. However, the
> same HCI SCO handle may be being used by different devices in a
> piconet to refer to different SCO links.
> 
> The LMP SCO handle is shared between the two devices in a SCO link
> (this allows the devices to distinguish multiple SCO links so that they
> agree on which link is to disconnect, for example).
> 
> The HCI SCO handles are not shared between the two devices. The two
> hosts may see different handles.

And there can't be a SCO and an ACL link with the same handle, right?

However the problems is that we see a SCO data packet with HCI handle 0
and zero data len, which should not be send up to the HCI. Basically I
think we must drop this directly in hci_usb driver and not even send it
up to BlueZ HCI core. Actually I tend to simply mark the SCO support of
this dongle broken.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Problems with anycom usb dongle

[Steven Singer]

Marcel Holtmann wrote:
>> >                                        As far as I know, the connection
>> > handle from the link manager must not be the same connection handle used
>> 
>> I think you mean 'need not' not 'must not'.
> 
> oh yes, right. Germans (especially I) tend to translate this wrong :)

I can see why this could be a problem. If "must" means "is required to
be" then it has two opposites "is required not to be" and "is not required
to be". That is, does the negation bind to "required" or to "to be".

You can't easily get to "is not required to be" using must. You end up
writing something horribly long like "it is not the case that A must be
B".

You could have said "doesn't need to be", but "need not be" is
idiomatic.

Anyway, back to the matter at hand:

> And there can't be a SCO and an ACL link with the same handle, right?

Correct. I don't know if the HCI spec explicitly states this, but it is
implicit. For example, the Disconnect command takes a connection handle
as an argument. If SCO and ACL links were able to have the same handle
then it would be ambiguous which was to be disconnected.

> However the problems is that we see a SCO data packet with HCI handle 0
> and zero data len, which should not be send up to the HCI. Basically I
> think we must drop this directly in hci_usb driver and not even send it
> up to BlueZ HCI core.

It would be valid for the dongle to create a link with HCI SCO handle 0,
but, if I read the traces correctly, it hasn't done this. So the problem
is that it's sending SCO packets for a non-existent handle.

It may just be a feature of this dongle that if the isochronous endpoint
is started up and there's no SCO data to send (or if it hasn't quite
finished setting up the SCO link internally) then it sends a dummy HCI
SCO header.

If the zero length packets are ignored then does the rest of the data
make sense. If so, silently dropping zero length packets might be
useful.

>                       Actually I tend to simply mark the SCO support of
> this dongle broken.

I think you mean "intend" not "tend". :-)

	- Steven



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Problems with anycom usb dongle

[Marcel Holtmann]

Hi Steven,

> >> I think you mean 'need not' not 'must not'.
> > 
> > oh yes, right. Germans (especially I) tend to translate this wrong :)
> 
> I can see why this could be a problem. If "must" means "is required to
> be" then it has two opposites "is required not to be" and "is not required
> to be". That is, does the negation bind to "required" or to "to be".
> 
> You can't easily get to "is not required to be" using must. You end up
> writing something horribly long like "it is not the case that A must be
> B".
> 
> You could have said "doesn't need to be", but "need not be" is
> idiomatic.

I know, I know. It is stupid, but happens sometimes. I am not a native
speaker and from time to time I translate a little bit to literally.

> > And there can't be a SCO and an ACL link with the same handle, right?
> 
> Correct. I don't know if the HCI spec explicitly states this, but it is
> implicit. For example, the Disconnect command takes a connection handle
> as an argument. If SCO and ACL links were able to have the same handle
> then it would be ambiguous which was to be disconnected.

Thanks for clarification.

> > However the problems is that we see a SCO data packet with HCI handle 0
> > and zero data len, which should not be send up to the HCI. Basically I
> > think we must drop this directly in hci_usb driver and not even send it
> > up to BlueZ HCI core.
> 
> It would be valid for the dongle to create a link with HCI SCO handle 0,
> but, if I read the traces correctly, it hasn't done this. So the problem
> is that it's sending SCO packets for a non-existent handle.

Yes and the BlueZ HCI core complains about it.

> It may just be a feature of this dongle that if the isochronous endpoint
> is started up and there's no SCO data to send (or if it hasn't quite
> finished setting up the SCO link internally) then it sends a dummy HCI
> SCO header.
> 
> If the zero length packets are ignored then does the rest of the data
> make sense. If so, silently dropping zero length packets might be
> useful.

Is there anything written about the minimum size of a SCO data packet,
because dropping every zero length SCO packet is quite simply. And it is
also simple to do this only for a specific dongle inside the hci_usb
without touching the BlueZ HCI core.

> >                       Actually I tend to simply mark the SCO support of
> > this dongle broken.
> 
> I think you mean "intend" not "tend". :-)

This becomes an English class ;) Actually one translation of "tend" is
"tendieren" and this is what I meant. However "intend" is also fine.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: snd-bt-sco problem

[Lars Grunewaldt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Boyle wrote:
| On Tue, Dec 07, 2004 at 08:37:56AM +0100, Sebastian Roth wrote:

| As mentioned in reply to Brad Midgley, this established a successful
| connection (pressing the volume buttons affected alsamixer), but I
| still couldn't actually get any audio to flow in either direction,
| despite continuous SCO data packets seen with hcidump, although only in
| one direction.

I just wanted to point out that the volume control messages are sent
over the HCI channel, while audio data is send over the SCO channel.
It's likely that if there's a problem with the SCO data transfer, the
volume buttons will still work.

With my headset, I can hear the volume increasing because the noise gets
loader.

You could also try the "loopback" mode; just don't use any audio
software, but activate the loopback i.e. in alsamixer by unmuting and
then press the headset button to connect.

Audio should than be routed back to the headset so you can "hear
yourself". Makes it easier to determine whether there's a bluez/sco
problem or something with your audio setup :)

good luck,
~  Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBtxE6QWC6DTWkDAoRAqVIAKC+2cyao0HoZPqBoK1rbwO6JbIHWwCgtEBN
lLLFf5eU+dU34SiO3lwc17g=
=G1e+
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel