[LAU] audio configuration for ulatencyd

[Robin Gareus]

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 at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user