Re: [LAU] audio configuration for ulatencyd

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

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Feb 14 20:15:03 2011