14 Feb
2011
14 Feb
'11
3:15 p.m.
Hi Daniel,
On 02/14/2011 12:29 PM, Daniel Poelzleithner wrote:
Hi,
I'm the developer of ulatencyd[1], a dynamic system optimizer for the
linux kernel.
I want to write a configuration that suits hifi audio usage better then
the default configuration. The default optimizes for normal workloads,
restrains amok running processes, gives priority to the active running
program, the window manager and desktop ui.
One problem I was facing is realtime tasks. Currently only two programs
are allowed to get rt priority, thats jackd and pulseaudio. I don't know
of any other that a normal user may use.
The default configuration looks like this:
https://github.com/poelzi/ulatencyd/blob/master/rules/scheduler_desktop.lua
jackd and pulseaudio go into users bg_high group which has 1/3 of the
users cpu share time and max 45% cpu realtime, which should be enough
for normal workload.
I don't think this is acceptable for professional audio. I suggest 1/1
of user's CPU share and max 99% CPU realtime. more: see below.
Normal processes, that are not caught specially are
grouped into groups,
using the pgrp process value. ( to workaround bad ui behaviour like kde
& gnome this value can be overridden by rules. Usually all programs
started get a group and all children of them end in the same group.)
I guess you guys need something different.
• do you a lot of rt tasks besides pulseaudio and jackd ?
All the audio-interface related IRQ tasks (on PREEMPT RT - e.g.
sirq-hrtimer, sirq-timer and irq/18-uhci_hcd, irq/17-ohci1394,
irq/28-hda_inte,.. etc - but they're inside the kernel and may not need
special attention from ulatencyd)
All processes/threads that inherit the RT privileges from JACK.
There may be a few ALSA-midi clients (no JACK) that try to acquire RT
scheduling but I can't think of any just now. Oh, and cdrdao (mastering
audio to CD) likes to have RT privileges.
AFAICT, the majority use professional LA users is not using pulseaudio
at all.
• do they need a lot of cpu time ? is 45% not enough
for jackd/pulseaudio ?
What is the reason behind 45% ? Wouldn't 99% make more sense? just use
the bare minimum to prevent the system from locking up. Am I missing
something there?
Why would I buy a fast multi-core CPU to have 55% of it just idling on
stage, during a performance or in a studio? Some headroom is fine, but
why restrict the box?
FWIW: I sometimes bump into 50-90 %CPU load (actually ~160% on a dual
core or ~300% on quad core) by running jammin, multiple jconvolvers or
occasional foo-yc20.
• would it be better to just put everything into one
cgroup instead of
many smaller groups ? maybe just make exceptions for ui apps and the
rest into one group ?
In order to come to a conclusion of "what is better". Could you please
outline advantages/disadvantages of each approach?
There are other neat things that could be done:
• move all away from one processor and move jackd for example on it,
giving him lowest latency possible. ok, not perfect as the kernel may
still use this cpu. But interrupts can also be masked on the core.
That would void the parallel execution of jack2 and tschack graphs,
wouldn't it? The main JACK-process is not CPU heavy: it's the JACK
client's threads that cause the CPU load.
• maybe changing /proc/sys/kernel/sched_latency_ns
will help
As you can see, there is a lot that can be done. As I'm not doing audio,
I really would like to get some requirements from users first, or even
better. Someone with insights is writing the configuration/rules. I will
be glad to assist :-)
kind regards
daniel
[1] https://github.com/poelzi/ulatencyd
many thanks for bringing this up!
Cheers!
robin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user