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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
