[Bluez-devel] multi rfcomm/sco connection

[Bluez-devel] multi rfcomm/sco connection

[ubaldo]

Buondi', 

I would like to understand why it is not possible to establish more than one 
sco connection and more than an rfcomm connection with and usb-dongle. 




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

[Marcel Holtmann]

Hi,

> I would like to understand why it is not possible to establish more than one 
> sco connection and more than an rfcomm connection with and usb-dongle. 

it is possible to establish up to 30 RFCOMM connections into each
direction. The number of SCO connections is limited to one per ACL link.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: multi rfcomm/sco connection

[ubaldo]

>> I would like to understand why it is not possible to establish more than one 
>> sco connection and more than an rfcomm connection with and usb-dongle. 
> 
> it is possible to establish up to 30 RFCOMM connections into each
> direction. The number of SCO connections is limited to one per ACL link.

Does it mean that for each SCO connection I need another bt-dongle, or there 
is a way to allow multi SCO connection with the same bt-dongle?

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

[Marcel Holtmann]

Hi,

> > it is possible to establish up to 30 RFCOMM connections into each
> > direction. The number of SCO connections is limited to one per ACL link.
> 
> Does it mean that for each SCO connection I need another bt-dongle, or there 
> is a way to allow multi SCO connection with the same bt-dongle?

I said per ACL link. The Bluetooth specification defines that between
two devices one ACL and up to three SCO links can exists. The max number
of SCO links per piconet is also three. In BlueZ we currently allow one
ACL and one SCO link between two devices. This limitation is some kind
of historic. Feel free to fix it.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: multi rfcomm/sco connection

[ubaldo]

Thanx Marcel for your unlimited patience! :) 


>> > it is possible to establish up to 30 RFCOMM connections into each
>> > direction. The number of SCO connections is limited to one per ACL link. 
>> 
>> Does it mean that for each SCO connection I need another bt-dongle, or there 
>> is a way to allow multi SCO connection with the same bt-dongle?
> 
> I said per ACL link. The Bluetooth specification defines that between
> two devices one ACL and up to three SCO links can exists. The max number
> of SCO links per piconet is also three. In BlueZ we currently allow one
> ACL and one SCO link between two devices. This limitation is some kind
> of historic. Feel free to fix it.

Any tip for where to put the eyes on for fixing? 

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

[Marcel Holtmann]

Hi,

> > I said per ACL link. The Bluetooth specification defines that between
> > two devices one ACL and up to three SCO links can exists. The max number
> > of SCO links per piconet is also three. In BlueZ we currently allow one
> > ACL and one SCO link between two devices. This limitation is some kind
> > of historic. Feel free to fix it.
> 
> Any tip for where to put the eyes on for fixing? 

actually I don't see why you need more than one SCO link in a connection
between two devices. However take a look at the kernel source code of
Linux 2.6.x and especially at net/bluetooth/hci_conn.c
Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: multi rfcomm/sco connection

[ubaldo]

Ciao Marcel, 

> actually I don't see why you need more than one SCO link in a connection
> between two devices. However take a look at the kernel source code of
> Linux 2.6.x and especially at net/bluetooth/hci_conn.c

I explain you a bit more my situation... 

I need to be able with a single usb-bt-dongle to play/capture audio for 
several bt-handsfree, I tried with one and there are no problems, but if I 
try to connect another one then I get something like "sco channel busy". 

I studied the net/bluetooth directory but I cannot find any good way to 
achieve what I need! :) 

Am I wrong in something or is this feature really missing?

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

[Marcel Holtmann]

Hi,

> > actually I don't see why you need more than one SCO link in a connection
> > between two devices. However take a look at the kernel source code of
> > Linux 2.6.x and especially at net/bluetooth/hci_conn.c
> 
> I explain you a bit more my situation... 
> 
> I need to be able with a single usb-bt-dongle to play/capture audio for 
> several bt-handsfree, I tried with one and there are no problems, but if I 
> try to connect another one then I get something like "sco channel busy". 
> 
> I studied the net/bluetooth directory but I cannot find any good way to 
> achieve what I need! :) 
> 
> Am I wrong in something or is this feature really missing?

