Marcel, Brad, Jose

Please find attached another rework of the SCO flow control patch. This 
patch is against 2.6.19.1.
I hope i'm getting closer to something that's good enough for inclusion 
in mh patches (Marcel, i'm waiting for your comments here ;-) ).

The only change compared to the previous release, is that the callback 
is gone.
The send complete aknowledge is now done using the skb destructor. As a 
consequence the sco feature is still strongly linked to sk_buffs & 
generic socket behaviour. However it looks like sound-of-bluez will be 
built on top of the socket layer, and won't replace it... so it looks OK 
for me to still have that strong dependancy on sockets.

Some design points are explained below (just a copy of one of my 
previous e-mails):

Point 1 : Why rely on hrtimers ?
As discussed previously on the list, there is no transport agnostic way 
to throttle ourselves to send data at the right rate.
SCO flow control support at HCI level is optionnal, thus we cannot rely 
on it.
Relying on isochronous USB transfer is not good as well, as it poses 
some architectural issues underlined by Marcel's previous e-mails. 
Moreover i suspect this to rely on USB host controller clock, which is 
unrelated to the bluetooth chip clock, and thus will  suffer the same 
clock offset drawback that a timer based approach.
So at some point we have to throttle ourselves, and timers can be used 
for that.

Point 2 : What about buffer settings ?
Audio API expects the application to specify a 'buffer size' and 'period 
size'.
Period size is the size of data that sound card hardware processes at a 
time.
Buffer size is a multiple of the period size, and is shared by both ALSA 
and the hardware
to move data from one to another.
One important thing to understand is that the biggest the buffer, the 
longer the added latency added.
That's why xmms's playing buffer default to 500 ms, while Ekiga's one is 
as small as two period sizes.
As it's up to the application to choose its buffer size, there is a need 
for SCO sockets to expose and API
to change the size of the buffer. There already exist such an API, which 
is SO_SNDBUF and SO_RCVBUF
setsockopt options, however the measurment does include the size of 
in-kernel data structures, which means the application has no way to 
tell the exact size of the buffer without knowing how big are the kernel 
data structures.
For ALSA this is not acceptable.
So i introduces SCO_TXBUFS and SCO_RXBUFS socket options to be able to 
specify a number of sco packets.
There is a nice tutorial on this subject by ALSA project that can be 
found on:
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html

Cheers,

Fabien