[alsa-devel] What does snd_pcm_delay() actually return?
tiwai at suse.de
Fri Jun 13 17:59:52 CEST 2008
At Fri, 13 Jun 2008 17:44:24 +0200 (CEST),
Jaroslav Kysela wrote:
> 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:
Yes and no. Yes, it updates with a system timer. No, it's not bound
with the period like the current framework.
The point is that the wake-up timing isn't defined as constant but via
a timing queue (or a request queue). This is more suitable for
pull-style apps like JACK. Which irq source is used doesn't matter.
More information about the Alsa-devel