Re: [Bluez-devel] Re: multi rfcomm/sco connection

[Marcel Holtmann <marcel@holtmann.org>]

Hi Suriyan,

> I just found the way to work with three headsets over only one
> Bluetooth dongle by a few hardcoded to BlueZ:-
> 
> 1. force alternate setting of USB interface number 1, isochronous
>     endpoint to 5 (3 voice channels with 16 bit encoding)
> 
> when three SCO channels connected (by run three hsplay consecutively)
> I found each incoming SCO HCI frame size up to 144 bytes (as I known
> previously one voice channel with 16-bit encoding SCO HCI frame size
> equals 48 bytes so that three channels 48 * 3 = 144 bytes)
> 
> This mean one HCI frame to transmit/receive for each SCO channel
> over USB isochronous endpoint when three SCO channels were
> connected have frame size equals 144 bytes + 3 bytes header
> (handle and size) but I not sure this is CSR specific since Bluetooth
> HCI USB transport specification (H:2) have not details in this point,
> define only suggested Max Packet Size of each USB frame for transport
> SCO HCI frame.

looks reasonable to me, but I've neever done this before.

> This cause I must do the second step,
> 
> 2. bypass checking (skb->len > hdev->sco_mtu) in function
>     hci_send_sco(...) [hci_core.c] and (len > conn->mtu) in
>     function sco_send_frame(...) [sco.c]
>     *** I just think, this step maybe change by hciconfig tool. ***

This is wrong. If the MTU increases with a different voice setting then
you have to change the check to depend on the voice setting value.

> Next step, I would like to fixed to dynamicaly change the alternate setting
> by looking for previous thread "question about hci_usb endpoint
> selection..." as you known in notify() cannot call usb_set_interface()
> since always in_interrupt() so that I would like to purpose to add ioctl()
> into hci_usb driver to do this or do you have others better approach?

The ioctl() way is a no go. You have everything you must know inside the
kernel. You know the number of SCO connections and the voice setting and
the driver must be able to deal with this by itself.

> Last, I found new problem when three SCO channels were connected
> ACL links (RFCOMM) that also connected to three Headset for control have
> very long response time (sometime up to 10 seconds or more to appear
> after I pressed a button on Headset). What are the sources of this problem?
> - Bandwidth limitation of Bluetooth and theirs packet type?
> - Implementation of Bluetooth firmware on USB dongle?
> - Implementation of USB stack on Linux?
> - Implementation of BlueZ stack?

It is maybe a firmware/chip limitation or a limitation of the piconet
itself, because SCO channels have reserved bandwith and then may nothing
is left for the ACL links.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel