Re: [Bluez-devel] PATCH1/2: bluez-utils-fix-a2dp-buffer-constraints

[Fabien Chevalier <fabchevalier@free.fr>]

Hi Kai,

> Hi Fabian, Luiz, and others,
> 
> On 18 Oct 2007,  Fabien Chevalier wrote:
>>>>  - increased max overall buffer size to 16384 bytes (~93msecs
>>> hmm, looking at this more deeply, I realized this doesn't quite work.
> 
>>> I originally thought there is a real ringbuffer (imitating the usual 
>>> audio hardware ringbuffer) between the worker thread and the 
>>> application, but this appears not to be the case.
>> No this is not the case. :-)
>> I implemented it that way so that not to add another buffering layer.
>> As per ALSA semantic, the buffer is found in the remote 
>> device, but we have no way of knowing how big it is. :-(
> 
> ok, this indeed affects the buffering constraints we should
> expose to the client (and my original buffer-constraints patch
> should be reverted).
> 
> One drawback of this design is that the timing of packet transmission 
> is not totally controlled by the plugin. Instead, whenever the
> application
> decides to write to the ALSA device, a packet might be sent. If
> the overall buffer-size is not constrained, application can send
> bursts of data, which will lead to burts of RTP packets sent to 
> headset, which will probably confuse it. Of course, if the bursts
> stay within the limits of headset's receive buffer, we are ok, but
> that's seems somewhat fragile as we don't the buffer size.

Yes you've spotted the main drawback of this implementation :-)

> 
> To force application _not_ to do this, the plugin can put a strict
> limit on buffer size and period count (-> application cannot write
> bursts of data to the plugin, but instead it will have to sleep until
> the sufficient amount of time has elapsed). But as a consequency, the
> timing
> requirements become really strict for the application, which will
> lead to XRUNs on loaded systems (and POSIX realtime scheduling might
> not help as that might mess interactions with the worker and the
> application thread).

Agree :-)

> 
> Plus the following, quite common design in ALSA apps, doesn't 
> work as expected:
>   - preload X frames of audio to the plugin
>   - ... do something else (that takes time)
>   - use snd_pcm_start() to trigger playback
> ... as the headset might start playback already before snd_pcm_start().
> 
> But I do agree that it makes sense to avoid adding another
> layer of buffering in the plugin.
> 
> Hmm, one compromise solution might be to use the existing buffer
> setup, but use the worker thread to actually send the packets (at
> intervals 
> defined by the system timer, not by the application calls to
> the plugin). If we set the buffer constraint to match the number
> of bytes needed by the SBC encoder per packet, and allow use of
> multiple periods, we'd 1) have no duplicated buffering, 2) timing
> would be more regular, 3) application would have slightly more
> relaxed timing requirements (hopefully leading to less XRUNs).
> Comments?

Well, given the issues you've spotted with our current implementation,
i'd say i'm 100% for it :-) [Though i don't have time to work on it 
myself :-( ]
Btw This is the way Frederic Dalleau made his plugin implementation.



> 
>> Well, application can prefill more data, the data gets send 
>> immediately to the headset, and buffering will happen at 
>> headset side. The issue is if the buffer size as seen by the 
>> application is bigger than the real headset buffer size, and 
>> the application waits for the buffer to be almost empty before 
>> to refill it, then audio cuts might happen. :-(
> 
> Yeps, I guess that's precisely the risk with sending bursts of 
> packets. OTOH, I guess it's not so clear cut. I guess some headsets 
> may require an initial burst before they start playback.

Yes sure they do :-)

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