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

[Jaroslav Kysela]

On Fri, 13 Jun 2008, Takashi Iwai wrote:

> > >     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...

This value should define maximum latency - not actual latency. 
snd_pcm_delay() should give actual overall latency to apps.

> > 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.)

It look like more complicated sleep_min implementation we already had:

http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=31e8960b35975ed235d283d6fb95d0e28dffded0

						Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.