[LAU] audio configuration for ulatencyd

[Robin Gareus]

On 02/14/2011 04:33 PM, Daniel Poelzleithner wrote:
> On 02/14/2011 03:15 PM, Robin Gareus wrote:
>
>> All processes/threads that inherit the RT privileges from JACK.
> 
> Are these processes parent of jack or do they just connect to it ?

JACK sets up these threads, but they reside in the context of the client
app's process ID - which call jack_client_new().

> If these are only connected, how can i get a list of all pids in the graph ?

there was a recent discussion on jack-devel:
 http://comments.gmane.org/gmane.comp.audio.jackit/23110
also check the jack-devel archive starting December 15 2010:
 http://comments.gmane.org/gmane.comp.audio.jackit/22928

and http://trac.jackaudio.org/wiki/Cgroups might be helpful.

> do you have me same simple command i just can run that causes non
> trivial load on jackd and it's childs to test ?

The easiest is to start jackd and jamin. The latter sucks ~15%-50% CPU
alone (depending on your CPU freq). Tou can also start a few instances
of jamin.

http://rg42.org/gitweb/?p=jackfreqd.git;a=blob_plain;f=tools/busyjack.c
is a small tool that allows to generate JACK DSP and CPU load. Start a
few of them (depending on how many cores you have).

> of course. PA is for desktop usage, not pro audio :-)

hehe, my desktop - for example - also runs on JACK (+ alsa-plug for
flash etc).

>>> • 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?
> 
> each group has a cpu.shares value and a rt_runtime_us (along with other
> values).
> 
> cgroup_a cpu.shares 10:
>    task 1
>    task 2
> 
> cgroup_b cpu.shares 5:
>    task 3
>    task 4
> 
> imaging all 4 tasks want 100% cpu time, then in this setting task 1 & 2
> get 66% of the cpu time and task 3 & 4 get 33%.
> 
> if you put all in one group: very task gets the same cpu time.
> shares that are not used will always be given to other slots, so there
> is no disadvantage in giving a group a higher share.
> 
> finding good groups of processes is of course not a easy task to get
> right. the current grouping works very well for desktops.
> 
>>> 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.
> 
> i ment of course the complete graph. If you get like 4 cores, you move
> all processes to 1 core and use the 3 remaining cores to do audio only.

aww right /me slaps head.

Thanks for the explanation.
Let me comment on those later or tomorrow, I've got a train to catch.
maybe s.o. else (jack-devs: wink wink nudge nudge) can jump in..

> what about a configuration like this:
> 
> - rt_audio:   cpu.shares 3000 rt: 99%
> - desktop ui: cpu.shares 500 rt: 0
> - audio ui:    cpu.shares 2000 rt: 0
> - the rest:   cpu.shares 100  rt: 0
> 
> ?

looks like a good starting point to me.

> kind regards
>  daniel

Cheers!
robin