Re: appl_ptr and DMA overrun at end of stream

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 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).

 						Jaroslav

-----
Jaroslav Kysela <perex@xxxxxxxx>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux