Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: David Jander <david.jander@protonic.nl>
To: Jaroslav Kysela <perex@perex.cz>
Cc: alsa-devel@alsa-project.org
Subject: Re: Writing a DMA-less PCM audio driver
Date: Thu, 20 Oct 2011 08:34:50 +0200	[thread overview]
Message-ID: <20111020083450.3544a9ce@archvile> (raw)
In-Reply-To: <4E9DC274.5040302@perex.cz>

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,

-- 
David Jander
Protonic Holland.

      parent reply	other threads:[~2011-10-20  6:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-18 15:56 Writing a DMA-less PCM audio driver David Jander
2011-10-18 18:16 ` Jaroslav Kysela
2011-10-19  6:18   ` David Jander
2011-10-20  6:34   ` David Jander [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111020083450.3544a9ce@archvile \
    --to=david.jander@protonic.nl \
    --cc=alsa-devel@alsa-project.org \
    --cc=perex@perex.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox