https://wiki.archlinux.org/api.php?action=feedcontributions&user=Cladmi&feedformat=atomArchWiki - User contributions [en]2024-03-28T18:32:42ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Realtime_process_management&diff=443291Realtime process management2016-07-26T12:20:33Z<p>Cladmi: Fix "IO Benchmarking: How, why and with what" page link</p>
<hr />
<div>[[Category:Security]]<br />
This article provides information on prioritizing process threads in real time, as opposed to at startup only. It shows how you can control CPU, memory, and other resource utilization of individual processes, or all processes run by a particular group.<br />
<br />
While many recent processors are powerful enough to play a dozen video or audio streams simultaneously, it is still possible that another thread hijacks the processor for half a second to complete another task. This results in short interrupts in audio or video streams. It is also possible that video/audio streams get out of sync. While this is annoying for a casual music listener; for a content producer, composer or video editor this issue is much more serious as it interrupts their workflow. <br />
<br />
The simple solution is to give the audio and video processes a '''higher priority'''. However, while normal users can set a higher ''nice'' value to a process, which means that its priority is lower, only root can set lower values and start processes at a lower ''nice'' value than 0. This protects the normal user from underpowering processes which are essential to the system. This can be especially important on multi-user machines.<br />
<br />
== Configuration ==<br />
<br />
By default, real-time prioritizing is enabled on Arch, however its configuration is simplistic and open to editing by the user. For example, in order to allow users to set nice priorities below 0, we need to tweak the default hard limit provided by [[PAM]].<br />
<br />
=== pam ===<br />
<br />
The {{Pkg|pam}} package from the official repositories provides the ''pluggable authentication modules'' for the linux kernel. <br />
<br />
{{Note| If you are running a custom kernel, ensure you have enabled "preemptible kernel" settings. The stock Arch kernel needs no modifications.}}<br />
<br />
=== Configuring PAM ===<br />
<br />
The {{ic|/etc/security/limits.conf}} file provides configuration for the {{ic|pam_limits}} PAM module, which sets limits on system resources. It lets you do things like define the default nice level for all processes, individual groups, the maximum locked-in memory address space, and more.<br />
<br />
{{Note| Processes initiated by Systemd service ignore limits.conf. You need to set in the .service files, for more info, man systemd.exec.}}<br />
<br />
There are two types of resource limits that {{ic|pam_limits}} provides: '''hard limits''' and '''soft limits'''. Hard limits are set by {{ic|root}} and enforced by the kernel, while soft limits may be configured by the user within the range allowed by the hard limits. By default, Arch uses the {{ic|-}} limit, which refers to both hard and soft limits.<br />
<br />
The default Arch Linux settings set the maximum real-time priority allowed for non-priveleged processes to 0, the maximum nice priority allowed to raise to 0, and some custom settings for the {{ic|audio}} group. Finally, the {{ic|memlock}} item sets the maximum locked-in memory address space to 40,000 KiB. These defaults are shown below:<br />
<br />
{{bc|<nowiki><br />
* - rtprio 0<br />
* - nice 0<br />
@audio - rtprio 65<br />
@audio - nice -10<br />
@audio - memlock 40000<br />
</nowiki>}}<br />
<br />
An example for why one might want to alter these settings is to get high-performance audio working. The defaults are permissive enough to get {{ic|jack-server}} running with {{ic|hydrogen}} or {{ic|ardour}}. However, for higher performance audio applications it might be necessary to redefine the values for {{ic|rt_prio}} from 65 to 80 or even higher! The following settings work well with {{ic|ardour}}:<br />
<br />
{{bc|<br />
@audio - rtprio 70<br />
@audio - memlock 250000<br />
}}<br />
<br />
See [[professional audio]] for more information.<br />
<br />
There are an infinite variety of possible PAM limits configurations. While an overview is provided here, it is highly advisable to read the {{ic|man 5 limits.conf}} page in order to better understand these functions.<br />
<br />
== Hard and soft realtime ==<br />
<br />
Realtime is a synonym for a process which has the capability to run<br />
in time without being interrupted by any other process. However, cycles can occasionally be dropped despite this. Low power supply or a process with higher priority could be a potential cause. To solve this problem, there is a scaling of realtime quality. This article deals with '''soft''' realtime. Hard realtime is usually not so much desired as it is ''needed''. An example could be made for car's ABS (anti-lock braking system). This can not be "rendered" and there is no second chance.<br />
<br />
== Power is nothing without control ==<br />
<br />
The realtime-lsm module granted the right to get higher capabilities to users belonging to a certain UID. The rlimit way works similar, but it can be controlled graduated finer. There is a new functionality in PAM which can be used to control the capabilities on a per user or a per group level. In the current version (0.80-2) these values are not set correctly out of the box and still create problems.<br />
With PAM you can grant realtime priority to a certain user or to a certain user group. PAM's concept makes it imaginable that there will be ways in the future to grant rights on a per application level; however, this is not yet possible.<br />
<br />
== Tips and tricks ==<br />
<br />
=== PAM-enabled login ===<br />
<br />
See [[Start X at login]].<br />
<br />
For your system to use PAM limits settings you have to use a {{ic|pam}}-enabled login method/manager. Nearly all graphical login managers are pam-enabled, and it now appears that the default Arch login is {{ic|pam}}-enabled as well. You can confirm this by searching {{ic|/etc/pam.d}}:<br />
<br />
$ grep pam_limits.so /etc/pam.d/*<br />
<br />
If you get nothing, you are whacked. But you will, as long as you have a login manager (and now [[PolicyKit]]). We want an output like this one:<br />
<br />
{{bc|<br />
/etc/pam.d/crond:session required pam_limits.so<br />
/etc/pam.d/login:session required pam_limits.so<br />
/etc/pam.d/polkit-1:session required pam_limits.so<br />
/etc/pam.d/system-auth:session required pam_limits.so<br />
/etc/pam.d/system-services:session required pam_limits.so<br />
}}<br />
<br />
So we see that {{ic|login}}, PolicyKit, and the others all require the pam_limits.so module. This is a good thing, and means PAM limits will be enforced.<br />
<br />
=== Console/autologin ===<br />
<br />
See: [[Automatically login some user to a virtual console on startup]]<br />
<br />
If you prefer to not have a graphical login, you still have a way. You need to edit the {{ic|pam}} stuff for {{ic|su}} (from {{Pkg|coreutils}}):<br />
<br />
{{hc|/etc/pam.d/su|<br />
...<br />
session required pam_limits.so<br />
}}<br />
<br />
Source [https://bbs.archlinux.org/viewtopic.php?pid=387214].<br />
<br />
== Reference ==<br />
<br />
=== RLIMIT Definitions ===<br />
<br />
; RLIMIT_AS: The maximum size of the process’s virtual memory (address space) in bytes. This limit affects calls to brk(2), mmap(2) and mremap(2), which fail with the error ENOMEM upon exceeding this limit. Also automatic stack expansion will fail (and generate a SIGSEGV that kills the process if no alternate stack has been made available via sigaltstack(2)). Since the value is a long, on machines with a 32-bit long either this limit is at most 2 GiB, or this resource is unlimited.<br />
; RLIMIT_CORE: Maximum size of core file. When 0 no core dump files are created. When non-zero, larger dumps are truncated to this size.<br />
; RLIMIT_CPU: CPU time limit in seconds. When the process reaches the soft limit, it is sent a SIGXCPU signal. The default action for this signal is to terminate the process. However, the signal can be caught, and the handler can return control to the main program. If the process continues to consume CPU time, it will be sent SIGXCPU once per second until the hard limit is reached, at which time it is sent SIGKILL. (This latter point describes Linux 2.2 through 2.6 behavior. Implementations vary in how they treat processes which continue to consume CPU time after reaching the soft limit. Portable applications that need to catch this signal should perform an orderly termination upon first receipt of SIGXCPU.)<br />
; RLIMIT_DATA: The maximum size of the process’s data segment (initialized data, uninitialized data, and heap). This limit affects calls to brk(2) and sbrk(2), which fail with the error ENOMEM upon encountering the soft limit of this resource.<br />
; RLIMIT_FSIZE: The maximum size of files that the process may create. Attempts to extend a file beyond this limit result in delivery of a SIGXFSZ signal. By default, this signal terminates a process, but a process can catch this signal instead, in which case the relevant system call (e.g., write(2), truncate(2)) fails with the error EFBIG.<br />
; RLIMIT_LOCKS: (Early Linux 2.4 only) A limit on the combined number of flock(2) locks and fcntl(2) leases that this process may establish.<br />
; RLIMIT_MEMLOCK: The maximum number of bytes of memory that may be locked into RAM. In effect this limit is rounded down to the nearest multiple of the system page size. This limit affects mlock(2) and mlockall(2) and the mmap(2) MAP_LOCKED operation. Since Linux 2.6.9 it also affects the shmctl(2) SHM_LOCK operation, where it sets a maximum on the total bytes in shared memory segments (see shmget(2)) that may be locked by the real user ID of the calling process. The shmctl(2) SHM_LOCK locks are accounted for separately from the per-process memory locks established by mlock(2), mlockall(2), and mmap(2) MAP_LOCKED; a process can lock bytes up to this limit in each of these two categories. In Linux kernels before 2.6.9, this limit controlled the amount of memory that could be locked by a privileged process. Since Linux 2.6.9, no limits are placed on the amount of memory that a privileged process may lock, and this limit instead governs the amount of memory that an unprivileged process may lock.<br />
; RLIMIT_MSGQUEUE: (Since Linux 2.6.8) Specifies the limit on the number of bytes that can be allocated for POSIX message queues for the real user ID of the calling process. This limit is enforced for mq_open(3). Each message queue that the user creates counts (until it is removed) against this limit according to the formula: bytes = attr.mq_maxmsg * sizeof(struct msg_msg *) + attr.mq_maxmsg * attr.mq_msgsize where attr is the mq_attr structure specified as the fourth argument to mq_open(3). The first addend in the formula, which includes sizeof(struct msg_msg *) (4 bytes on Linux/i386), ensures that the user cannot create an unlimited number of zero-length messages (such messages nevertheless each consume some system memory for bookkeeping overhead).<br />
; RLIMIT_NICE: (since Linux 2.6.12, but see BUGS below) Specifies a ceiling to which the process’s nice value can be raised using setpriority(2) or nice(2). The actual ceiling for the nice value is calculated as 20 – rlim_cur. (This strangeness occurs because negative numbers cannot be specified as resource limit values, since they typically have special meanings. For example, RLIM_INFINITY typically is the same as -1.)<br />
; RLIMIT_NOFILE: Specifies a value one greater than the maximum file descriptor number that can be opened by this process. Attempts (open(2), pipe(2), dup(2), etc.) to exceed this limit yield the error EMFILE. (Historically, this limit was named RLIMIT_OFILE on BSD.)<br />
; RLIMIT_NPROC: The maximum number of processes (or, more precisely on Linux, threads) that can be created for the real user ID of the calling process. Upon encountering this limit, fork(2) fails with the error EAGAIN.<br />
; RLIMIT_RSS: Specifies the limit (in pages) of the process’s resident set (the number of virtual pages resident in RAM). This limit only has effect in Linux 2.4.x, x < 30, and there only affects calls to madvise(2) specifying MADV_WILLNEED.<br />
; RLIMIT_RTPRIO: (Since Linux 2.6.12, but see BUGS) Specifies a ceiling on the real-time priority that may be set for this process using sched_setscheduler(2) and sched_setparam(2).<br />
; RLIMIT_RTTIME: (Since Linux 2.6.25) Specifies a limit on the amount of CPU time that a process scheduled under a real-time scheduling policy may consume without making a blocking system call. For the purpose of this limit, each time a process makes a blocking system call, the count of its consumed CPU time is reset to zero. The CPU time count is not reset if the process continues trying to use the CPU but is preempted, its time slice expires, or it calls sched_yield(2). Upon reaching the soft limit, the process is sent a SIGXCPU signal. If the process catches or ignores this signal and continues consuming CPU time, then SIGXCPU will be generated once each second until the hard limit is reached, at which point the process is sent a SIGKILL signal. The intended use of this limit is to stop a runaway real-time process from locking up the system.<br />
; RLIMIT_SIGPENDING: (Since Linux 2.6.8) Specifies the limit on the number of signals that may be queued for the real user ID of the calling process. Both standard and real-time signals are counted for the purpose of checking this limit. However, the limit is only enforced for sigqueue(2); it is always possible to use kill(2) to queue one instance of any of the signals that are not already queued to the process.<br />
; RLIMIT_STACK: The maximum size of the process stack, in bytes. Upon reaching this limit, a SIGSEGV signal is generated. To handle this signal, a process must employ an alternate signal stack (sigaltstack(2)).<br />
<br />
=== Scheduling policies ===<br />
<br />
CFS implements three scheduling policies:<br />
; SCHED_NORMAL (traditionally called SCHED_OTHER): The scheduling policy that is used for regular tasks.<br />
; SCHED_BATCH: Does not preempt nearly as often as regular tasks would, thereby allowing tasks to run longer and make better use of caches but at the cost of interactivity. This is well suited for batch jobs.<br />
; SCHED_IDLE: This is even weaker than nice 19, but its not a true idle timer scheduler in order to avoid to get into priority inversion problems which would deadlock the machine.<br />
<br />
=== Scheduling classes ===<br />
<br />
; IOPRIO_CLASS_RT: This is the realtime io class. The RT scheduling class is given first access to the disk, regardless of what else is going on in the system. Thus the RT class needs to be used with some care, as it can starve other processes. As with the best effort class, 8 priority levels are defined denoting how big a time slice a given process will receive on each scheduling window. This scheduling class is given higher priority than any other in the system, processes from this class are given first access to the disk every time. Thus it needs to be used with some care, one io RT process can starve the entire system. Within the RT class, there are 8 levels of class data that determine exactly how much time this process needs the disk for on each service. In the future this might change to be more directly mappable to performance, by passing in a wanted data rate instead.<br />
; IOPRIO_CLASS_BE: This is the best-effort scheduling class, which is the default for any process that hasn’t set a specific io priority. This is the default scheduling class for any process that hasn’t asked for a specific io priority. Programs inherit the CPU nice setting for io priorities. This class takes a priority argument from 0-7, with lower number being higher priority. Programs running at the same best effort priority are served in a round-robin fashion. The class data determines how much io bandwidth the process will get, it’s directly mappable to the cpu nice levels just more coarsely implemented. 0 is the highest BE prio level, 7 is the lowest. The mapping between cpu nice level and io nice level is determined as: io_nice = (cpu_nice + 20) / 5.<br />
; IOPRIO_CLASS_IDLE: This is the idle scheduling class, processes running at this level only get io time when no one else needs the disk. A program running with idle io priority will only get disk time when no other program has asked for disk io for a defined grace period. The impact of idle io processes on normal system activity should be zero. This scheduling class does not take a priority argument. The idle class has no class data, since it doesn’t really apply here.<br />
<br />
== See also ==<br />
<br />
* [http://cuddletech.com/?p=330 IO Benchmarking: How, why and with what]<br />
* [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt CGROUPS Kernel documentation]<br />
* [http://www.askapache.com/linux-unix/optimize-nice-ionice.html Optimizing servers and processes for speed with ionice, nice, ulimit]<br />
* [http://sebastien.godard.pagesperso-orange.fr/ SYSSTAT utilities home page]<br />
* [http://gaarai.com/2009/03/06/multitasking-from-the-linux-command-line-plus-process-prioritization/ Multitasking from the Linux command line and process prioritization]</div>Cladmihttps://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=344083JACK Audio Connection Kit2014-11-09T18:45:47Z<p>Cladmi: Correct link to FAQ jack1/jack2 difference</p>
<hr />
<div>[[Category:Audio/Video]]<br />
[[fr:Jack]]<br />
[[ja:JACK Audio Connection Kit]]<br />
==Installation==<br />
In order for JACK to work properly, your user needs to be [[Users and groups#Group management|added]] to the {{ic|audio}} group for access to higher ulimits defined in {{ic|/etc/security/limits.conf}}, which is needed for realtime audio processing.<br />
{{Note|You need to manually add your user to the {{ic|audio}} group even if you're using logind, since logind just handles access to direct hardware.}}<br />
<br />
There are two JACK implementations, see [https://github.com/jackaudio/jackaudio.github.com/wiki/Q_difference_jack1_jack2 this comparison] for the difference between the two.<br />
<br />
===JACK2===<br />
'''JACK2''' is rewritten explicitly towards multiprocessor hardware. Install it with {{Pkg|jack2}}, available from the [[official repositories]]. If you are on a 64-bit installation and need to run 32-bit applications that require JACK, also install {{Pkg|lib32-jack2}} from the [[multilib]] repository.<br />
<br />
====JACK2 D-Bus====<br />
JACK2 with [[D-Bus]] can be installed via {{Pkg|jack2-dbus}}. It is the same as the jack2 package but does not provide the legacy "jackd" server.<br />
<br />
It is controlled by the {{ic|jack_control}} utility. The important commands are listed below:<br />
jack_control start - starts the jack server<br />
jack_control stop - stops the jack server<br />
jack_control ds alsa - selects alsa as the driver (backend)<br />
jack_control eps realtime True - set engine parameters, such as realtime<br />
jack_control dps period 256 - set the driver parameter period to 256<br />
<br />
===JACK===<br />
Alternatively, there is the older '''JACK''', installable with {{pkg|jack}}, available from the [[official repositories]]. If you are on a 64-bit installation and need to run 32-bit applications that require JACK, also install {{Pkg|lib32-jack}} from the [[multilib]] repository.<br />
<br />
===GUI===<br />
If you want a GUI control application, the most widely used one is {{Pkg|qjackctl}}, available in the [[official repositories]].<br />
<br />
==Basic Configuration==<br />
<br />
===Overview===<br />
<br />
[http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf This Linux Magazine article] is a very good general overview, although do not worry about manual compilations, quite a few JACK tools work right off the wire now, ''after'' JACK is configured correctly.<br />
<br />
Most tutorials are advising a realtime kernel, which is quite helpful for live synthesis and FX; but for purposes of recording and editing it is not necessary, as long as you set up for non-realtime latencies -- 10-40+ ms (100-500+ ms for older hardware).<br />
<br />
The right configuration for your hardware and application needs, depends on several factors.<br />
<br />
===A Shell-Based Example Setup===<br />
<br />
''''' [https://github.com/jackaudio/jackaudio.github.com/wiki/FAQ_and_Myths JACK docs linking this precise example] do merit consideration. But the original author of the example wishes to state that it is for priority access to computation, to RAM, and motherboard nexus hardware, not mostly audio, that he uses schedtool on sound-production processes. '''''<br />
<br />
The D-Bus edition of JACK2 can make startup much easier. Formerly, we had to have QjackCtl start it for us, or use a daemonizer, or some other method. But using {{Pkg|jack2-dbus}}, we can easily start and configure it via a shell script.<br />
<br />
Create a shell script that can be executed at X login:<br />
<br />
{{hc|start_jack.sh|<br />
#!/bin/bash<br />
<br />
jack_control start<br />
sudo schedtool -R -p 20 `pidof jackdbus`<br />
jack_control eps realtime true<br />
jack_control ds alsa<br />
jack_control dps device hw:HD2<br />
jack_control dps rate 48000<br />
jack_control dps nperiods 2<br />
jack_control dps period 64<br />
sleep 10<br />
/usr/bin/a2jmidid -e &<br />
sleep 10<br />
sudo schedtool -R -p 20 `pidof a2jmidid`<br />
qjackctl &<br />
sleep 10<br />
sudo schedtool -R -p 20 `pidof qjackctl`<br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
sleep 10<br />
sudo schedtool -R -p 20 `pidof qmidiroute`<br />
yoshimi -S &<br />
sleep 10<br />
sudo schedtool -R -p 20 `pidof yoshimi`<br />
}}<br />
<br />
The above will start a complete realtime JACK live-synthesis setup, integrating several tools. Details of each line follow. When discovering your own best configuration, it is helpful to do trial and error using QjackCtl's GUI with a non-D-Bus JACK2 version.<br />
<br />
====Details of the Shell-Based Example Setup====<br />
<br />
jack_control start<br />
Starts JACK if it is not already started.<br />
sudo schedtool -R -p 20 `pidof jackdbus`<br />
Set JACK to realtime mode in the Linux kernel, priority 20 (options range 1-99).<br />
jack_control eps realtime true<br />
Sets JACK to realtime mode in its own internal setup.<br />
jack_control ds alsa<br />
Sets JACK to use the ALSA driver set.<br />
jack_control dps device hw:HD2<br />
Sets JACK to use ALSA-compatible sound card named HD2. One can find the names with {{ic|cat /proc/asound/cards}}. Most ALSA tutorials and default configurations use card numbers, but this can get confusing when external MIDI devices are in use; names make it easier.<br />
jack_control dps rate 48000<br />
Sets JACK to use 48000 khz sampling. Happens to work very well with this card. Some cards only do 44100, many will go much higher. The higher you go, the lower your latency, but the better your card and your CPU has to be, and software has to support this as well.<br />
jack_control dps nperiods 2<br />
Sets JACK to use 2 periods. 2 is right for motherboard, PCI, PCI-X, etc.; 3 for USB.<br />
jack_control dps period 64<br />
Sets JACK to use 64 periods per frame. Lower is less latency, but the setting in this script gives 2.67 ms latency, which is nicely low without putting too much stress on the particular hardware this example was built for. If a USB sound system were in use it might be good to try 32. Anything less than 3-4 ms should be fine for realtime synthesis and/or FX, 5 ms is the smallest a human being can detect. There are many cases of perfect-storm-gorgeous hardware which can handle 1 ms latency without stressing the CPU, but definitely this is not always the case! QjackCtl will tell you how you are doing; at no-load, which means no clients attached, you will want a max of 3-5% CPU usage, and if you cannot get that without xruns (the red numbers which mean the system cannot keep up with the demands), you will have to improve your hardware. There are many inexpensive USB sound systems which produce very good quality at very low latency if the USB is good on the motherboard, but not all. <br />
sleep 10<br />
Wait for the above to settle.<br />
/usr/bin/a2jmidid -e &<br />
Start the ALSA-to-JACK MIDI bridge. Good for mixing in applications which take MIDI input through ALSA but not JACK.<br />
sleep 10<br />
Wait for the above to settle.<br />
sudo schedtool -R -p 20 `pidof a2jmidid`<br />
Set a2jmidid to realtime scheduling in the Linux kernel.<br />
qjackctl &<br />
Load QjackCtl. GUI configuration tells it to run in the system tray. It will pick up the JACK session started by D-Bus just fine, and very smoothly too. It maintains the patchbay, the connections between these applications and any other JACK-enabled apps to be started manually. The patchbay is set up using manual GUI, but connections pre-configured in the patchbay are automatically created by QjackCtl itself when apps are started.<br />
sleep 10<br />
Wait for the above to settle.<br />
sudo schedtool -R -p 20 `pidof qjackctl`<br />
Set qjackctl to realtime scheduling in the Linux kernel. <br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
Load qmidiroute, loading a custom-created configuration file which will rewrite all MIDI events on all channels to channel 1. This is useful when plugging the PC into any keyboard anywhere -- no matter what the keyboard's channel defaults to, qmidiroute will send the signal to the synth on channel 1, where it needs it. qmidiroute is capable of very complex and useful configurations of many sorts, including multiple simultaneous translations, transpositions, signal type rewrites, etcetera.<br />
sleep 10<br />
Wait for the above to settle.<br />
sudo schedtool -R -p 20 `pidof qmidiroute`<br />
Set qmidiroute to realtime scheduling in the Linux kernel.<br />
yoshimi -S &<br />
Load the Yoshimi synthesizer, using the pre-saved default state.<br />
sleep 10<br />
Wait for the above to settle.<br />
sudo schedtool -R -p 20 `pidof yoshimi`<br />
Set Yoshimi to realtime scheduling in the Linux kernel.<br />
<br />
With all of the above in a script run at logon, and with the QjackCtl patchbay set correctly, all we have to do is plug the PC/laptop into a MIDI keyboard using a USB-to-MIDI adapter, or simply the USB-in MIDI capability of many modern keyboards, and you are ready to play!<br />
<br />
The essence of QJackCtl is described fairly well in [http://www.linuxjournal.com/article/8354 this article.]<br />
<br />
===A GUI-Based Example Setup===<br />
<br />
The shell-based example above, lays out in detail lots of things you may well need to know, and it does work well. If you want something much more GUI, however, do this:<br />
<br />
* Install {{Pkg|jack2-dbus}}.<br />
<br />
* Copy {{ic|/etc/asound.conf}} to {{ic|/etc/asound.conf.ORIGINAL}}, and replace it with this:<br />
<br />
pcm.pulse {<br />
type pulse<br />
}<br />
ctl.pulse {<br />
type pulse<br />
}<br />
pcm.!default {<br />
type pulse<br />
}<br />
ctl.!default {<br />
type pulse<br />
}<br />
<br />
* Install {{Pkg|pulseaudio}}.<br />
* Install {{Pkg|pulseaudio-alsa}}.<br />
* Install {{Pkg|qjackctl}}, and tell your GUI window/desktop system to run it at startup.<br />
* Make sure QjackCtl is told to:<br />
** use the D-Bus interface,<br />
** run at startup,<br />
** save its configuration to the default location,<br />
** start the JACK audio server on application startup,<br />
** enable the system tray icon, and<br />
** start minimized to sytem tray.<br />
* Reboot.<br />
* After logging in, you will see QjackCtl in your system tray. Left-click on it.<br />
* Start tweaking in the QjackCtl GUI. The info embedded in the shell-script setup above may be of some help :-) As may be the info in [http://www.linuxjournal.com/article/8354 this article]. Just remember that you have to get your latency down to less than 5ms for live tone production or filtration of any sort, or the delay will be obvious to player and listener alike.<br />
* From the [[AUR]], install {{AUR|non-daw}}. One of the components of this package is called non-session-manager; it has the function of setting up "sessions": sets of other audio software items which Jack (through the QjackCtl patchbay or not!) will wire together. NSM can handle as many different sessions as you wish to set up; and as a result, it's all GUI, apart from the one rc.local edit in the beginning.<br />
<br />
===More===<br />
<br />
Yet more info is in the [[Pro Audio]] page.<br />
<br />
== Jack for a multi-user system ==<br />
{{Out of date|this needs to be updated for [[systemd]]}}<br />
So, you have a decent multiuser system as it was designed more than 20 years ago, and now some developers decided that sound is only for a mono-user system... No I can not believe it !<br />
<br />
{{Warning|Before following the below instructions, please note that there is a security risk to any service running as root, and, more importantly, the developers for jack do not test it for running as root. In other words, it could eat your babies, data, or both}}<br />
<br />
Fortunately some time ago someone convinced the developers to allow jack to run as a system wide daemon. Here is the procedure to follow:<br />
<br />
'''Create a {{Ic|/etc/profile.d/jack.sh}} file''' containing:<br />
export JACK_PROMISCUOUS_SERVER=""<br />
<br />
'''Replace {{Ic|/etc/rc.d/jack-audio-connection-kit}}''' with the following content<br />
{{bc|<nowiki><br />
#!/bin/bash <br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
# source application-specific settings<br />
[ -f /etc/conf.d/jack-audio-connection-kit ] && . /etc/conf.d/jack-audio-connection-kit<br />
<br />
PID=`pidof -o %PPID /usr/bin/jackd`<br />
<br />
[ -n "$JACKUSER" ] && HOME="/home/$JACKUSER"<br />
[ -z "$JACK_PARAMS" ] && JACK_PARAMS=$(sed 's:/usr/bin/jackd ::' $HOME/.jackdrc)<br />
<br />
case "$1" in<br />
start)<br />
stat_busy "Starting JACK"<br />
if [ -z "$PID" ]; then<br />
if [ -n "$JACKUSER" ]; then<br />
su - $JACKUSER -c 'export JACK_PROMISCUOUS_SERVER="" && . /etc/conf.d/jack-audio-connection-kit && umask 0000 && /usr/bin/jackd $JACK_PARAMS &> /dev/null &'<br />
else<br />
export JACK_PROMISCUOUS_SERVER=""<br />
umask 0000<br />
/usr/bin/jackd $JACK_PARAMS &> /dev/null &<br />
fi<br />
fi<br />
<br />
if [ ! -z "$PID" -o $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
add_daemon jack<br />
stat_done<br />
fi<br />
;;<br />
stop)<br />
stat_busy "Stopping JACK"<br />
[ ! -z "$PID" ] && kill $PID &> /dev/null<br />
if [ $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
rm_daemon jack<br />
stat_done<br />
fi<br />
;;<br />
restart)<br />
$0 stop<br />
sleep 1<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {sta|stop|restart}"<br />
esac<br />
exit 0<br />
</nowiki>}}<br />
<br />
Where my '''{{Ic|/etc/conf.d/jack-audio-connection-kit}}''' is<br />
{{bc|1=<br />
# Configuration for starting JACK at boot<br />
<br />
# Uncomment this to run as user (recommended)<br />
#JACKUSER="root"<br />
<br />
# Uncomment this to not source ~/.jackdrc<br />
JACK_PARAMS="-R -P89 -dalsa -dhw:1 -r48000 -p512 -n3"<br />
}}<br />
<br />
===Playing nice with ALSA===<br />
To allow Alsa programs to play while jack is running you must install the jack plugin for alsa with {{Pkg|alsa-plugins}}.<br />
<br />
And enable it by editing (or creating) /etc/asound.conf (system wide settings) to have these lines:<br />
{{bc|<nowiki><br />
# convert alsa API over jack API<br />
# use it with<br />
# % aplay foo.wav<br />
<br />
# use this as default<br />
pcm.!default {<br />
type plug<br />
slave { pcm "jack" }<br />
}<br />
<br />
ctl.mixer0 {<br />
type hw<br />
card 1<br />
}<br />
<br />
# pcm type jack<br />
pcm.jack {<br />
type jack<br />
playback_ports {<br />
0 system:playback_1<br />
1 system:playback_2<br />
}<br />
capture_ports {<br />
0 system:capture_1<br />
1 system:capture_2<br />
}<br />
}</nowiki>}}<br />
<br />
You need not restart your computer or anything. Just edit the alsa config files, start up jack, and there you go...<br />
<br />
Remember to start it as a '''user'''. If you start it with {{ic|jackd}} -d alsa" as user X, it will not work for user Y.<br />
<br />
Another approach, using ALSA loopback device (more complex but probably more robust), is described in [http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge this article].<br />
<br />
=== gstreamer ===<br />
Example: watching a live stream without gconf<br />
{{bc|<nowiki>gst-launch-0.10 playbin2 uri=http://streamer.stackingdwarves.net/bewerungeroom.ogv audio-sink="jackaudiosink"</nowiki>}}<br />
<br />
Setting gstreamer to use jack using gconftool-2<br />
gconftool-2 --type string --set /system/gstreamer/0.10/audio/default/audiosink "jackaudiosink buffer-time=2000000"<br />
gconftool-2 --type string --set /system/gstreamer/0.10/audio/default/musicaudiosink "jackaudiosink buffer-time=2000000"<br />
gconftool-2 --type string --set /system/gstreamer/0.10/audio/default/chataudiosink "jackaudiosink buffer-time=2000000"<br />
<br />
Further information: http://jackaudio.org/gstreamer_via_jack<br />
<br />
=== PulseAudio ===<br />
If you need to keep {{Pkg|pulseaudio}} installed (in the event it is required by other packages, like {{Pkg|gnome-settings-daemon}}), you may want to prevent it from spawning automatically with X and taking over from JACK.<br />
<br />
Edit {{ic|/etc/pulse/client.conf}}, uncomment "autospawn" and set it to "no":<br />
;autospawn = yes<br />
autospawn = no<br />
<br />
''If you want both to play along, see: [[PulseAudio/Examples#PulseAudio through JACK]]''<br />
<br />
==MIDI==<br />
<br />
JACK can handle one soundcard very well, and an arbitrary number of MIDI devices (connected e.g. via USB).<br />
If you start JACK and want to use a MIDI keyboard or a synthesizer or some other pure MIDI device, you have to start JACK with a proper soundcard (one that actually outputs or inputs PCM sound).<br />
As soon you have done that, you can connect the MIDI device. E.g. with QjackCtl ({{pkg|qjackctl}}), you click on the connect button and you will find your device listed under JACK-MIDI or ALSA-MIDI, depending on the driver.<br />
<br />
For JACK-MIDI, you may want to set the '''MIDI Driver''' to '''seq''' or '''raw''' in QjackCtl ''Setup > Settings''. This should make your MIDI device appear under the ''MIDI'' tab. You can also change the name of the client (from a generic "midi_capture_1" to something more descriptive), if you enable ''Setup > Display > Enable client/port aliases'' and then ''Enable client/port aliases editing (rename)''.<br />
<br />
For ALSA-MIDI, make sure to turn on '''Enable ALSA Sequencer support''' in QjackCtl ''Setup > Misc''. This will add the ''ALSA'' tab in QjackCtl ''Connect'' window where your MIDI controller will show up.<br />
<br />
For bridging ALSA-MIDI to JACK-MIDI, you may consider using a2jmidid ({{AUR|a2jmidid}}). The following command will export all available ALSA MIDI ports to JACK MIDI ports:<br />
$ a2jmidid -e<br />
They will be visible in QjackCtl under the ''MIDI'' tab labelled "a2j" client.<br />
You can automate starting of a2jmidid by adding to QjackCtl ''Setup > Options > Execute script after Startup'': {{ic|/usr/bin/a2jmidid -e &}}<br />
{{note|When connecting MIDI keyboard controllers in QjackCtl, make sure to ''Expand All'' first and connect the desired ''Output Ports'' (below the ''Readable Clients'') to the ''Input Ports'' (below the ''Writable Clients''). As a shortcut, if you select a writable client instead of individual ports as your destination, it should connect all its currently displayed output ports underneath.}}<br />
<br />
*'''Q:''' What is the difference between JACK-MIDI and ALSA-MIDI?<br />
*'''A:''' The former has improved timing and sample accurate MIDI event alignment. It extends or may even replace the latter but at this point they both co-exist.<br />
<br />
To install some M-Audio MIDI keyboards, you will need the firmware package {{AUR|midisport-firmware}} in the [[AUR]]. Also, the snd_usb_audio module has to be available.<br />
For more information about specific USB MIDI devices, see http://alsa.opensrc.org/USBMidiDevices.<br />
<br />
==Troubleshooting==<br />
==="Cannot lock down memory area (Cannot allocate memory)" message on startup===<br />
See [[Realtime for Users#Add user to audio group]].<br />
<br />
===jack2-dbus and qjackctl errors===<br />
Still having the "Cannot allocate memory" and/or "Cannot connect to server socket err = No such file or directory" error(s) when pressing qjackctl's start button (assuming that you have package jack2-dbus installed) ?<br />
<br />
Please delete {{ic|~/.jackdrc}}, {{ic|~/.config/jack/conf.xml}}, {{ic|~/.config/rncbc.org/QjackCtl.conf}}. Kill ''jackdbus'' and restart from scratch :)<br />
(Thanks to nedko)<br />
<br />
===Problems with specific applications===<br />
====VLC - no audio after starting JACK====<br />
Run VLC and change the following menu options:<br />
* Tools > Preferences<br />
* Show settings: All<br />
* Audio > Output modules > Audio output module: JACK audio output<br />
* Audio > Output modules > JACK: Automatically connect to writable clients (enable)<br />
<br />
==Related Articles==<br />
*[[Pro Audio]]</div>Cladmihttps://wiki.archlinux.org/index.php?title=Talk:Simple_stateful_firewall&diff=184859Talk:Simple stateful firewall2012-02-15T12:28:11Z<p>Cladmi: </p>
<hr />
<div>Maybe I misunderstood some of the instructions but I found that I needed to insert the rules into the chains TCP and UDP rather than OPEN-TCP and OPEN-UDP as the latter didn't exist:<br />
<br />
# iptables -I TCP -p tcp -m recent --update --seconds 60 --name TCP-PORTSCAN -j REJECT --reject-with tcp-rst<br />
# iptables -I UDP -p udp -m recent --update --seconds 60 --name UDP-PORTSCAN -j REJECT --reject-with port-unreach<br />
<br />
I also found that I needed to add an --update:<br />
<br />
# iptables -A INPUT -p icmp --icmp-type echo-request -m recent --name ping_limiter --hitcount 6 --seconds 4 -j DROP<br />
<br />
I believe an --rcheck would also have worked. I'm not sure which would be correct. In general, I found this very helpful in conjunction with the man page for iptables. --[[User:Margali|Margali]] 21:57, 29 December 2011 (EST)<br />
<br />
<br />
<br />
For ipv6 adaptation.<br />
As '''--reject-with icmp6-proto-unreachable''' does not exist in ipv6, as told in the page, and according to the error messages description in the RFC [[https://tools.ietf.org/html/rfc4443#section-3.1]].<br />
I think the '''icmp6-adm-prohibited''' which means "Communication with destination administratively prohibited" may be the message to send. It is only by reading the RFC, I am not a network expert and I have no idea of what is generally done in this case.--[[User:Cladmi|Cladmi]] 07:28, 15 February 2012 (EST)</div>Cladmihttps://wiki.archlinux.org/index.php?title=Talk:Simple_stateful_firewall&diff=184858Talk:Simple stateful firewall2012-02-15T12:26:31Z<p>Cladmi: Suggestion for protocol filtering reject error in ipv6</p>
<hr />
<div>Maybe I misunderstood some of the instructions but I found that I needed to insert the rules into the chains TCP and UDP rather than OPEN-TCP and OPEN-UDP as the latter didn't exist:<br />
<br />
# iptables -I TCP -p tcp -m recent --update --seconds 60 --name TCP-PORTSCAN -j REJECT --reject-with tcp-rst<br />
# iptables -I UDP -p udp -m recent --update --seconds 60 --name UDP-PORTSCAN -j REJECT --reject-with port-unreach<br />
<br />
I also found that I needed to add an --update:<br />
<br />
# iptables -A INPUT -p icmp --icmp-type echo-request -m recent --name ping_limiter --hitcount 6 --seconds 4 -j DROP<br />
<br />
I believe an --rcheck would also have worked. I'm not sure which would be correct. In general, I found this very helpful in conjunction with the man page for iptables. --[[User:Margali|Margali]] 21:57, 29 December 2011 (EST)<br />
<br />
<br />
<br />
For ipv6 adaptation.<br />
As '''--reject-with icmp6-proto-unreachable''' does not exist in ipv6, as told in the page, and according to the error messages description in the RFC [[https://tools.ietf.org/html/rfc4443#section-3.1]].<br />
I think the '''icmp6-adm-prohibited''' which means "Communication with destination administratively prohibited" may be the message to send. It is only by reading the RFC, I am not a network expert and I have no idea of what is generally done in this case.</div>Cladmi