as I said, between two devices BlueZ supports only one ACL link and one
SCO link. These links a bi-directional so you can play and capture audio
data at the same time. The limit to one SCO link is only a per ACL link
limitation. If you open a second ACL to another device you can also have
a second SCO link bound to that connection.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

[Radha Thiagarajan]

Marcel,

We need clarification from you about two things regarding SCO.

1) We noticed that the SCO module has different behavior when dealing 
with BDADDR_ANY as opposed to a specific bluetooth address. If a device 
is told to listen for a SCO connection with BDADDR_ANY, and then creates 
an outgoing SCO connection to a device using BDADDR_ANY, the connection 
succeeds. Later, if an incoming SCO connection is received, the listen 
socket will accept the connection (thus producing two SCO connections 
over 2 ACL connections to 2 different devices).

This is all fine, but if instead, we bind the listen socket with a 
specific device address (instead of BDADDR_ANY) and then try to make the 
outgoing SCO connection using the specific address, it will fail 
claiming that the address is already in use. This looks like 
inconsistent behavior, given that even if we specify BDADDR_ANY and we 
only have one interface, both connections will be using the same interface.

So, in short, if BlueZ is asked to use a specific interface for both 
incoming and outgoing SCO connections, it will refuse to carry out the 
bind calls, but if BDADDR_ANY is used, it will allow both connections. 
Therefore, it appears to be a bug - either BlueZ really can't handle 
more than one SCO at a time and it is being tricked into doing it, or it 
should allow the user to specify the address and not complain.


2) Consider two devices A and B. A uses BlueZ while B does not. Let us 
also assume that B can handle more than one SCO per ACL connection.  Let 
us say that there is a SCO connection between A and B already. Then B 
initiates a second SCO connection on the same ACL to A. Looking at the 
source for this situation, it appears that  the device A will overwrite 
the SCO socket values with the new one that was just established (since 
it allows only one SCO per ACL). Is this the intended behavior?

Thanks,
Radha


On 07/16/2004 10:29 AM, Marcel Holtmann wrote:

>as I said, between two devices BlueZ supports only one ACL link and one
>SCO link. These links a bi-directional so you can play and capture audio
>data at the same time. The limit to one SCO link is only a per ACL link
>limitation. If you open a second ACL to another device you can also have
>a second SCO link bound to that connection.
>
>Regards
>
>Marcel
>
>  
>

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

[Marcel Holtmann]

Hi Radha,

> 1) We noticed that the SCO module has different behavior when dealing 
> with BDADDR_ANY as opposed to a specific bluetooth address. If a device 
> is told to listen for a SCO connection with BDADDR_ANY, and then creates 
> an outgoing SCO connection to a device using BDADDR_ANY, the connection 
> succeeds. Later, if an incoming SCO connection is received, the listen 
> socket will accept the connection (thus producing two SCO connections 
> over 2 ACL connections to 2 different devices).
> 
> This is all fine, but if instead, we bind the listen socket with a 
> specific device address (instead of BDADDR_ANY) and then try to make the 
> outgoing SCO connection using the specific address, it will fail 
> claiming that the address is already in use. This looks like 
> inconsistent behavior, given that even if we specify BDADDR_ANY and we 
> only have one interface, both connections will be using the same interface.
> 
> So, in short, if BlueZ is asked to use a specific interface for both 
> incoming and outgoing SCO connections, it will refuse to carry out the 
> bind calls, but if BDADDR_ANY is used, it will allow both connections. 
> Therefore, it appears to be a bug - either BlueZ really can't handle 
> more than one SCO at a time and it is being tricked into doing it, or it 
> should allow the user to specify the address and not complain.

there is a simply answer to that question. It is a bug :(

> 2) Consider two devices A and B. A uses BlueZ while B does not. Let us 
> also assume that B can handle more than one SCO per ACL connection.  Let 
> us say that there is a SCO connection between A and B already. Then B 
> initiates a second SCO connection on the same ACL to A. Looking at the 
> source for this situation, it appears that  the device A will overwrite 
> the SCO socket values with the new one that was just established (since 
> it allows only one SCO per ACL). Is this the intended behavior?

I read the source that the new SCO connection will be overwritten with
the value of the first one. However this still doesn't looks very nice
in any case.

