Paul Davis wrote:
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