From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: alsa-devel@alsa-project.org,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Liam Girdwood <lrg@ti.com>, Grazvydas Ignotas <notasas@gmail.com>
Subject: Re: [PATCH 3/3] ASoC: omap-mcbsp: Add period size protection mode
Date: Wed, 21 Mar 2012 10:03:34 +0200 [thread overview]
Message-ID: <4F698B56.6030502@ti.com> (raw)
In-Reply-To: <4F68AE51.808@bitmer.com>
On 03/20/2012 06:20 PM, Jarkko Nikula 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.
I also suggested to use custom asound.conf. For Pandora it does exist,
but the argument was that it need to be specifically created/copied to
any new OS being ported to the HW.
> IMHO custom sysfs is even worse option and very hard to remove afterwards.
Well, for system integration's point of view I would prefer the sysfs
file. If this is needed by the distribution/use case it can be enabled,
disabled in runtime. In my view it poses less hassle for distributions.
> And defaulting this new setting for Pandora might break e.g. MER or MeeGo on N900.
I would not default this behavior for the exact same reasons. It was
planed to be optional.
> 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)?
The start_threshold is sw_param, driver should not touch it. In fact it
is way above the driver layer.
--
Péter
next prev parent reply other threads:[~2012-03-21 8:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 11:13 [PATCH 0/3] ASoC: omap-mcbsp: Constraint handling changes Peter Ujfalusi
2012-03-20 11:13 ` [PATCH 1/3] ASoC: omap-mcbsp: buffer size constraint only applies to playback stream Peter Ujfalusi
2012-03-20 15:26 ` Mark Brown
2012-03-20 16:34 ` Jarkko Nikula
2012-03-20 11:13 ` [PATCH 2/3] ASoC: omap-mcbsp: Restructure omap_mcbsp_dai_startup code Peter Ujfalusi
2012-03-20 15:27 ` Mark Brown
2012-03-20 11:13 ` [PATCH 3/3] ASoC: omap-mcbsp: Add period size protection mode Peter Ujfalusi
2012-03-20 16:01 ` Mark Brown
2012-03-20 16:15 ` Grazvydas Ignotas
2012-03-20 17:04 ` Mark Brown
2012-03-20 17:27 ` Grazvydas Ignotas
2012-03-20 18:07 ` Trent Piepho
2012-03-20 18:12 ` Mark Brown
2012-03-21 8:23 ` Peter Ujfalusi
2012-03-21 11:55 ` Grazvydas Ignotas
2012-03-20 16:20 ` Jarkko Nikula
2012-03-20 16:42 ` Grazvydas Ignotas
2012-03-20 19:20 ` Jarkko Nikula
2012-03-20 19:47 ` Trent Piepho
2012-03-21 7:57 ` Peter Ujfalusi
2012-03-21 8:13 ` Jarkko Nikula
2012-03-21 8:21 ` Peter Ujfalusi
2012-03-21 8:03 ` Peter Ujfalusi [this message]
2012-03-21 8:32 ` Jarkko Nikula
2012-03-21 8:40 ` Mark Brown
2012-03-21 9:16 ` Peter Ujfalusi
2012-03-21 9:34 ` Jarkko Nikula
2012-03-21 9:46 ` Peter Ujfalusi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F698B56.6030502@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=jarkko.nikula@bitmer.com \
--cc=lrg@ti.com \
--cc=notasas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.