At Fri, 22 May 2009 09:58:29 -0400, Jon Smirl wrote: > > On Fri, May 22, 2009 at 3:14 AM, Takashi Iwai <tiwai@xxxxxxx> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
