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@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/listinfo/linux-audio-user _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
