[alsa-devel] What does snd_pcm_delay() actually return?
perex at perex.cz
Fri Jun 13 17:44:24 CEST 2008
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:
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
More information about the Alsa-devel