Re: [Bluez-devel] An explanation of a2dpd weird behaviour on high resolution timers enabled kernels

[Fabien Chevalier <fabchevalier@free.fr>]

Hi all, please find some comments below.

> Let's take an example : An application write 40 ms of music.
> If you internally buffer the data, then the application will consider it
>  written (not played yet).
> The application will then wait for the data to be played by repeatedly 
> asking the delay until is it 0. However, that application 
> will NOT call write(), preventing the plugin code to be executed.
> 
> I already hear you saying, let's put the code in getdelay() too. This is not possible
> because the application can also call getdelay() once and wait, or even not call
> getdelay() at all, because the number of music data is known...
> 
> However, using a thread can solve this issue.
> 
>> Ok, then we have to implement snd_pcm_get_delay() and offer the option 
>> to the application to sleep itself (or do other time consuming tasks 
>> such as video decoding). However when the application sends data too 
>> fast (such as a simple aplay) we *have* to do the sleeping ourselves to 
>> prevents cuts on the headset side :-)
> 
> Aplay is not sending the data too fast. aplay tries to fill the sound
> card buffer as 100% of sound playing application do.
> Buffer size being known, delay determine available space. When there is
> space, aplay writes data and that's all.
> 
> The current plugin delay implementation is the number of data written
> (not played) => delay is always 0 => buffer is always empty => aplay
> fills it => plugin have to wait in the write() call.
> 

Ok, this time i understood. I agree with you. Which means two things:
  * i basically screwed up the pcm plugin i did a while ago for headsetd 
:-(. I was wrongs about the sleeping stuff. I understood alsa dynamic 
behaviour the wrong way.
  * ALSA API has the builtin assomption that the data gets transmitted 
using a hardware ring buffer, which is not the bluetooth way of things 
when you send packets one after the other.

This means we have to workaround this by implementing a virtual buffer 
with a virtual hardware pointer.
While as Marcel, i'm not a big fan of threads, i'd tend to see them here 
as the less worse alternative we have :-) : so i'd say : let's go with 
threads !!

> I'm not sure we can assume an headset will buffer the received packets.

Well it does. However how much is left completely unspecified by the 
bluetooth specs. :-(

> In fact, the only application to care about is the sound server.

Could you be more specific on that ?
If you think of pulseaudio as the sound server, i'm afraid a native 
pulse plugin will have to be written for good bluetooth support anyway.

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel