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

[Fabien Chevalier <fabchevalier@free.fr>]

Hello Kai,

> I've been testing with a low spec GNU/Debian desktop, and the problem has 
> been too high CPU load leading to a continuous stream of XRUNs in 
> the pcm_bluetooth.c code (i.e. no audio output at all). With the patch, 
> on the same exact system, playback is flawless. And the problem only
> occurs with apps that always poll/select before writing to the device (i.e.
> not aplay). Relaxing the buffering constraints allows apps to feed audio 
> to A2DP with less context switches and less system calls (bigger buffer
> fragments at a time basicly).

I'm quite interested in optimizations for low end ARM boxes :-)
Could you provide CPU details and the player you used to performed your 
testing ? I'd like to be able to reproduce those on my Neo1973 box :-)

> 
>>> -	/* supported block size */
>>> +	/* supported block sizes:
>>> +	 *   - lower limit is A2DP codec size
>>> +	 *   - total buffer size is the upper limit (with two periods) */
>>>  	err = snd_pcm_ioplug_set_param_minmax(io,
> SND_PCM_IOPLUG_HW_PERIOD_BYTES,
> [...]
>>> +	/* supported buffer sizes */
>>> +	err = snd_pcm_ioplug_set_param_minmax(io,
> SND_PCM_IOPLUG_HW_BUFFER_BYTES,
>>> +					      MIN_BUFFER_SIZE,
> MAX_BUFFER_SIZE);
>>>  	if (err < 0)
>>>  		return err;
>>
>> This part of the code is useless, you don't need to set 
>> SND_PCM_IOPLUG_HW_BUFFER_BYTES if you set 
>> SND_PCM_IOPLUG_HW_PERIODS, you just have to choose one of the 
>> two alternatives :-)
> 
> But if we'd drop setting mimax for BUFFER_BYTES, the application could 
> request for 64 periods of size 'MAX_BUFFER_SIZE / 2' -> 524288 bytes.
> Of course we could fix this by limiting the max period size, but then 
> the application couldn't use a buffering setup of two max-sized periods
> (good for robust playback). If we'd limit the max count of periods, 
> application couldn't choose a buffering setup of lots of small 
> buffer fragments (good for robust recording with minimal latency).
> 
> So defining a minmax range for all three params gives more
> flexibility without requiring any added logic to the plugin
> code.

That's definately a good answer :-).
Maybe we should drop SND_PCM_IOPLUG_HW_PERIODS and keep 
SND_PCM_IOPLUG_HW_BUFFER_BYTES only then ?

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