Subject: Re: [linux-audio-dev] Non preemptive driver layer in linux?
From: Dustin Barlow (dbarlow_AT_omnids.com)
Date: Fri Jun 23 2000 - 09:07:16 EEST
> If these problems are fixed, you can get performance latency as good
> as Reality does by running a program with SCHED_FIFO priority, which
> basically says "whenever this task is ready to run, run it no matter
> what". It doesn't get rid of "preemption" in the sense of interrupt
> handling still interrupting execution flow, but it does get rid of it
> in the sense that no other process will get the processor unless the
> SCHED_FIFO one blocks (waiting for I/O, for example).
So I assume that the Windows driver layer is also not purely non-preemptive
"in the sense" that it must also deal with interrupts to execution flow at
that level as well? I know you can set priority levels on threads in Win32.
How does this brute force approach to keeping the processors attention in
Win32 differ from a SCHED_FIFO in linux or at the driver/kernel level in
Windows?
> Note that this does NOT involve putting the synth code into the
> kernel, as Seer did. There is absolutely no reason to do what Seer did
> on a properly designed OS. You can bet that if they ever release
> Reality for BeOS, it will not operate in the same way as under
> Windows. The same logic applies to Linux, at least if it has the
> required patches.
I was wondering about that very thing. I had figured that it was Seer's
attempt to patch Windows faulty design, and I believe you have confirmed
this. I guess the folks at Seer do deserve some praise for taking the time
design it the best they could with the platform (ie Windows) they decided to
use. It would seem to me that the other "real-time" synth vendors seem to
be waiting for faster processors to mask their complete acceptance of
Windows Win32/DirectX design.
So do you have some inside scoup on them releasing a version of Reality for
BeOS? :}
~Db
This archive was generated by hypermail 2b28 : Fri Jun 23 2000 - 09:24:36 EEST