[alsa-devel] [PATCH v3 1/3] ASoC: davinci-mcasp: Constraint on the period and buffer size based on FIFO usage
peter.ujfalusi at ti.com
Thu Mar 20 14:47:06 CET 2014
On 03/19/2014 03:14 PM, Mark Brown wrote:
> On Wed, Mar 19, 2014 at 01:13:50PM +0200, Peter Ujfalusi wrote:
>> On 03/18/2014 08:07 PM, Mark Brown wrote:
>>> OK, so is the patch an improvement or not? If it fixes some cases it's
>>> probably worth applying even if further fixes are still needed.
>> Some application might fail (like mplayer with 44.1KHz) with constraint on the
>> period size only. Without the constraint we will have constant pops at every
>> period when non aligned size has been selected - if the FIFO depth is
>> configured to more than 1, which is not yet the case in upstream.
> OK, given that the FIFO depth change isn't yet upstream it'd be a step
> backwards so I'll leave this for now.
I have looked at the issue and I found some clues on why mplayer fails:
it try to set the snd_pcm_hw_params_set_buffer_time_near() first followed by
the snd_pcm_hw_params_set_periods_near(). And this fails in some cases when we
have constraint step on the period only.
Other applications set the period param first followed by the buffer (aplay
and various alsa test tools as well).
PA however have a fallback mechanism:
1. buffer first followed by period
2. period first followed by buffer
3. buffer only
4. period only
5. no period, no buffer params
When I have step constraint on period PA fails with the first, second (because
there's a bug in the PA code here) and third method but going to succeed with
I have looked around in the kernel and other drivers do set both period and
buffer step constraint, for example:
I still don't know why buffer size fails (in some cases) if we only have step
constraint on the period size, but it looks to me that others also encountered
with similar issues and the fix they have is the same what I had in the first
version of the patch.
More information about the Alsa-devel