Are you planning to use SCO over HCI or PCM?

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

[Radha Thiagarajan]

Hi Marcel,

Thanks for the reply. We will be using SCO over PCM.
Are you planning on a fix for both the problems?

Thanks,
Radha.


On 08/04/2004 06:35 PM, Marcel Holtmann wrote:

>Hi Radha,
>
>> 1) We noticed that the SCO module has different behavior when dealing 
>> with BDADDR_ANY as opposed to a specific bluetooth address. If a device 
>> is told to listen for a SCO connection with BDADDR_ANY, and then creates 
>> an outgoing SCO connection to a device using BDADDR_ANY, the connection 
>> succeeds. Later, if an incoming SCO connection is received, the listen 
>> socket will accept the connection (thus producing two SCO connections 
>> over 2 ACL connections to 2 different devices).
>> 
>> This is all fine, but if instead, we bind the listen socket with a 
>> specific device address (instead of BDADDR_ANY) and then try to make the 
>> outgoing SCO connection using the specific address, it will fail 
>> claiming that the address is already in use. This looks like 
>> inconsistent behavior, given that even if we specify BDADDR_ANY and we 
>> only have one interface, both connections will be using the same interface.
>> 
>> So, in short, if BlueZ is asked to use a specific interface for both 
>> incoming and outgoing SCO connections, it will refuse to carry out the 
>> bind calls, but if BDADDR_ANY is used, it will allow both connections. 
>> Therefore, it appears to be a bug - either BlueZ really can't handle 
>> more than one SCO at a time and it is being tricked into doing it, or it 
>> should allow the user to specify the address and not complain.
>
>there is a simply answer to that question. It is a bug :(
>
>> 2) Consider two devices A and B. A uses BlueZ while B does not. Let us 
>> also assume that B can handle more than one SCO per ACL connection.  Let 
>> us say that there is a SCO connection between A and B already. Then B 
>> initiates a second SCO connection on the same ACL to A. Looking at the 
>> source for this situation, it appears that  the device A will overwrite 
>> the SCO socket values with the new one that was just established (since 
>> it allows only one SCO per ACL). Is this the intended behavior?
>
>I read the source that the new SCO connection will be overwritten with
>the value of the first one. However this still doesn't looks very nice
>in any case.
>
>Are you planning to use SCO over HCI or PCM?
>
>Regards
>
>Marcel
>
>  
>

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

[Marcel Holtmann]

Hi Radha,

> Thanks for the reply. We will be using SCO over PCM.
> Are you planning on a fix for both the problems?

the point is if you use SCO over PCM then the SCO socket interface is
really useless. My idea is to add an ioctl to the L2CAP and RFCOMM
sockets for adding and releasing a SCO link. Actually I realized that I
never thought about incoming SCO connections for that case. Are there
any proposals for getting a nice SCO over PCM support?

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] SCO audio sync

[ubaldo]

I am having another strange problem, sometime when I record from a SCO 
channel in 16bit (0x0060) to a file the first byte is missing and when I 
play it back I listen just caos. 

But if I cut the first byte, or I add a byte in front of the file, then I 
can listen it fine. 

Is there a way to be sure that I am reading the packet in the right way? 




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SCO audio sync

[Marcel Holtmann]

Hi,

> I am having another strange problem, sometime when I record from a SCO 
> channel in 16bit (0x0060) to a file the first byte is missing and when I 
> play it back I listen just caos. 
> 
> But if I cut the first byte, or I add a byte in front of the file, then I 
> can listen it fine. 
> 
> Is there a way to be sure that I am reading the packet in the right way? 

check the mailing list archive, because I remember that there was a
thread about this problem.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

[ubaldo]

Ciao Suriyan, 

I was looking, few months ago, for a way to solve a problem more or less 
like your. 

All what I could do was to set the headphones to HV3 and the bt-dongle too, 
in this mode it was possible to "listen"  audio on 3 different channels, the 
problem, for me, was that this channels were "mixed" so if with a channel I 
was receiving 24bit with 3 channels they were 72, but I could not find a way 
to "demux" this caos who was coming out, but I remember I found a way to 
"create" 3 different sco connections with just one bt-(usb)-dongle.


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel

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

