>Maybe we want a special 'multimedia' scheduling mode with these
>properties:
>- - able to ask for rescheduling on RTC interrupts
>- - CPU time is twice as expensive
>- - priority is higher, but the process gets less CPU to hog
>
>This way, multimedia programmers are encouraged to code
>their program with one 'worker' thread and one 'output'
>thread -- with some buffering in between to catch most
>I/O delays etc...
the buffering is the heart of the problem. some of us would like to
use linux in real time music performance situations (*). that means i want
to be able to twiddle some feature of a MIDI instrument, and get the
relevant audio output soon enough that if i'm working with other
people whose instruments are *not* routed through my computer, we
sound in sync with each other.
this means not much more than 5-10ms of buffering. by linux standards,
this is rather small, and in fact, would still be considered a delay
with a distinct name (flanging) in the audio world.
>For real RT or low-latency work, you will need to work
>on an unloaded computer anyway.
very true, but you still have to work like crazy to get linux to
cooperate with such low latency goals. ensuring that different i/o
subsystems do not block each other (e.g. disk, audio, serial port,
parallel port) will go a long way to helping this problem.
--p
(*) partly because it won't crash in the middle of a performance, and
partly because its a great platform for developing interesting
software on.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/