Return-Path: Message-ID: <471E2711.2010001@free.fr> Date: Tue, 23 Oct 2007 18:53:37 +0200 From: Fabien Chevalier MIME-Version: 1.0 To: BlueZ development References: <719D5CCC2F6E3644B0A9F5C9B1D00088038171C2@esebe104.NOE.Nokia.com> <471730B2.3030606@free.fr> <719D5CCC2F6E3644B0A9F5C9B1D0008803882911@esebe104.NOE.Nokia.com> In-Reply-To: <719D5CCC2F6E3644B0A9F5C9B1D0008803882911@esebe104.NOE.Nokia.com> Subject: Re: [Bluez-devel] PATCH1/2: bluez-utils-fix-a2dp-buffer-constraints Reply-To: BlueZ development List-Id: BlueZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: bluez-devel-bounces@lists.sourceforge.net Errors-To: bluez-devel-bounces@lists.sourceforge.net 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