Subject: [linux-audio-dev] using SCHED_FIFO threads (Was: Re: MuCoS, Glame, API Issues)
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe maalis 10 2000 - 08:36:51 EST
>> > > there are problems with scheduling multiple RT threads in low latency
>> > > settings (no preemptive/timesharing switching among SCHED_FIFO
>> > > threads), and some other things...
>> >
>> > RT threads are bad.
>>
>> No. They are *required* for certain tasks.
>
>Ok, lets lay for glame they're not an issue (right now) :)
As someone who has written several low latency, "real time" audio apps
for Linux, let me say that you *cannot* get "professional level" audio
performance from Linux without using SCHED_FIFO. This applies to any
situation other than playback from pre-recorded material. That covers:
FX processing, real time audio synthesis, user-space MIDI sequencing,
etc.
>> We're talking about *peak* latency here. Drop-outs are not acceptable
>> in a real time audio system, and the worst case scheduling latency of
>> the kernel can appear as frequently once per kernel call, if you have
>> too much bad luck. (Which happens all the time in a real system.)
>
>Well to prevent dropouts we do buffering. Of course the maximum buffer
>size determines the "peak" latency in the net.
Right, and if you want a system with peak latency of say, 5ms, so that
people used to ProTools, Event Systems, Paris and the rest will not
turn up their noses at you, then you *have* to use SCHED_FIFO and
small buffers.
>Hehe :) There's the 2 hours... - make it say 1ms and linux will not meet
>the criteria for hard realtime.
True, but make it 5ms and Linux *will* meet the criteria, and pretty
comfortably at that. I didn't believe that this was possible until
Benno pushed and pushed and Ingo Molnar took the pushing and converted
it into real improvements in the kernel.
--p
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST