Difference between revisions of "Package:JACK Audio Connection Kit"

m (Drobbins moved page Package:Jack to Package:JACK Audio Connection Kit without leaving a redirect)
Line 1: Line 1:
 
{{Ebuild
 
{{Ebuild
|Summary=A low-latency audio server.
+
|Summary=A sophisticated audio routing and mixing application.  
 
|CatPkg=media-sound/jack-audio-connection-kit
 
|CatPkg=media-sound/jack-audio-connection-kit
 
|Maintainer=
 
|Maintainer=

Revision as of 21:21, November 27, 2014

media-sound/jack-audio-connection-kit


Source Repository:Gentoo Portage Tree
Homepage

Summary: A sophisticated audio routing and mixing application.

Use Flags

coreaudio
Build the CoreAudio driver on Mac OS X systems
cpudetection
Enables runtime cpudetection
pam
Add basic realime configuration via sys-auth/realtime-base

JACK Audio Connection Kit

JACK

JACK is an acronym for Jack Audio Connection Kit. It is a low latency audio server mainly utilized by pro audio software.

Note: 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 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 provide 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 have 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 add a slight scheduling overhead, and some of us don't want it.

For a jack related explanation, see 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 task imply less bandwidth and responsiveness for the other.

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.

It is several methods to configure cgroups for our purpose (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 chroups 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 one. 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 than with the rt-sources.