[alsa-devel] [PATCH 3/3] ASoC: omap-mcbsp: Add period size protection mode

[Grazvydas Ignotas]

On Tue, Mar 20, 2012 at 6:20 PM, Jarkko Nikula <jarkko.nikula at bitmer.com> wrote:
> On 03/20/2012 01:13 PM, Peter Ujfalusi wrote:
>> Certain application can experience underrun right after the playback start.
>> This is caused by the McBSP FIFO/sDMA integration:
>> The sDMA will push samples to the FIFO till it has threshold amount of free
>> slots available in the FIFO. If the application picks period size which is
>> smaller than the FIFO size, and it did not prepared multiple periods, or
>> it did not set the start_threshold for the stream to cover the FIFO size
>> the hw pointer will move forward, which is causing the underrun.
>>
>> Add a sysfs entry for McBSP ports: period_protection.
>> If this property is set the driver will place the constraint agains the
>> period size, and not for the buffer size. To ensure that we do not hit
>> underrun, the period size constraint will be increased with the requested
>> number of frames (the period size will be FIFO size + period_protection).
>>
>> As default the period_protection is disabled.
>>
> I don't think this is going to solve the actual problem here where
> custom asound.conf was required. IMHO custom sysfs is even worse option
> and very hard to remove afterwards. And defaulting this new setting for
> Pandora might break e.g. MER or MeeGo on N900.
>
> I didn't check this but would it be possible to either put restriction
> to start-delay (I think Grazvydas said he has experimental code for
> that?) or make sure that minimum buffer size must be higher than FIFO +
> 1 period (or something like that)?

This is what we have in pandora tree now:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=d494977441ac8f99d094b5e03398cb33a14e832a
Seems to work well for everything here.

-- 
Gražvydas