Hello,
I've been studying the SCO packet processing to understand how it works.
There are a few things that I noticed that don't seem quite right. I'll
attempt
to explain.
In the SCO transmit path, data gets put in a skb and then queued. There's
a tasklet that will dequeue and send the skb to the hci driver. This
tasklet
is scheduled when data needs to be sent or when there's a HCI event
HCI_EV_NUM_COMP_PKTS. This works fine for an ACL link and it could work
for a non-USB SCO transport. However, for USB HCI, the SCO data is carried
by the isochronous transport that doesn't require explicit flow control.
The
problem is that the current code (hci_sched_sco in hci_core.c) will send
all
packets to the hci layer with no flow control. That explains why
application
kludges have been introduced to avoid loosing packets.
Note that for non-USB links (i.e. UART), the current code is not correct
either as it doesn't enable HCI_EV_NUM_COMP_PKTS anywhere. Also,
the value of hdev->sco_cnt is never decremented.
Last May, Fabien Chevalier posted some patches to avoid this problem.
His approach of using timers didn't work for me but I think this is the
wrong
way to go about it. What is needed is a proper flow control mechanism
between
the bluetooth module and the hci layer for the case of USB HCI transport.
I'm thinking that a callback is necessary that is invoked by hci_usb to
kickstart the process.
I also have issues with hci_sched_sco. I think it should interleave skb
from
different active SCO sockets. Currently, it sends too many skbs from the
same socket flooding the dongle's buffers and potentially starving other
SCO channels.
I realize SCO handling has not been a priority and it sort of works.
Is there much interest in getting it right?
Regards,
Jose
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> > I realize SCO handling has not been a priority and it sort of works.
> > Is there much interest in getting it right?
>
> I'm very interested in it but I've only been able to address the
> application side of things. It looks like you've dug in and reached a
> decent understanding of where problems are.
>
> Developers of embedded systems are passing linux/bluez over because
> voice is too important to just have it "mostly" work.
>
> It's unfortunate that Fabien is not still working at it too. I was
> hoping he would keep a dialog going long enough to find an approach that
> Marcel likes but it seems like Fabien got tired of pushing it.
I am happy about any patches, but they must be clean and preferable not
breaking any kernel<->userspace API. Improving the SCO support would be
really nice.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Jose
> I realize SCO handling has not been a priority and it sort of works.
> Is there much interest in getting it right?
I'm very interested in it but I've only been able to address the
application side of things. It looks like you've dug in and reached a
decent understanding of where problems are.
Developers of embedded systems are passing linux/bluez over because
voice is too important to just have it "mostly" work.
It's unfortunate that Fabien is not still working at it too. I was
hoping he would keep a dialog going long enough to find an approach that
Marcel likes but it seems like Fabien got tired of pushing it.
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel