[linux-audio-dev] Linux Security Module for realtime audio

[Benno Senoner]

Paul Davis wrote:

>
>now, if the audio thread is burning so much CPU time that the GUI
>doesn't get to run, its certainly a problem. but step back - is it a
>problem you want to fix by raising the priority of the GUI thread so
>that it steals time from the audio thread? or even from a "disk
>butler" thread. no, i don't think so. it simply means that the user is
>asking too much from their current hardware (and/or that the s/w is
>badly implemented, but thats a different story).
>
Speaking about the disk butler thread, I don't know what kind of 
priority ardour's one uses
but in LinuxSampler we experienced weird behaviour when running the disk 
thread with
SCHED_FIFO/RR , even at low priorities.
The problem is the following: normally the disk thread calls read() to 
read data from disk and
since read() must wait for the disk I/O subsystems it often relinquishes 
the CPU and thus
is causing no problems to the other active processes.

But since in LinuxSampler we often hit a situation where most of the 
initial parts of each
sample (that is streamed from disk) gets cached by the linux disk i/o 
layer it means that
the read() call will very often read from the cache (thus doing a memory 
copy) instead from disk.
This is good because it avoids many unnecessary disk accesses (otherwise 
we would need
to write our own caching algorithm but since Linux works so well we used 
the kernel's one).
But there is a weird side effect that arises when the disk thread runs 
with real time priority.

Assume a not so fast CPU (with relatively low RAM bandwidth), when you 
play many notes
at the same time where most of the streams are cached (because your RAM 
is large enough to
cache most of the samples needed) then the disk thread will issue 
read()s that will almost everytime
translate to memory copying (from the disk cache to the userspace buffer).
This means a substantial chunk of CPU is used (eg 20-30%) by the disk 
thread to copy the data.
And since the disk thread is optimized to read() large segments from 
disk in order to maximize bandwidth,
it could happen that it read()s let's say 100 (# of voices) x 200KB of 
data = 20MB before going to sleep.
This could stall the machine for several dozen/hundreds msecs stalling 
GUIs and making the overall usage
of the machine sluggish.
This is why I now run the diskthread without real time privileges 
because if the above situation happens
it does not suck away precious CPU time (the disk thread always tries to 
refill all ringbuffers until they are completely
full but that is not strictly needed) making the box unresponsive.

So in conclusion I'd say: don't run your disk butlers SCHED_FIFO/RR but 
use nice(-10) or something alike.
Same for GUIs if you care about  reaction speed of the GUI run it 
nice(-10) because with nice you don't risk hogging
the machine because of a slow gfx card/drivers or because of a 
suboptimal redrawing implementation.

cheers,
Benno
http://www.linuxsampler.org