[alsa-devel] Writing a DMA-less PCM audio driver
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.
Best regards,
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.
Jaroslav
On Tue, 18 Oct 2011 20:16:20 +0200 Jaroslav Kysela perex@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,
On Tue, 18 Oct 2011 20:16:20 +0200 Jaroslav Kysela perex@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 a lot. That worked! I am keeping the FIFO filled on the alarm interrupt in the regular handler, and defer calling snd_pcm_period_elapsed() to the threaded handler. Rationale is that I may miss one call to snd_pcm_period_elapsed(), but never a FIFO underrun if things get too busy.
Best regards,
participants (2)
-
David Jander -
Jaroslav Kysela