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