[alsa-devel] Alsa timing question

Raymond Toy rtoy at google.com
Fri Aug 26 17:56:57 CEST 2011

On Fri, Aug 26, 2011 at 1:29 AM, Olivier Guillion - Myriad <
olivier at myriad-online.com> wrote:

> Hi,
> Raymond Toy wrote:
> > > > I'm working on an application where I'd like to have relatively fixed
> > > timing
> > > > between calls to snd_pcm_writei.
> > >
> > > Why?
> > >
> >
> > It's a bit complicated.  A different process generates the audio and
> places the
> > data in a shared memory area.  My process sends signals the other process
> to
> > generate more data, I read the shared memory area (for the previously
> generated
> > data).  Sometime later, the other process fills the shared area with new
> > samples.  Thus, if the timing between calls is not fairly regular, I'll
> either
> > reread the same data or miss the new data.  (I'm not in control of how
> this
> > works.  I just have to deal with what I'm given.)
> IMO, it's not a good idea to try to synchronize perfectly two processes by
> way
> of an interrupt.
> If the generating process has to remain untouched, you should probably
> bufferize its data in your own process before sending it to writei. It
> would
> add some latency, but make the data flow safer.
> Here is how it could work:
> 1- Your process writes a "magic" pattern at the end of the shared area
> 2- It sends a signal to the other process to make it generate data
> 3- It checks whether the magic pattern is still here
> 4- When changed, it means the data have been calculated. It saves them to
> an
> internal circular buffer

A nice idea, but I'm not sure it will work in my scenario.  The "magic"
pattern could potentially be real data (the buffer contains audio samples),
so that would cause funny, hard-to-reproduce glitches.  Plus, I think that
when I request new data, something is always written.

Clemens idea of a counter at the beginning of the buffer would work nicely,
but requires changes in the generating process.



More information about the Alsa-devel mailing list