_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Jose,
> Very interesting. I interpreted this to mean that if synchronous
> channels are supported, then synchronous flow control is required.
> Some form of feedback from the HCI device is required to main
> synchronization. If you use timers you run occasional the risk of
> getting out of sync.
that shouldn't be such a problem. It is only audio data.
> All this speculation can be clarified if someone with an actual UART
> dongle can speak up. The patch that I posted should work as long
> as the device implements synchronous flow control. Maybe the
> solution is to not support SCO on UART until someone can take
> responsibility.
I have a couple of UART based development kits at home and I can
actually test it. However you shouldn't think about the actual transport
at all. This is the job of the driver and not the Bluetooth core. So it
must work with SCO flow control enabled and disabled.
> BTW, the IEEE spec is the base for bluetooth.
That is wrong. The IEEE specification was written based on the Bluetooth
specification. What gets released by the Bluetooth SIG at bluetooth.com
is the specification that counts.
Regards
Marcel
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fabien,
Very interesting. I interpreted this to mean that if synchronous
channels are supported, then synchronous flow control is required.
Some form of feedback from the HCI device is required to main
synchronization. If you use timers you run occasional the risk of
getting out of sync.
All this speculation can be clarified if someone with an actual UART
dongle can speak up. The patch that I posted should work as long
as the device implements synchronous flow control. Maybe the
solution is to not support SCO on UART until someone can take
responsibility.
One thing is clear, the current code is wrong. It allows application
programs to easily cause Linux to panic. I'm very surprised that this
condition has been allowed.
BTW, the IEEE spec is the base for bluetooth.
Jose
Fabien Chevalier wrote:
> Hello Jose,
>
> The documents i used as reference are the ones from bluetooth SIG. I
> don't know who copied the others, but they are closely similar to the
> one from IEEE :-)
> Concerning SCO flow control over UART link, it is stated nowhere it is
> mandatory nor optionnal. :-(
>
> However, having a look at the Bluetooth 2.0+EDR spec (available on
> http://www.bluetooth.com), section 6.26 "Supported commands" describes the
> bitmask that lists the supported hci commands for a given
> implementation, stating that *It is implied that if a command is listed
> as supported, the feature underlying that command is also supported.*
>
> And guess what ?.... in the bitmask there is a bit for the "Write
> Synchronous flow control enable" command. ;-)
>
> *** cut here ***
> 0 Read Hold Mode Activity
> 1 Write Hold Mode Activity
> 2 Read Transmit Power Level
> 3 Read Synchronous Flow Control Enable
> 10
> 4 Write Synchronous Flow Control Enable
> 5 Set Host Controller To Host Flow Control
> 6 Host Buffer Size
> 7 Host Number Of Completed Packets
> *** cut here ***
>
> Having analysed all these informations, my guess is that it is
> synchronous flow control is 'optionnal', even for uart links.
>
> Cheers,
>
> Fabien
>
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hello Jose,
The documents i used as reference are the ones from bluetooth SIG. I
don't know who copied the others, but they are closely similar to the
one from IEEE :-)
Concerning SCO flow control over UART link, it is stated nowhere it is
mandatory nor optionnal. :-(
However, having a look at the Bluetooth 2.0+EDR spec (available on
http://www.bluetooth.com), section 6.26 "Supported commands" describes the
bitmask that lists the supported hci commands for a given
implementation, stating that *It is implied that if a command is listed
as supported, the feature underlying that command is also supported.*
And guess what ?.... in the bitmask there is a bit for the "Write
Synchronous flow control enable" command. ;-)
*** cut here ***
0 Read Hold Mode Activity
1 Write Hold Mode Activity
2 Read Transmit Power Level
3 Read Synchronous Flow Control Enable
10
4 Write Synchronous Flow Control Enable
5 Set Host Controller To Host Flow Control
6 Host Buffer Size
7 Host Number Of Completed Packets
*** cut here ***
Having analysed all these informations, my guess is that it is
synchronous flow control is 'optionnal', even for uart links.
Cheers,
Fabien
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fabien,
You need to get the IEEE 802.15.1 specification. Go to here:
http://standards.ieee.org/getieee802/802.15.html
Section 11.4 talks about HCI flow control. I don't see that
this facility is optional. In the case of USB, it's different
because another mechanism exists for flow control.
Has anyone every used SCO with a UART link?
Jose
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Jose,
> Hi Fabien,
>
> It's my understanding from reading the IEEE spec that Bluetooth
Could you point me to what you refer to ?
I had a look to the following document
http://www.bluetooth.com/NR/rdonlyres/24C24181-5B5D-4566-BB4F-D4C302910B9D/1766/Volume4_SPEC.pdf
which describes bt transport over uart, but did not find any mention of
synchronous flow control beeing mandatory :-(
> compliant devices with UART interface must support synchronous
> flow control if they support SCO channels. But I have no experience
> with such devices. Has anyone else used such a device?
I don't either :-(
Cheers,
Fabien
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fabien
I would like to better document how to try this patch and use it with
the alsa sco plugin. I've started it in
https://help.ubuntu.com/community/BluetoothAudio
Is the sco plugin in our cvs current and will it enable your flow control?
Brad
> After a few very busy months at work i finally had the opportunity to go
> back to my bluez flow control patch i left in the middle of nowhere back
> in May. :-)
> You will find attached an updated version of the patch against
> 2.6.18-mh4, as well as a sample test program that shows the flow control
> stuff is really working.
>
> Major changes compared to previous versions:
> * Packets are queued in the core, and are dequeue from there.
> * Flow control is achieved using high resolution timers. This means the
> code is really HZ independant, and things will even go better when the
> dyntick patch which has been in the air recently will be included in the
> mainline kernel.
> * Fixed a stupid bug that would cause packets to be sent really too
> slowly when HZ was < 1000
> * Should work with HZ = 100, 250, 1000, ... or whatever else. I tested
> with 250 HZ only for now.
> * Wrote a test program, "headsettest". To run this program you will need
> an USB dongle that supports SCO, as well as a
> headset. This program records your own voice for 30 seconds, then plays
> what it recorded in your ears for 30 seconds. Beware : Running it
> without the flow control patch is likely to crash your box !!
> * The patch is cleaner. This is mainly due to the fact i am getting to a
> better understanding of Linux socket layer.DEFAULT_SCO_RXBUFS;
> sk->sk_sndtime
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Jose,
Please see my comments below.
> Hi Fabien,
>
> So your issue is supporting synchronous channels on the UART
> interface.
Well, i would be better if this flow control issue was solved once and
for all, for all kind of interfaces :-)
I think it's best to enable synchronous flow control.
Do you know if this feature is supported by bt controllers on the UART
interface?
Cheers,
Fabien
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fabien Chevalier wrote:
> Hello Jose,
>
>
>> Hi, Fabien,
>>
>> I'll take a look at your patch. I've been working on one myself.
>> As I mentioned earlier, I've taken a different approach that works
>> well. I use the standard HCI synchronous flow control. Now since
>> USB dongles don't generate this, I have the hci_usb_tx_complete
>> generate a HCI_EV_NUM_COMP_PKTS for transfer. Then the existing
>> system works fine. No timers are necessary. Only a small change
>> to hci_sched_sco in hci_core.c was necessary.
>>
>
> Yes this will work. The only issue i see with this approach is that it
> is hci USB centric. This works with USB because there is a dedicated USB
> channel to send SCO packets, and the bandwidth of this channel is
> precisely the one of the SCO stream. So when the USB controller
> acknowledges the transmitted packet, you know you can precisely send the
> next one, which is great. :-)
>
> Now, for RS232 hci devices, there is only one physical channel, the
> RS232 link, which is shared for SCO/ACL/CMD packets. The bandwidth is
> typically as high as 921 kbit/s. This means when the R232 controller
> acknowledges the SCO packet, you have to wait a bit to send the next SCO
> packet, and thus rely a way or another on a timer. It's too bad, but i
> see no other way for now :-(
>
> Thus, if we take into account the fact completed packets events are not
> send by bt controllers, and that the flow control stuff should work
> whatever controller driver is, it think we have to rely on timers ;-)
>
>
Hi Fabien,
So your issue is supporting synchronous channels on the UART
interface. I think it's best to enable synchronous flow control.
and have the hci_uart manage the transmit queue to minimize delay.
This means that hci_uart can peek at the HCI_EV_NUM_COMP_PKTS
received to determine if another synchronous packet needs
to be sent.
Regards,
Jose
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
please find below a few additionnal notes
> Jose
>
>> The problem I'm running into now is with dynamic isochronous
>> allocation. By default my driver sets interface 1 to use alternative 0
>> (i.e. no bandwidth). When the SCO is opened, this is changed to
>> alternative 2. All this works great. It's when the SCO is closed or
>> a second SCO is opened that causes problems as the bandwidth
>> needs to be reallocated.
>
> You're encountering something we need to address anyway for multiple sco
> connections. I haven't had a very clear understanding of the alt
> setting. It seems that we were setting it to 2 and leaving it there but
> maybe it is actually going between 0 and 2 dynamically.
>
Alternate settings are used to have an isochronous USB endpoint working
at the appropriate bandwidth. Isochronous endpoints in USB have a
dedicated allocated bandwidth, so the bluetooth stack should select the
proper alternate setting, given the number of SCO connections opened,
and the bandwidth allocated to each one.
The table below sums up which alternate configuration must be used
given the number of sco channels in use.
Nr of 8 bits SCO Nr of 16 bits SCO Alt. config. to use
0 0 0
1 0 1
2 0 2
3 0 3
0 1 2
0 2 4
0 3 5
Cheers,
Fabien
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hello Jose,
> Hi, Fabien,
>
> I'll take a look at your patch. I've been working on one myself.
> As I mentioned earlier, I've taken a different approach that works
> well. I use the standard HCI synchronous flow control. Now since
> USB dongles don't generate this, I have the hci_usb_tx_complete
> generate a HCI_EV_NUM_COMP_PKTS for transfer. Then the existing
> system works fine. No timers are necessary. Only a small change
> to hci_sched_sco in hci_core.c was necessary.
Yes this will work. The only issue i see with this approach is that it
is hci USB centric. This works with USB because there is a dedicated USB
channel to send SCO packets, and the bandwidth of this channel is
precisely the one of the SCO stream. So when the USB controller
acknowledges the transmitted packet, you know you can precisely send the
next one, which is great. :-)
Now, for RS232 hci devices, there is only one physical channel, the
RS232 link, which is shared for SCO/ACL/CMD packets. The bandwidth is
typically as high as 921 kbit/s. This means when the R232 controller
acknowledges the SCO packet, you have to wait a bit to send the next SCO
packet, and thus rely a way or another on a timer. It's too bad, but i
see no other way for now :-(
Thus, if we take into account the fact completed packets events are not
send by bt controllers, and that the flow control stuff should work
whatever controller driver is, it think we have to rely on timers ;-)
>
> The problem I'm running into now is with dynamic isochronous
> allocation. By default my driver sets interface 1 to use alternative 0
> (i.e. no bandwidth). When the SCO is opened, this is changed to
> alternative 2. All this works great. It's when the SCO is closed or
> a second SCO is opened that causes problems as the bandwidth
> needs to be reallocated.
Yes, i agree with you, this is something that needs to be handled properly.
It could be done by adding some bits to the core so that it notifies the
driver when a SCO connection is opened/closed, so that the usb-hci
driver can select the right configuration. There already exists a notify
function in the hci driver interface, maybe it could be extended to
achieve this ?
I'm not gonna work on this however, as i still have some work to do on
the sco alsa plugin next :-)
Cheers,
Fabien
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Jose
> The problem I'm running into now is with dynamic isochronous
> allocation. By default my driver sets interface 1 to use alternative 0
> (i.e. no bandwidth). When the SCO is opened, this is changed to
> alternative 2. All this works great. It's when the SCO is closed or
> a second SCO is opened that causes problems as the bandwidth
> needs to be reallocated.
You're encountering something we need to address anyway for multiple sco
connections. I haven't had a very clear understanding of the alt
setting. It seems that we were setting it to 2 and leaving it there but
maybe it is actually going between 0 and 2 dynamically.
What is a decent uart-connected csr platform to test sco on? I have a
gumstix and a csr module but I'm still struggling the specs at
http://www.semiconductorstore.com/pdf/Bluegiga/esite_wt12.pdf
Brad
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fabien
> You will find attached an updated version of the patch against
> 2.6.18-mh4, as well as a sample test program that shows the flow control
> stuff is really working.
I'm glad you're hacking at this still and I hope we are converging on
something that everyone agrees on.
> Random notes :
> I tryed to enable number of completed packets events for synchronous
> connections,
> to get rid of all the timer stuff, however it didn't succeed.
How does this idea that didn't work out compare to the approach Jose is
discussing? From what I've seen they both seem to be considering the
problem at a lower level.
FYI, on the topic of plugins... I am writing up new documentation (using
the ubuntu wiki for now... don't hate me). I'm moving emphasis away from
the old "btsco" daemon method for sco audio. The sco alsa plugin detail
in the wiki is only a placeholder currently but I want to flesh it out soon.
https://help.ubuntu.com/community/BluetoothAudio
Brad
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi, Fabien,
I'll take a look at your patch. I've been working on one myself.
As I mentioned earlier, I've taken a different approach that works
well. I use the standard HCI synchronous flow control. Now since
USB dongles don't generate this, I have the hci_usb_tx_complete
generate a HCI_EV_NUM_COMP_PKTS for transfer. Then the existing
system works fine. No timers are necessary. Only a small change
to hci_sched_sco in hci_core.c was necessary.
The problem I'm running into now is with dynamic isochronous
allocation. By default my driver sets interface 1 to use alternative 0
(i.e. no bandwidth). When the SCO is opened, this is changed to
alternative 2. All this works great. It's when the SCO is closed or
a second SCO is opened that causes problems as the bandwidth
needs to be reallocated.
Jose
Chevalier wrote:
>
> Marcel, Brad, Jose,
>
> After a few very busy months at work i finally had the opportunity to
> go back to my bluez flow control patch i left in the middle of nowhere
> back in May. :-)
> You will find attached an updated version of the patch against
> 2.6.18-mh4, as well as a sample test program that shows the flow
> control stuff is really working.
>
> Major changes compared to previous versions:
> * Packets are queued in the core, and are dequeue from there.
> * Flow control is achieved using high resolution timers. This means
> the code is really HZ independant, and things will even go better when
> the dyntick patch which has been in the air recently will be included
> in the mainline kernel.
> * Fixed a stupid bug that would cause packets to be sent really too
> slowly when HZ was < 1000
> * Should work with HZ = 100, 250, 1000, ... or whatever else. I tested
> with 250 HZ only for now.
> * Wrote a test program, "headsettest". To run this program you will
> need an USB dongle that supports SCO, as well as a
> headset. This program records your own voice for 30 seconds, then
> plays what it recorded in your ears for 30 seconds. Beware : Running
> it without the flow control patch is likely to crash your box !!
> * The patch is cleaner. This is mainly due to the fact i am getting to
> a better understanding of Linux socket layer.
>
> Random notes :
> I tryed to enable number of completed packets events for synchronous
> connections,
> to get rid of all the timer stuff, however it didn't succeed.
> This is achieved using hcitool command while there are no active
> connections :
>
> tannat:/home/fchevalier/tmp/linux-2.6.18-mh4-fch# hcitool cmd 0x003
> 0X002F 0x01
> < HCI Command: ogf 0x03, ocf 0x002f, plen 1
> 01
> > HCI Event: 0x0e plen 4
> 01 2F 0C 00
> tannat:/home/fchevalier/tmp/linux-2.6.18-mh4-fch# hcitool cmd 0x003
> 0X002E
> < HCI Command: ogf 0x03, ocf 0x002e, plen 0
> > HCI Event: 0x0e plen 5
> 01 2E 0C 00 01
>
> I tryed with 3 different USB dongles :
> * one of them did not support this feature (old CSR 1.1 dongle)
> * the two others supported the feature, however did never send any
> completed packets events for SCO packets (Broadcom BCM2035 and ISSC).
>
> Due to this lack of working hardware i took the decision to stick with
> timers, even though it is not the best technical choice :-(
>
> Limitations :
> For now the flow control only works with CVSD air encoding
> (ie 16 bit frames). If 8 bit frames are used, data will be sent twice
> too fast.
>
> I am looking forward to your comments,
>
> Cheers,
>
> Fabien
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel