At Thu, 14 May 2009 10:25:22 -0400, Jon Smirl wrote: > > On Thu, May 14, 2009 at 6:39 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: > > 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. > > Free-wheeling mode is basically unreliable. Wouldn't it be better to > start phasing dmix out in favor of pulseaudio? That's not what developers can decide. > Why is OSS still in the kernel? Why? It is designed so :) Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
