Re: Alsa timing question

[Clemens Ladisch <clemens@ladisch.de>]

Raymond Toy wrote:
> On Thu, Aug 25, 2011 at 12:15 AM, Clemens Ladisch <clemens@ladisch.de>wrote:
> > 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.

The obvious way to resolve this problem would be to add a signal from
the other process to your process.  Even a serial number in the shared
memory area would help detecting problems.

> (I'm not in control of how this works.  I just have to deal with what
> I'm given.)

"It is a vessel of fertilizer, and none may abide its strength."

> > > [...] I see is that most calls to snd_pcm_writei are spaced about 50 ms
> > > apart.  This makes some sense, but I was expecting the calls to be about
> > > 42.67 ms apart.  However, about every 6th call, the time is just 200 us
> > > or so.  Why is that?
> >
> > In theory, when the device is configured for a specific period size, its
> > interrupts (and therefore the application wakeups) will arrive spaced at
> > this interval (modulo any scheduling delays).
> >
> > However, if you're using the dmix plugin,

Your other mail shows you're using the PulseAudio plugin.

> > the period size of your application's device will not necessarily be
> > identical with the period size of the hardware device.

PulseAudio doesn't use period interrupts, it uses its own timer that,
apparently, runs at 50 ms.

In theory, you should use a period size that is an exact multiple of
50 ms, but in practice, this is not possible because the device's sample
clock is not synchronized with the computer's timer.

You could try to use, e.g.,  500 ms periods so that the inaccuracies of
PA's timer result in smaller relative jitter in your own timing, but
this will increase latency.

Try asking on the PA list how to get accurate period timing.


Regards,
Clemens