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

[Takashi Iwai]

At Fri, 13 Jun 2008 18:38:53 +0200,
I wrote:
> 
> At Fri, 13 Jun 2008 18:20:43 +0200 (CEST),
> Jaroslav Kysela wrote:
> > 
> > On Fri, 13 Jun 2008, Takashi Iwai wrote:
> > 
> > > 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.
> > 
> > But applications can use timers or any other wakeup source directly (for 
> > example from video card interrupt) - thus I'm not sure if it's good to 
> > complicate our API, again. If we remove period tied I/O operations and 
> > assumptions in alsa-lib (thus we will do only byte-stream transfers), then 
> > everything will be fine and possible.
> > 
> > Other option is to create such timing queues separately as complete new 
> > API without integration to PCM API. Complex apps call poll() anyway. 
> > Support this complex timing for read()/write() for simple apps does not 
> > make much sense, I think.
> 
> Well, you miss the point.  Let me clarify some issues:
> 
>  - The timing queue is optional.  As default, we assume the period
>    model as is now.
> 
>  - The period model is internally driven as the automatic fill of
>    constant periods to the timing queue.
> 
>  - The stream is handled as a byte-stream.
> 
>  - If apps wants another wakeup source, it's fine.  This has nothing
>    to do with wakeup of the sound driver, no?  It's up to apps how to
>    handle streams.  We just provide the timing from our system.
> 
>  - What the timing queue affects is only the wake-up timing of
>    poll/read/write.  So, basically, no other API change is required
>    (although a simpler API with combination of queue+read/write would
>    be more helpful).
> 
>  - In my original implementation, periods become the sync points
>    between the hardware position and the system timer.  But, this can
>    be optional.

And one thing forgotten.

- If this were so great, I'd have already pushed to the upstream.
  But I didn't.  So you can guess that it's no perfect solution.


Takashi