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.