[alsa-devel] more on appl_ptr and DMA overrun at end of stream

[Takashi Iwai]

At Fri, 22 May 2009 09:07:43 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Fri, 22 May 2009, Takashi Iwai wrote:
> 
> > At Thu, 21 May 2009 14:44:27 -0400,
> > Jon Smirl wrote:
> >>
> >> I've been reading Lennart's article on glitch free audio....
> >>
> >> On my scatter/gather DMA hardware I generate an interrupt at the end
> >> of each period. On the last period this causes ALSA to issue a
> >> trigger(STOP). However, there is a latency from when that interrupt is
> >> generated and when ALSA does the trigger(STOP). During that latency my
> >> hardware starts playing the next buffer (which contains stale data).
> >> Playing stale data causes a noise burst. I fixed this by programming
> >> my DMA hardware to not overrun appl_ptr.
> >>
> >> There's another solution. ALSA already knows the stream ends
> >> mid-period and pads out the partial period with silence. If it simply
> >> padded out the next period with silence too the overrun problem would
> >> become non-audible and there would time to process trigger(STOP).
> >>
> >> If padding out two periods at end of stream is possible, it then
> >> becomes possible for me to turn off interrupts in my audio driver.
> >
> > This can be another interesting feature.  For example, you could add
> > a soft-mute padding to avoid a click noise at the end instead of a
> > whole silence.
> >
> > But, this kind of hack really depends on the hardware implementation.
> > If a hardware has no DMA but require explicit writes, adding two
> > periods is too much.  Just a few samples would be enough.
> 
> I agree to leave such things to lowlevel drivers.
> 
> > Or, in the case of normal PCI DMA transfer, how can it be stopped?
> > That is, the stream is still running although it's claimed to be
> > stopped.  If a period size is big (say over one second), the stop at
> > the next interrupt doesn't sound good.
> 
> I would suggest to improve drain() logic in kernel with
> snd_pcm_update_hw_ptr() calls and using proper timeouts for 
> schedule_timeout().
> 
> Note that this situation were handled with dead and removed pcm tick API - 
> although it required assistance (setup) from application.

... and, the results was no one used it :)
Apps don't want to set up such details at all -- that's the lesson
we had to learn...


Takashi