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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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?
>> 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?
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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?
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. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
>
>
>
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. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
>
>
>
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. http://www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel
-----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. http://www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel
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. http://www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel
Hi Suriyan,
> I would like to known feasibility to add multi SCO connections support on
> BlueZ stack. I try lastest patched 2.6.9-mh3, I saw sco_num and acl_num were
> counted separately, is BlueZ stack going to support multi SCO connections?
this has nothing to do with it.
> 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.
> 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)?
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel