From: Frederic Dalleau <frederic.dalleau@access-company.com>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
In-Reply-To: <46C1A555.80404@free.fr>
References: <46BD85F4.1090400@free.fr> <1186855275.6698.10.camel@violet>
	<1186999158.6262.10.camel@ubuntu.mpl.access-company.com>
	<1186999538.6698.141.camel@violet> <46C07EAC.8060407@free.fr>
	<1187024669.6698.214.camel@violet>
	<1187027354.6262.59.camel@ubuntu.mpl.access-company.com>
	<46C1A555.80404@free.fr>
Date: Tue, 14 Aug 2007 16:47:16 +0200
Message-Id: <1187102836.3463.60.camel@ubuntu.mpl.access-company.com>
Mime-Version: 1.0
Subject: Re: [Bluez-devel] An explanation
	of	a2dpd	weird	behaviour	on	high	resolution timers enabled kernels
Reply-To: BlueZ development <bluez-devel@lists.sourceforge.net>
Content-Type: text/plain; charset="us-ascii"
Sender: bluez-devel-bounces@lists.sourceforge.net
Errors-To: bluez-devel-bounces@lists.sourceforge.net

Hi,

I'll try to be more clear,

> > Even if enough data is buffered, you are not guaranteed that the
> > application will send data in time. Worse, if enough data is buffered,
> > the application can choose not to send more data. The application calls
> > snd_pcm_get_delay(), then sleeps for the remaining delay, then sends new
> > data. This is typically true at the end of a stream. The application
> > write what can be written, then wait until the stream underrun, without
> > writing anymore.
> 
> I'm not sure i understood your last paragraph : could you please 
> expand/reformulate ?

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.

> This means we have to implement some kind of "virtual buffer" and sleep 
> only after this buffer is full, and not after each packet is sent.

I'm not sure we can assume an headset will buffer the received packets.
data should be sent as regularly as possible.

> Or at first we can just say "go to hell" to those applications that do 
> everything in the same thread and choose to solve the issue later :-)

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

Frederic


-------------------------------------------------------------------------
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