|
|
| Line 7: |
Line 7: |
| JACK is an acronym for Jack Audio Connection Kit. It is a low latency audio server mainly utilized by pro audio software. | | JACK is an acronym for Jack Audio Connection Kit. It is a low latency audio server mainly utilized by pro audio software. |
|
| |
|
| {{Note|1=
| | For users that require low latency when running JACK, see the following [[Kernel/configs/realtime|kernel configuration guide]]. |
| This page needs cleanup. The following probably needs to go into it's own page on the wiki! (blatantly stolen from http://proaudio.tuxfamily.org/wiki/index.php?title=DAW_Digital_Audio_Workstation which is CC:BY:SA)}}
| |
| | |
| ===Instructions for 3.x Kernels===
| |
| | |
| With the current 3.x kernels series, we have one more possibility to get real-time operations to work: Control Groups, or cgroups in short. This method is not available with the rt-kernel.
| |
| | |
| For a general introduction, see [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups kernel documentation]. | |
| | |
| From it: "Control Groups provide a mechanism for aggregating/partitioning sets of tasks, and all their future children, into hierarchical groups with specialized behaviour."
| |
| | |
| This is exactly what the real-time patch is doing: it provides a mechanism for aggregating the audio tasks, and for attributing them a higher priority than the other tasks. The same (and much more) can be done with the Control Groups, this with any recent kernel.
| |
| | |
| On the long run, I think many of us will use a vanilla or gentoo kernel with an audio related cgroups set-up. But the rt kernel will remain in use, firstly because it has proven to be a good working solution, secondly because the developers of the rt patch will continue to experiment new solutions, and thirdly because cgroups adds a slight scheduling overhead, and some of us don't want it.
| |
| | |
| For a jack related explanation, see [http://trac.jackaudio.org/wiki/Cgroups Some notes on CGroups].
| |
| | |
| ====RT scheduling cpu bandwidth and cgroups====
| |
| In the kernel configuration, the minimal and sufficient cgroups set-up to get RT scheduling is:
| |
| | |
| General setup --->
| |
| [*] Control Group support --->
| |
| [*] Group CPU scheduler --->
| |
| [*] Group scheduling for SCHED_RR/FIFO
| |
| | |
| As you can see in its help, this last option will give us CONFIG_RT_GROUP_SCHED. With this, we get access to RT scheduling cpu bandwidth controlled via cgroups. The root cgroup has this setup correctly. Remember, RT operations is all about bandwidth allocation of resources, more bandwidth for some tasks imply less bandwidth and responsiveness for the others.
| |
| | |
| ====cgroups set-up====
| |
| | |
| We also need to install dev-libs/libcgroup, which provide tools and libraries to configure and manage kernel Control Groups.
| |
| | |
| emerge libcgroup
| |
| | |
| However when libcgroup is installed and the cgconfig service has been started, it creates a "sysdefault" cgroup and moves all tasks over there. The sysdefault group does not have RT bandwidth assigned to it. In this case jackd can not be started.
| |
| | |
| There are several methods to configure cgroups for our purpose ([http://trac.jackaudio.org/wiki/Cgroups Some notes on CGroups]).
| |
| I started with the method 2, but it was necessary to add a namespace section. In consequence, the following set-up is a mix of method 2 and 3.
| |
| | |
| Edit /etc/cgroups/cgconfig.conf as follow:
| |
| | |
| namespace {
| |
| cpu = /;
| |
| }
| |
|
| |
| group rtaudio {
| |
| perm {
| |
| task {
| |
| uid = root;
| |
| gid = audio;
| |
| }
| |
| admin {
| |
| uid = root;
| |
| gid = root;
| |
| }
| |
| }
| |
| cpu {
| |
| cpu.rt_runtime_us = 950000;
| |
| }
| |
| }
| |
| | |
| We create here a kernel cgroup named rtaudio. Root can manage it. The users in the audio group can use it. We use rtaudio to define the processor use of the RT processes. The members of the rtaudio cgroup (the RT threads of the programs which are member of rtaudio) can use the processor during 950000 us per second, the other tasks get the remaining time, 50000 us.
| |
| | |
| At that time, we need to explicitly add the programs that must get RT scheduling. For that, edit /etc/cgroups/cgrules.conf:
| |
| | |
| # One of the following line is needed for jack
| |
| #@audio:jackd cpu rtaudio/
| |
| @audio:jackdbus cpu rtaudio/
| |
| # Comment the 2 following lines if not using snd-aloop
| |
| @audio:alsa_in cpu rtaudio/
| |
| @audio:alsa_out cpu rtaudio/
| |
| # Add one line for each RT software
| |
| @audio:mplayer cpu rtaudio/
| |
| @audio:ardour cpu rtaudio/
| |
| @audio:jamin cpu rtaudio/
| |
| | |
| You must add one line per application you want to be in the rtaudio cgroup. In the future, jack will provide a mechanism to move the RT threads of its clients into the cgroup of jackd.
| |
| | |
| We must configure PAM in /etc/security/limits.conf:
| |
| @audio - rtprio 99
| |
| @audio - memlock unlimited
| |
| | |
| Starting cgroups with our configuration:
| |
| # /etc/init.d/cgred start
| |
| * Starting cgconfig service ... [ ok ]
| |
| * Starting CGroup Rules Engine Daemon ... [ ok ]
| |
| | |
| Only the new processes will be managed by cgroups. It is best to start it at boot time:
| |
| rc-update add cgred default
| |
| | |
| ====Testing cgroups====
| |
| To test your set-up, you can use the 2 following small scripts, findrtp and findrtt.
| |
| | |
| findrtt will output the running programs which are member of rtaudio. findrtt will output all their threads.
| |
| | |
| findrtp
| |
| | |
| #!/bin/sh
| |
| for i in `cat /sys/fs/cgroup/cpu//rtaudio/cgroup.procs`;
| |
| do echo "Found pid $i which correspond at `cat /proc/$i/cmdline`";
| |
| done
| |
| | |
| and
| |
| | |
| findrtt
| |
| | |
| #!/bin/sh
| |
| for i in `cat /sys/fs/cgroup/cpu//rtaudio/tasks`;
| |
| do echo "Find pid $i which correspond to `cat /proc/$i/cmdline`";
| |
| done
| |
| | |
| Save them in your path and make them executable.
| |
| | |
| Run them:
| |
| # findrtp
| |
| Trouvé le pid 1846 qui correspond à /usr/bin/jackdbusauto
| |
| Trouvé le pid 2123 qui correspond à /usr/bin/alsa_out-jploop-dploop-q1
| |
| Trouvé le pid 2124 qui correspond à /usr/bin/alsa_in-jcloop-dcloop-q1
| |
| Trouvé le pid 2162 qui correspond à timidity-iA-B2,8-Oj-EFreverb=0-s48000
| |
| Trouvé le pid 2259 qui correspond à mplayerdvb://2@
| |
| | |
| # findrtt
| |
| Trouvé le pid 1846 qui correspond à /usr/bin/jackdbusauto
| |
| Trouvé le pid 2116 qui correspond à /usr/bin/jackdbusauto
| |
| Trouvé le pid 2117 qui correspond à /usr/bin/jackdbusauto
| |
| Trouvé le pid 2118 qui correspond à /usr/bin/jackdbusauto
| |
| Trouvé le pid 2119 qui correspond à /usr/bin/jackdbusauto
| |
| Trouvé le pid 2123 qui correspond à /usr/bin/alsa_out-jploop-dploop-q1
| |
| Trouvé le pid 2124 qui correspond à /usr/bin/alsa_in-jcloop-dcloop-q1
| |
| Trouvé le pid 2128 qui correspond à /usr/bin/alsa_out-jploop-dploop-q1
| |
| Trouvé le pid 2129 qui correspond à /usr/bin/alsa_out-jploop-dploop-q1
| |
| Trouvé le pid 2130 qui correspond à /usr/bin/alsa_out-jploop-dploop-q1
| |
| Trouvé le pid 2131 qui correspond à /usr/bin/alsa_in-jcloop-dcloop-q1
| |
| Trouvé le pid 2162 qui correspond à timidity-iA-B2,8-Oj-EFreverb=0-s48000
| |
| Trouvé le pid 2170 qui correspond à timidity-iA-B2,8-Oj-EFreverb=0-s48000
| |
| Trouvé le pid 2171 qui correspond à timidity-iA-B2,8-Oj-EFreverb=0-s48000
| |
| Trouvé le pid 2172 qui correspond à timidity-iA-B2,8-Oj-EFreverb=0-s48000
| |
| Trouvé le pid 2259 qui correspond à mplayerdvb://2@
| |
| Trouvé le pid 2339 qui correspond à mplayerdvb://2@
| |
| Trouvé le pid 2340 qui correspond à mplayerdvb://2@
| |
| Trouvé le pid 2341 qui correspond à mplayerdvb://2@
| |
| | |
| To see which threads are RT, we can use ps:
| |
| ps -eLo rtprio,pri,cgroup,class,pid,pcpu,%mem,user,comm --sort pri|less
| |
| RTPRIO PRI CGROUP CLS PID %CPU %MEM USER COMMAND
| |
| ...
| |
| - 19 2:cpu:/rtaudio TS 2613 0.0 1.0 dom jackdbus
| |
| - 19 2:cpu:/rtaudio TS 2613 0.0 1.0 dom jackdbus
| |
| - 19 2:cpu:/rtaudio TS 2613 0.0 1.0 dom jackdbus
| |
| 10 50 2:cpu:/rtaudio FF 2613 0.4 1.0 dom jackdbus
| |
| - 19 2:cpu:/rtaudio TS 2613 0.0 1.0 dom jackdbus
| |
| ...
| |
| - 19 2:cpu:/rtaudio TS 3642 0.0 1.0 dom alsa_out
| |
| - 19 2:cpu:/rtaudio TS 3642 0.0 1.0 dom alsa_out
| |
| - 19 2:cpu:/rtaudio TS 3642 0.0 1.0 dom alsa_out
| |
| 5 45 2:cpu:/rtaudio FF 3642 0.5 1.0 dom alsa_out
| |
| - 19 2:cpu:/rtaudio TS 3643 0.0 1.0 dom alsa_in
| |
| - 19 2:cpu:/rtaudio TS 3643 0.0 1.0 dom alsa_in
| |
| - 19 2:cpu:/rtaudio TS 3643 0.0 1.0 dom alsa_in
| |
| 5 45 2:cpu:/rtaudio FF 3643 0.5 1.0 dom alsa_in
| |
| - 19 2:cpu:/rtaudio TS 3664 0.0 1.3 dom timidity
| |
| - 19 2:cpu:/rtaudio TS 3664 0.0 1.3 dom timidity
| |
| - 19 2:cpu:/rtaudio TS 3664 0.0 1.3 dom timidity
| |
| 5 45 2:cpu:/rtaudio FF 3664 0.0 1.3 dom timidity
| |
| - 19 2:cpu:/rtaudio TS 30170 6.1 1.4 dom mplayer
| |
| - 19 2:cpu:/rtaudio TS 30170 0.0 1.4 dom mplayer
| |
| - 19 2:cpu:/rtaudio TS 30170 0.0 1.4 dom mplayer
| |
| 5 45 2:cpu:/rtaudio FF 30170 0.1 1.4 dom mplayer
| |
| | |
| The FF threads are the real-time ones. We will see the same result with htop, but with other priority numbers (I prefer htop).
| |
| | |
| Another test is to lower jack latency. Run qjackctl and play with the parameters. With the Control Groups, I can lower jack latency with the gentoo-sources from 42,7 msec (1024 Frames/Period, 48kHz, 2 Periods/Buffer) to 0,667 msec (16 Frames/Period) without more xruns (only at applications start-up), which is as good as with the rt-sources.
| |
| {{EbuildFooter}} | | {{EbuildFooter}} |