[Marcel Holtmann]

Hi,

> I was looking, few months ago, for a way to solve a problem more or less 
> like your. 
> 
> All what I could do was to set the headphones to HV3 and the bt-dongle too, 
> in this mode it was possible to "listen"  audio on 3 different channels, the 
> problem, for me, was that this channels were "mixed" so if with a channel I 
> was receiving 24bit with 3 channels they were 72, but I could not find a way 
> to "demux" this caos who was coming out, but I remember I found a way to 
> "create" 3 different sco connections with just one bt-(usb)-dongle.

this sounds like a problem with the wrong alternate setting on the ISOC
interface of the USB device. Your workaround is not reliable and maybe
it is CSR specific. To get more than one SCO channel working the hci_usb
driver must be fixed to dynamicaly change the alternate settting.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel

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

[Suriyan]

Hi Marcel,

> > I have application to uses Bluetooth Headset work as Wireless Microphone
so
> > that I would like support up to 3 channels for each dongle.
Unfotunately,
> > with lastest BlueZ stack my application can support only one Headset per
> > dongle.
>
> Please read and understand my responses. We support one SCO per ACL
> link. Which means when you open three ACL links, you can also have three
> SCO links, but of course there can be only one ACL link between two
> Bluetooth devices.
>
I see, one SCO link per an ACL link between two Bluetooth devices.
My application each Bluetooth Headset operate separately (see text
diagram below) so that they have only one SCO link per an ACL link to
BlueZ side.

In the BlueZ side it must handle up to three pairs of SCO and ACL links
however each pair of links route to different Bluetooth device (Headset).

                                                                   V
                                                                   |
                  +-------------------------------------------+
                  |    BlueZ Stack (1 USB BT Adaptor)   |
                  +-------------------------------------------+


                   V                         V                         V
                   |                          |                          |
+----------------+    +----------------+      +----------------+
| BT Headset 1 |     |BT Headset 2 |       | BT Headset 3 |
+----------------+    +----------------+      +----------------+

I have test with hsplay (bluez-utils-2.7/test) to play audio file to two
Headsets by run hsplay separately but it's failed since the second
hsplay cannot create SCO connection with error report address in
use (-EADDRINUSE). By loooking into sco.c and bypass address check
in sco_sock_bind() the second hsplay can create SCO connection but
when SCO connection on secord hsplay is connected it cause both
Headsets are quiet while hcidump -x continue dump SCO data on
both SCO handles (I uses fixed 48 bytes of SCO packet size in hstest.c)

In the other way, I have test with hsmicro with two Headsets it's OK
but I must force Alternate Setting of Isochronous interface from default
2 to 4 (two 16 bits Voice links) in hci_usb_probe() [hci_usb.c]

I have work backward to hsplay after I force Alternate Setting to 4, it's
failed even first Headset since I heard noise on Headset.

Do you have any suggestions to solve my problem?

> > Anyone have going to add multi SCO connections support on BlueZ stack?
> > Please let me known, I'd like to hear from you all. Any contact would be
> > greatly appreciated.
>
> As I said, I haven't seen any application that needs to connect more
> than one SCO link to an ACL link. Your problem looks like a hardware
> limit. Are you using SCO over HCI or over PCM? What kind of Bluetooth
> dongle do you use (hciconfig -a)?
>
My application is described above needs more than one pair of SCO and ACL
link, not more than one SCO link to an ACL link.

I uses SCO over HCI (hci_usb.c). My dongle hciconfig -a shown below :-

hci0: Type: USB
BD Address: 00:10:60:AA:32:13 ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:1057 acl:0 sco:0 events:29 errors:0
TX bytes:440 acl:0 sco:0 commands:28 errors:0
Features: 0xff 0xff 0x0f 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: 'BlueZ (0)'
Class: 0x000100
Service Classes: Unspecified
Device Class: Computer, Uncategorized
HCI Ver: 1.1 (0x1) HCI Rev: 0x33c LMP Ver: 1.1 (0x1) LMP Subver: 0x33c
Manufacturer: Cambridge Silicon Radio (10)


Additional hciconfig hci0 revision shown below :-

