[alsa-devel] Driver code with mpc5200 pointer problem.

[Mark Brown]

On Tue, Apr 28, 2009 at 10:55:53AM +0200, Jaroslav Kysela wrote:
> On Mon, 27 Apr 2009, Mark Brown wrote:

>> Could you expand a bit on what qualifies as "too big" here?  I've not
>> been following the thread here or the changes that caused problems.

> The problem is that period_elapsed() callback checks if data are not  
> "consumed" (playback) or "produced" (capture) too quickly using jiffies  
> timing (with HZ/100 margin). In case of large FIFO, the data are  
> buffered, but the real playback position is different.

Right.  As I said in my excellently timed reply to Takashi just now this
is liable to cause problems for some embedded applications.  There are
some which can use a large (tens to hundreds of kilobytes) FIFO to allow
audio playback to proceed with the processor and RAM suspended, reducing
power consumption during things like MP3 playback which aren't latency
sensitive.  In latency sensitive cases the application needs to submit
less data - there's no requirement to fill.

> The question is, if driver's pointer function should estimate more real  
> stream position (taking in account the FIFO) in this case or if upper  
> layers of the ALSA driver and applications should handle the situation  
> using FIFO size value.

Or both, I guess.

> I would suggest this:

> - implement the stream position corrections in the pointer callback -
>   in this case applications get valid realtime timing source for
>   A/V synchronization etc. - in case of mpc driver, another timing
>   and interrupt source should be used to compute the pointer value not
>   DMA engine

This feels like it's being done at the wrong level - if estimation code
is needed it should probably be pushed up the stack, done based on
information provided by the driver about how accurate the information
it's providing is.