At Mon, 11 May 2009 14:00:59 -0400, Jon Smirl wrote: > > On Mon, May 11, 2009 at 1:37 PM, Jaroslav Kysela <perex@xxxxxxxx> wrote: > > On Mon, 11 May 2009, Jon Smirl wrote: > > > >> Checking for over/under run in software is not reliable since the DMA > >> hardware runs asynchronously with the CPU. There will always be > >> variable latencies between when the CPU detects the condition and when > >> it can control the DMA hardware. The only reliable way to do this is > >> to program the DMA hardware to do itself. AFAIK all DMA modern > >> hardware can be programed to do this if the right information is made > >> available. Programming the DMA hardware to do this is a 100% reliable > >> solution and not subject to random latency problems. > > > > I comment playback for simplicity. > > > > The key point is when you fill DMA engine. Nothing forces you to queue whole > > ring buffer in the scatter-gather list. You may queue just one period and > > then next one (including partial). The available samples can be determined > > using snd_pcm_playback_hw_avail() function at any time. If you have large > > I didn't know about this function. I can use it to replace the direct > manipulation of appl_ptr. Well, this computes a value between appl_ptr and hw_ptr. That is, it relies on the current hw_ptr value. Just to make sure... > > FIFO and you receive interrupt before FIFO goes empty, you can fill partial > > period. The elapsed notifier does not require any change. > > > > The underruns should be avoided as first step, because it's really unwanted > > system behaviour. All methods to fix underruns fails in some respects. > > > > Also note that we have also mode when appl_ptr is not updated at all (when > > stop_threshold == boundary). > > How does this mode work? Could it be hidden inside > snd_pcm_playback_hw_avail() such that low level drivers don't have to > worry about it? Hm, no, in this case, it won't work properly. *_avail() simply tells you a bogus value, even a negative one. Basically this is a free-wheeling mode, e.g. used by dmix. In this mode, you simply ignore appl_ptr but assume that period_size samples are available at each period update. So, this would be a different implementation. I don't know whether this mode has to be implemented for the hardware like yours. I feel it's better to avoid the free-wheel mode by some condition (a new pcm_info flag?) thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
