[alsa-devel] What does snd_pcm_delay() actually return?

Takashi Iwai tiwai at suse.de
Fri Jun 13 17:27:45 CEST 2008

At Fri, 13 Jun 2008 10:14:33 +0200 (CEST),
Jaroslav Kysela wrote:
> On Fri, 13 Jun 2008, Takashi Iwai wrote:
> > - Add some new API functions,
> I would prefer to extend the current API than to change meaning of hw_ptr 
> to handle extra latencies.
> >   * To give the accuracy of the position inquiry (optional)
> > 
> >     This requires some new kernel <-> user-space stuff.
> >   * To query the known latency
> > 
> >     Ditto, or we may reuse snd_pcm_hw_params_fifo_size()?
> Yes, fifo_size was designed to announce possible extra latency to 
> applications.

On the second thought, it's better *not* to query this value as
hw_params.  The latency may be variable.  And the word "FIFO" isn't
appropriate in every case.

And, above all, reviving an old API is bad...

> >   * To query the position being played (optionally)
> > 
> >     This can be simply hwptr + latency.
> > 
> > - Don't change snd_pcm_delay().  Keep as is now.
> > 
> > 
> > About the period model -- it's a bit more tough problem.
> > I once already made a patch to allow user-apps to use a system timer
> > for more flexible period settings.  But, it was for very old version
> > of ALSA.  Better to write from the scratch again...
> I think that the current PCM API concept is tightly period based. You 
> cannot change it easily. It would be probably better to move to 
> "byte-stream" in next revision of PCM API.

Not that difficult, I guess, from API POV.  The major work is in the
PCM core part and some alsa-lib plugins.  But, it's not API.

What I once worked on is an extra timinig queue.  Suppose that we
provide an API to access a timing queue that holds the wake-up
schedule, either in time or sample unit.  The poll / read / write
syscalls are woken up at the time of this schedule.  In the case of
period model, it means that the queue is automatically filled up with
a constant period.  If app wants to schedule by itself, it can use
this queue manually.  (Of course, this means that the timing queue
must be filled before starting the stream.)


More information about the Alsa-devel mailing list