hci0: Type: USB
BD Address: 00:10:60:AA:32:13 ACL MTU: 192:8 SCO MTU: 64:8
HCI 16.14
Chip version: BlueCore02
Max key size: 56 bit
SCO mapping: HCI


Any your suggestions would be greatly appreciated.

Regards

Suriyan




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel

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

[Marcel Holtmann]

Hi Suriyan,

> > Please read and understand my responses. We support one SCO per ACL
> > link. Which means when you open three ACL links, you can also have three
> > SCO links, but of course there can be only one ACL link between two
> > Bluetooth devices.
> >
> I see, one SCO link per an ACL link between two Bluetooth devices.
> My application each Bluetooth Headset operate separately (see text
> diagram below) so that they have only one SCO link per an ACL link to
> BlueZ side.
> 
> In the BlueZ side it must handle up to three pairs of SCO and ACL links
> however each pair of links route to different Bluetooth device (Headset).
> 
>                                                                    V
>                                                                    |
>                   +-------------------------------------------+
>                   |    BlueZ Stack (1 USB BT Adaptor)   |
>                   +-------------------------------------------+
> 
> 
>                    V                         V                         V
>                    |                          |                          |
> +----------------+    +----------------+      +----------------+
> | BT Headset 1 |     |BT Headset 2 |       | BT Headset 3 |
> +----------------+    +----------------+      +----------------+
> 
> I have test with hsplay (bluez-utils-2.7/test) to play audio file to two
> Headsets by run hsplay separately but it's failed since the second
> hsplay cannot create SCO connection with error report address in
> use (-EADDRINUSE). By loooking into sco.c and bypass address check
> in sco_sock_bind() the second hsplay can create SCO connection but
> when SCO connection on secord hsplay is connected it cause both
> Headsets are quiet while hcidump -x continue dump SCO data on
> both SCO handles (I uses fixed 48 bytes of SCO packet size in hstest.c)

oh yes, I remember that there was a problem with more than one SCO
connection sharing the same source address. Please don't ask me why we
have this limit. Feel free to send in a patch.

> In the other way, I have test with hsmicro with two Headsets it's OK
> but I must force Alternate Setting of Isochronous interface from default
> 2 to 4 (two 16 bits Voice links) in hci_usb_probe() [hci_usb.c]

This is a known problem, because we don't use a dynamic alternate
setting switching. It must be fixed inside the driver.

> I have work backward to hsplay after I force Alternate Setting to 4, it's
> failed even first Headset since I heard noise on Headset.

Won't work, because when only one headset is connected the alternate
setting should be 2. Check the HCI USB transport specification for the
details.

> Do you have any suggestions to solve my problem?

Send me a patch for the hci_usb driver that can switch the alternate
setting depending on the number of SCO connections. You should talk to
the Bluetooth ALSA (bluetooth-alsa.sf.net) guys, because they will need
this too.

> > As I said, I haven't seen any application that needs to connect more
> > than one SCO link to an ACL link. Your problem looks like a hardware
> > limit. Are you using SCO over HCI or over PCM? What kind of Bluetooth
> > dongle do you use (hciconfig -a)?
> >
> My application is described above needs more than one pair of SCO and ACL
> link, not more than one SCO link to an ACL link.
> 
> I uses SCO over HCI (hci_usb.c). My dongle hciconfig -a shown below :-
> 
> hci0: Type: USB
> BD Address: 00:10:60:AA:32:13 ACL MTU: 192:8 SCO MTU: 64:8
> UP RUNNING PSCAN ISCAN
> RX bytes:1057 acl:0 sco:0 events:29 errors:0
> TX bytes:440 acl:0 sco:0 commands:28 errors:0
> Features: 0xff 0xff 0x0f 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: 'BlueZ (0)'
> Class: 0x000100
> Service Classes: Unspecified
> Device Class: Computer, Uncategorized
> HCI Ver: 1.1 (0x1) HCI Rev: 0x33c LMP Ver: 1.1 (0x1) LMP Subver: 0x33c
> Manufacturer: Cambridge Silicon Radio (10)
> 
> 
> Additional hciconfig hci0 revision shown below :-
> 
> hci0: Type: USB
> BD Address: 00:10:60:AA:32:13 ACL MTU: 192:8 SCO MTU: 64:8
> HCI 16.14
> Chip version: BlueCore02
> Max key size: 56 bit
> SCO mapping: HCI

