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