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. Ah, yes, that's a more elegant solution. > 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. I don't think such an extension is needed so far. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
