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