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@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Feb 14 16:15:02 2011
This archive was generated by hypermail 2.1.8 : Mon Feb 14 2011 - 16:15:02 EET