On Mon, 27 Apr 2009, Mark Brown wrote: > On Mon, Apr 27, 2009 at 05:09:27PM +0200, Jaroslav Kysela wrote: > >> Appearently, FIFO is too big. I'm working on some changes to take account >> fifo_size to the jiffies based check. Please, set fifo_size correctly in >> your driver. USB drivers with big "URB FIFOs" should be changed as well, >> too. > > 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. 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. 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 - leave current fifo_size without change (there will be only small FIFO values to notify applications about small extra delays before samples reaches DAC or leaves ADC) - add cache_size value to snd_pcm_hardware struct - here will be stored area of buffer which might be cached in the hardware for large FIFOs including prepared USB's URBs (the upper layer should not work with this buffer area - rewind operation etc.) Other ideas? Jaroslav ----- Jaroslav Kysela <perex@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