So in general this can work, but I don't know if this Bluetooth chip and
its firmware are supposed to work. Can one from CSR please confirm that
we can use three SCO links with HCI transport with the 16.14 firmware.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel

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

[Lars Grunewaldt]

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

Marcel Holtmann wrote:
|>In the other way, I have test with hsmicro with two Headsets it's OK
|>but I must force Alternate Setting of Isochronous interface from default
|>2 to 4 (two 16 bits Voice links) in hci_usb_probe() [hci_usb.c]
|
|
| This is a known problem, because we don't use a dynamic alternate
| setting switching. It must be fixed inside the driver.
|
| Send me a patch for the hci_usb driver that can switch the alternate
| setting depending on the number of SCO connections. You should talk to
| the Bluetooth ALSA (bluetooth-alsa.sf.net) guys, because they will need
| this too.

*developer raising hand*

I'm one of the bt-alsa guys and looked into the problem a bit. You can
find my questions in the mailing list archive of bluez-devel, Topic was
"question about hci_usb endpoint selection..."

We cleared some basic things like what usb callbacks are needed, but I
never came to selecting the correct alternate mode.

I short it comes down to something like:

"the number of sco connections and there type (16b, 8b) lead to the
alternate setting. Look again in the BT specs for this".

Another excerpt from the email communication:

***
~ int usb_set_interface(struct usb_device *dev, int interface, int
alternate);
***

The documentation/manpage says:

***
Note that in the Linux USB subsystem, bandwidth associated with an
endpoint in a given alternate setting is not reserved until an URB is
submitted that needs that bandwidth. Some other operating systems
allocate bandwidth early, when a configuration is chosen.

This call is synchronous, and may not be used in an interrupt context.
Also, drivers must not change altsettings while urbs are scheduled for
endpoints in that interface; all such urbs must first be completed
(perhaps forced by unlinking).
***

Please have a closer look at the older email communication, if you begin
to develop a solution it would be great if you can keep me up-to-date so
that we don't do the same work twice.

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

iD8DBQFBjQAVQWC6DTWkDAoRAj2CAJ95/FndEkAExhpxoFepV575WlXQWwCbBP0q
mlqU0TpoDkgYY1WwAchOSow=
=ujWU
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel

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

[Suriyan]

Hi Marcel,

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.

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. ***

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?

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?

Regards

Suriyan.




-------------------------------------------------------
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

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

[Marcel Holtmann]

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

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

[Lars Grunewaldt]

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

Marcel Holtmann wrote:

|>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.

Question is, how can we handle the endpoint selection when we can't use
usb_set_interface() in the notify function? Or to be more precisly, when.

Next question is what happens to not-yet-send packages, I think we must
empty all queues before we can use usb_set_interface.

What function in the kernel driver would you use to add this? maybe the
send functions? We could set a flag "change endpoint to..." in notify
and apply the change when queues are empty - and reject/hold new send
urbs until we were able to change the endpoint setting.

Maybe?

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

iD8DBQFBl4TtQWC6DTWkDAoRAjGfAJ9M/d+eILKDbDOouVVBmIHu5HxtwACglGY2
RQOhETxlea2hR0mqL0Du7qw=
=Z5px
-----END PGP SIGNATURE-----


-------------------------------------------------------
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

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

[Marcel Holtmann]

Hi Lars,

> | 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.
> 
> Question is, how can we handle the endpoint selection when we can't use
> usb_set_interface() in the notify function? Or to be more precisly, when.
> 
> Next question is what happens to not-yet-send packages, I think we must
> empty all queues before we can use usb_set_interface.

you must stop the current ISOC URBs and then change the alternate
setting and then submit them again. Even more you shouldn't started them
in the open routine. Only start them when a SCO link is created.

> What function in the kernel driver would you use to add this? maybe the
> send functions? We could set a flag "change endpoint to..." in notify
> and apply the change when queues are empty - and reject/hold new send
> urbs until we were able to change the endpoint setting.

I don't think that this will more, because you are in the wrong context
too. However check with in_interrupt() and do this always on a SMP and
preempt enabled kernel.

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