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

[Takashi Iwai]

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.


Takashi