Difference between pages "Video" and "Package:JACK Audio Connection Kit"

(Difference between pages)
m (link to Package:Nouveau_Video_Drivers_(Open_Source))
 
 
Line 1: Line 1:
The purpose of this page is to give you streamlined steps for setting up your video hardware for X, and desktop environments such as GNOME.
+
{{Ebuild
 +
|Summary=A sophisticated audio routing and mixing application.  
 +
|CatPkg=media-sound/jack-audio-connection-kit
 +
|Maintainer=
 +
|Homepage=http://www.jackaudio.org
 +
}}
 +
== JACK ==
  
{{Important|Editors: OK, I've decided to change the plans for this page. This is going to be a page similar to [[Subarches]]. The idea is to help people to identify their hardware and guide them toward the correct driver for their chipset. The focus will be primarily on defining the types of hardware that are supported, what products they appear in, and how to know if you have this hardware, and also give people good general overview of options available to them (free vs. proprietary, etc.) Other important topics that apply to all drivers, like <code>eselect opengl</code> should be covered as well. This will then serve as the meta-page for Video support, with individual ebuild pages holding the details for each driver.}}
+
JACK is an acronym for Jack Audio Connection Kit. It is a low latency audio server mainly utilized by pro audio software.
  
== Video Drivers ==
+
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)
  
First determine which video card you have and which driver it requires.
+
===Instructions for 3.x Kernels===
  
<console>###i## lspci -nn | grep -i vga</console>
+
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.
  
to see what your system is using:
+
For a general introduction, see [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups kernel documentation].
<console>###i## lspci -k</console>
+
  
Once hardware is determined use the following sections to add or edit the <code>VIDEO_CARDS</code> global variable in <code>/etc/portage/[[make.conf]]</code>.  For more granular details including kernel configurations, frame buffer settings, and xorg configurations: see specific package page links.
+
From it: "Control Groups provide a mechanism for aggregating/partitioning sets of tasks, and all their future children, into hierarchical groups with specialized behaviour."
  
=== AMD/ATI ===
+
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.
Users can choose between free ({{Package|x11-drivers/xf86-video-ati}}) and proprietary ({{Package|x11-drivers/ati-drivers}}) video drivers. The free drivers are recommended as the proprietary drivers are not currently maintained very well by AMD.
+
  
==== Cards ====
+
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.
* '''NEED TABLE''': available drivers, hardware gen, required VIDEO_CARDS variable
+
  
==== {{package|x11-drivers/xf86-video-ati}} ====
+
For a jack related explanation, see [http://trac.jackaudio.org/wiki/Cgroups Some notes on CGroups].
Open source drivers:
+
{{file|name=/etc/portage/make.conf|lang=|desc=set video global variable|body=
+
VIDEO_CARDS="radeon"
+
}}
+
  
==== {{Package|x11-drivers/ati-drivers}} ====
+
====RT scheduling cpu bandwidth and cgroups====
Closed source drivers:
+
In the kernel configuration, the minimal and sufficient cgroups set-up to get RT scheduling is:
{{file|name=/etc/portage/make.conf|lang=|desc=set video global variable|body=
+
VIDEO_CARDS="fglrx"
+
}}
+
  
=== Intel ===
+
General setup --->
==== Cards ====
+
        [*] Control Group support --->
* '''NEED TABLE''': available drivers, hardware gen, VIDEO_CARDS variable
+
                  [*] Group CPU scheduler --->
 +
                            [*] Group scheduling for SCHED_RR/FIFO
  
==== gen 1&2 ====
+
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.
{{file|name=/etc/portage/make.conf|lang=|desc=set video global variable|body=
+
VIDEO_CARDS="intel"
+
}}
+
  
==== gen 3 ====
+
====cgroups set-up====
{{file|name=/etc/portage/make.conf|lang=|desc=set video global variable|body=
+
VIDEO_CARDS="intel i915"
+
}}
+
  
==== gen 4+ ====
+
We also need to install dev-libs/libcgroup, which provide tools and libraries to configure and manage kernel Control Groups.
{{file|name=/etc/portage/make.conf|lang=|desc=set video global variable|body=
+
VIDEO_CARDS="intel i965"
+
}}
+
  
 +
emerge libcgroup
  
=== Nvidia ===
+
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.
Users can choose between Open (nouveau) and Closed-Source {{package|x11-drivers/nvidia-drivers}} video drivers. Open nouveau drivers are preferred as many kernels conflict with closed-source drivers.
+
  
==== Cards ====
+
It is several methods to configure cgroups for our purpose ([http://trac.jackaudio.org/wiki/Cgroups Some notes on CGroups]).
* '''NEED TABLE''': nouveau + nvidia-drivers versions, hardware gen, required VIDEO_CARDS variable
+
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.
  
==== {{Package|x11-drivers/xf86-video-nouveau}} ====
+
Edit /etc/cgroups/cgconfig.conf as follow:
Open source drivers:
+
{{file|name=/etc/portage/make.conf|lang=|desc=set video global variable|body=
+
VIDEO_CARDS="nouveau"
+
}}
+
  
==== {{Package|x11-drivers/nvidia-drivers}}====
+
namespace {
Closed source drivers:
+
cpu = /;
{{file|name=/etc/portage/make.conf|lang=|desc=set video global variable|body=
+
}
VIDEO_CARDS="nvidia"
+
}}
+
group rtaudio {
 +
perm {
 +
task {
 +
uid = root;
 +
gid = audio;
 +
}
 +
admin {
 +
uid = root;
 +
gid = root;
 +
}
 +
}
 +
cpu {
 +
cpu.rt_runtime_us = 950000;
 +
}
 +
}
  
see [[Uvesafb]] for framebuffering.
+
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.
  
=== Other ===
+
At that time, we need to explicitly add the programs that must get RT scheduling. For that, edit /etc/cgroups/cgrules.conf:
==== Multiple Cards (Hybrid Graphics) ====
+
 
recommended [[make.conf]] VIDEO_CARDS
+
# One of the following line is needed for jack
Hybrid intel/ati:
+
#@audio:jackd cpu rtaudio/
{{file|name=/etc/portage/make.conf|lang=|desc=set video global variable|body=
+
@audio:jackdbus  cpu rtaudio/
VIDEO_CARDS="fglrx intel"
+
# 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.
  
==== Virtual Machine Guests ====
+
We must configure PAM in /etc/security/limits.conf:
These settings are used by Parallels VM's and presumably others
+
@audio  -  rtprio    99
{{file|name=/etc/portage/make.conf|lang=|desc=set video global variable|body=
+
@audio  -  memlock    unlimited
VIDEO_CARDS="vesa vga"
+
 
}}
+
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.
  
==== Framebuffer Specific ====
+
findrtt will output the running programs which are member of rtaudio. findrtt will output all their threads.
=====[[Uvesafb]]=====
+
  
====={{package|x11-drivers/xf86-video-vesa}}=====
+
findrtp
  
==== Raspberry Pi ====
+
#!/bin/sh
{{SectionNeedsUpdates}}
+
for i in `cat /sys/fs/cgroup/cpu//rtaudio/cgroup.procs`;
 +
    do echo "Found pid $i which correspond at `cat /proc/$i/cmdline`";
 +
done
  
== Install ==
+
and
Once your video cards variables are set in [[make.conf]], and kernel configurations are arranged merge changes into your system:
+
  
<console>###i## emerge -avuND world</console>
+
findrtt
  
{{note|we should change world to the specific package that pulls in all the other video stuff so if this page is ran on an old stale system it doesn't pull in 50 bazillion packages}}
+
#!/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
  
==Configure X.org==
+
Save them in your path and make them executable.
===Nvidia===
+
nvidia-xconfig, etc.
+
  
===AMD/ATI===
+
Run them:
aticonfig, etc.
+
# findrtp
<console># ##i##aticonfig --initial --input=/etc/X11/xorg.conf</console>
+
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@
  
==Finalize and test==
+
# findrtt
==== eselect opengl ====
+
Trouvé le pid 1846 qui correspond à /usr/bin/jackdbusauto
{{note|change the number of card eselected to match the card of your system}}
+
Trouvé le pid 2116 qui correspond à /usr/bin/jackdbusauto
<console>###i## eselect opengl list
+
Trouvé le pid 2117 qui correspond à /usr/bin/jackdbusauto
###i## eselect opengl set 1</console>
+
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@
  
==== eselect opencl ====
+
To see which threads are RT, we can use ps:
{{note|some setups can make use of opencl}}
+
ps -eLo rtprio,pri,cgroup,class,pid,pcpu,%mem,user,comm --sort pri|less
<console>###i##eselect opencl list
+
RTPRIO PRI CGROUP                      CLS  PID %CPU %MEM USER COMMAND
###i##eselect opencl set 1</console>
+
...
* reboot/test process
+
    -  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
  
==Troubleshooting==
+
The FF threads are the real-time one. We will see the same result with htop, but with other priority numbers (I prefer htop).
* what to do if only a blank screen
+
  
Category:Video Cards wrap me with braces when im snazzy
+
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.
Category:First Steps wrap me with braces when im snazzy
+
{{EbuildFooter}}

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.