[alsa-devel] Writing a DMA-less PCM audio driver

[David Jander]

On Tue, 18 Oct 2011 20:16:20 +0200
Jaroslav Kysela <perex at perex.cz> wrote:

> Date 18.10.2011 17:56, David Jander wrote:
> > 
> > Hi all,
> > 
> > I am writing a PCM audio driver for a piece of (embedded) hardware that
> > has no DMA, only a FIFO capable of holding 2048 samples. I was trying to
> > use a kthread with high realtime (SCHED_FIFO) priority to keep the FIFO
> > filled, and sleep with schedule_timeout(x), where "x" is depending on the
> > current FIFO fill level. The same thread also calls
> > snd_pcm_period_elapsed() on every completed period. It seems to work, but
> > I get sporadic audio skips and I am trying to figure out where they come
> > from. Most of the time schedule_timeout(1) takes almost exactly 1ms (1
> > jiffy at HZ=1000) to complete, but sometimes it takes up to 30ms. It seems
> > related to file-IO (via NFS) happening on the system, but the effect is
> > far bigger if the program that is playing the audio (mplayer) itself is
> > producing file-IO. When using a large cache parameter on mplayer
> > (effectively preloading the entire MP3 file into RAM), the problem is
> > almost gone. Before deciding whether I should debug the network driver to
> > see if it could produce such tremendous amounts of latency, is there a
> > better way to solve this problem? Are there any other DMA-less audio
> > drivers I could look at as an example?
> > Any suggestion is welcome.
> 
> Any pure PCMCIA driver has to handle FIFOs (see the sound/pcmcia tree).
> They use hardware interrupts for a better timing.

Thanks for the pointer. What I don't fully understand is why on a fully
preemptive kernel a threaded interrupt or a tasklet scheduled from an interrupt
handler would work better than a SCHED_FIFO kthread calling
schedule_timeout(1) in a loop for example. Beats me. I am going to try out
this approach and see if it works better.

Best regards,

-- 
David Jander
Protonic Holland.