At Mon, 11 May 2009 15:45:49 +0200 (CEST), Jaroslav Kysela wrote:
On Mon, 11 May 2009, Jon Smirl wrote:
Right. This is the value to check in your case.
What do think about redesigning the ALSA DMA interface to support detection of over and under run? Leaving the DMA engine in a loop and not coordinating with ALSA as to where the valid data is does not seem to be a safe way of exchanging data. That interface may be a source of the problems pulseaudio is encountering.
A simple solution would be for snd_pcm_period_elapsed() to return physical address of the last valid sample. That would let me avoid playing with s->runtime->control->appl_ptr. You could provide the same data in the pointer() function.
More simpler solution is to check the stream state in the low level driver. If it's in DRAINING state, then end of stream is signaled from the application and driver might not queue next buffer. We may also add another callback (or use ioctl callback) to pass this stream state change to the lowlevel driver immediately, so the driver might react more quickly on this situation.
BTW, regarding the PCM core implementation: one missing thing in the PCM core is a proper way of queuing before trigger(START) and a proper clean-up after trigger(STOP). Since the trigger callback is atomic (in the ALSA sense), it cannot take a long task.
For a long task like buffer-prefetching or DMA clean up, there might be a need for yet another callback, such as ops->pre_start() or ops->post_stop(), and call this before the spinlocked trigger calls. For example, pre_start should be used to send the available data (up to appl_ptr) to the hardware.
Just $0.02 as now, though.
Takashi