[alsa-devel] [PATCH 3/3] ASoC: omap-mcbsp: Add period size protection mode
peter.ujfalusi at ti.com
Wed Mar 21 08:57:54 CET 2012
On 03/20/2012 09:47 PM, Trent Piepho wrote:
>> To me this looks more like a correct fix. At quick test I got single
>> xrun when starting up but not endless loop of them. Maybe need to tune a
>> bit with CONFIG_SND_PCM_XRUN_DEBUG=y.
> Does the ALSA API allow the driver to change start_threshold in the
> prepare function? It seems what is needed is a minimum
> start_threshold constraint, but there aren't constaints for sw_params.
I did as well looked at the start_threshold, and came to the same
conclusion. It is sw_param, and the driver should not modify it.
The OSS emulation layer sets the start_threshold to 1, most application
sets the start threshold to the size of the buffer. Some legacy
application might not care about this at all. Others might want specific
threshold to start the actual playback.
> With that fix, you could have an app set start_threshold to 50 ms,
> write 51 ms of audio, and expect the stream to start. But it won't,
> because the driver has increased start_threshold. The app could have
> read back start_threshold from the driver, but I doubt any apps do
> this, since there is nothing in the documentation about that being
True, it is a sw_param, and the applications does not expect it to be
changed by the driver (since the driver should not change it).
More information about the Alsa-devel