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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
