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

[Takashi Iwai]

At Fri, 22 May 2009 09:58:29 -0400,
Jon Smirl wrote:
> 
> On Fri, May 22, 2009 at 3:14 AM, Takashi Iwai <tiwai at suse.de> wrote:
> > 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.
> 
> The core problem is that the lowlevel driver does not have sufficient
> information to know where the end of stream is.

Yes.  In other words, it's because of the current code flow in ISR as
I pointed.  Issuing trigger(STOP) after queuing is simply stupid, if
we know beforehand that the stream will be stopped anyway...


Takashi