The ideal scheduler for realtime apps would be one that has an api that allows for a call like "schedule me at exactly 10ms intervals+-1ms".
no, thats not true.
the system clock does not run in sync with the sample clock. the drift in this would become noticeable in a few minutes.
I know that. I was saying that we should be able to use the sample clock in scheduling descisions as well as the system clock, but as you say, for sound, we don't really care about the sample clock, only the interrupt that happens as a result.
It would still be nice to have a system clock based interval process for applications that require activity at specific intervals, but are not to do with sound or video.
the only time to run an audio app is ASAP after the interrupt from the device is recieved (assuming minimum latency; there is a more involved, but still interrupt-driven deadline with non-minimal latency).
--p
An audio hardware interrupt can interrupt any process at any time.
Is there already a procedure in linux so that the interrupt_handler can cause the scheduler to select a particular process to run immeadiately after this interrupt_handler has finished?
I can see problems with the following setup: -
Audio interrupt occurs
Audio interrupt_handler finishes.
Audio user space process get control of CPU.
Some other interrupt occurs
Some other interrupt_handler informs the scheduler to run xyz process next.
Question: -
Which process should be run next?
Continue with the audio user space process, or start the new xyz process?
Cheers James
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
