Continued : SCO flow control patch design questions

Continued : SCO flow control patch design questions

[Fabien Chevalier]

[-- Attachment #1: Type: text/plain, Size: 3899 bytes --]


All & Marcel,

I'm moving a discution with Marcel on the list, as others might which to 
jump in the discutions.
> Hi Fabien,
>
>   
>>> No. I only need to understand some of your decisions why you did
>>> something in this particular way.
>>>  
>>>   
>>>       
>> Ok, i'm gonna try to come up with something. 
>> If you have some particular questions that you would like to be
>> answered,
>> please send them to me, this will avoid me to play the
>> 'guess-what-he-wants-me-to-explain'
>> game :-)
>>     
>
> the important one is about the callback to signal when a packet actually
> has been send. This is too ugly for me. I would prefer if we don't need
> this at all. If we need it, we have to do it a little bit different and
> much more cleaner.
>
> The other questions is for what we actually use the hrtimer and some
> things about the buffer settings on the socket.
>
> Regards
Ok, now i see what you mean, so here are a few answers:

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

Point 3 : Why is there a callback ?
Yes i agree this is not the cleanest design ever.
This design fullfills two constraints posed by Marcel:
 * keep the packet list in the core, and stream it from there.
 * open the door to a user level implementation that would not rely on 
sockets

The callbask just says : ok one packet is sent, there is room on my 
internal queue, send me one more!
I have an idea on how to do it without introducing a callback, however 
this would make it rely on sockets flow control, and thus would break 
second item.
Streaming packets from the socket queue directly would make the thing 
really easy to implement, but would break both items :-(. If you 
remember, this was the spirit of my first patch ;-)
Marcel : Your opinion is welcomed on this point. If you say bye bye to 
second item, i can come up with a solution without callbacks.

Marcel & All,

Your comments are of course welcome :-)
Yet another thing : if we could agree on a design before i start coding 
again, that would really be great ;-)

Cheers,

Fabien

[-- Attachment #2: Type: text/html, Size: 4622 bytes --]