All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.