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. > 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? > > Jaroslav > > ----- > Jaroslav Kysela <perex@xxxxxxxx> > Linux Kernel Sound Maintainer > ALSA Project, Red Hat, Inc. > > -- Jon Smirl jonsmirl@xxxxxxxxx _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
