https://wiki.archlinux.org/api.php?action=feedcontributions&user=Smoge&feedformat=atomArchWiki - User contributions [en]2024-03-28T21:11:54ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=378147JACK Audio Connection Kit2015-06-11T10:15:34Z<p>Smoge: Removing misleading use of schedtool for GUI applications. See https://wiki.archlinux.org/index.php/Talk:JACK_Audio_Connection_Kit</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://www.linux-magazine.com/content/download/63041/486886/version/1/file/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 />
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 />
qjackctl &<br />
sleep 10<br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
sleep 10<br />
yoshimi -S &<br />
sleep 10<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 />
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 />
<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 />
yoshimi -S &<br />
Load the Yoshimi synthesizer, using the pre-saved default state.<br />
sleep 10<br />
Wait for the above to settle.<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 ({{Pkg|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 />
Also try running <br />
$ fuser /dev/snd/*<br />
and check the resulting PID's with<br />
$ ps ax | grep [PID here]<br />
This will hopefully show the conflicting programs.<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>Smogehttps://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=378146JACK Audio Connection Kit2015-06-11T10:12:57Z<p>Smoge: Undo revision 378145 by Smoge (talk)</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://www.linux-magazine.com/content/download/63041/486886/version/1/file/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 />
{{Accuracy|Be careful when using schedtool! DO NOT change scheduling policies of GUI applications, this will not make any good for audio... In fact this can make things worse}}<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 ({{Pkg|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 />
Also try running <br />
$ fuser /dev/snd/*<br />
and check the resulting PID's with<br />
$ ps ax | grep [PID here]<br />
This will hopefully show the conflicting programs.<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>Smogehttps://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=378145JACK Audio Connection Kit2015-06-11T10:11:20Z<p>Smoge: /* A Shell-Based Example Setup */</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://www.linux-magazine.com/content/download/63041/486886/version/1/file/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 />
{{Accuracy|Be careful when using schedtool! DO NOT change scheduling policies of GUI applications, this will not make any good for audio... In fact this can make things worse}}<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 />
qjackctl &<br />
sleep 10<br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
sleep 10<br />
yoshimi -S &<br />
sleep 10<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 />
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 />
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 />
yoshimi -S &<br />
Load the Yoshimi synthesizer, using the pre-saved default state.<br />
sleep 10<br />
Wait for the above to settle.<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 ({{Pkg|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 />
Also try running <br />
$ fuser /dev/snd/*<br />
and check the resulting PID's with<br />
$ ps ax | grep [PID here]<br />
This will hopefully show the conflicting programs.<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>Smogehttps://wiki.archlinux.org/index.php?title=Talk:JACK_Audio_Connection_Kit&diff=378144Talk:JACK Audio Connection Kit2015-06-11T10:09:26Z<p>Smoge: </p>
<hr />
<div>== Misleading script using schedtool for non-audio processes ==<br />
<br />
I would just remove the examples setting up realtime scheduling of GUI application.<br />
<br />
If JACK is running with higher priority, the whole chain of audio processes will have the same priority.<br />
<br />
The script suggests that elevating GUI application priorities with schedtool will increase the priority of their audio processes, but in fact this is *not* necessary.<br />
<br />
What will happen is that the user will increase the priority of non-audio processes (GUI etc), which will have the same priority of the audio processes. It makes things "worse" because you are decreasing the relative priority of the audio processes when you increase priorities of several non-audio processes.<br />
<br />
It is just a misleading procedure as far as I'm concerned: the reader will understand something different then what he/she is actually doing.<br />
<br />
<br />
== Wrong sound card number in "Playing nice with ALSA"? ==<br />
<br />
Is the sound card used in the section https://wiki.archlinux.org/index.php/JACK_Audio_Connection_Kit#Playing_nice_with_ALSA supposed to use...<br />
<br />
{{bc|ctl.mixer0 {<br />
type hw<br />
card 0<br />
}<br />
}}<br />
<br />
...instead of<br />
<br />
{{bc|ctl.mixer0 {<br />
type hw<br />
card 1<br />
}<br />
}}<br />
<br />
I've tried both in my system and I don't notice anything changing because of it. I've left mine at "card 0" because that's my default sound card.<br />
<br />
[[User:Saultdon|Saultdon]] ([[User talk:Saultdon|talk]]) 01:24, 6 July 2013 (UTC)</div>Smogehttps://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=377915JACK Audio Connection Kit2015-06-08T18:27:19Z<p>Smoge: /* Details of the Shell-Based Example Setup */</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://www.linux-magazine.com/content/download/63041/486886/version/1/file/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 />
{{Warning|Be careful when using schedtool! DO NOT change scheduling policies of GUI applications, this will not make any good for audio... In fact this can make things worse}}<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 />
qjackctl &<br />
sleep 10<br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
sleep 10<br />
yoshimi -S &<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 />
<s> <br />
sudo schedtool -R -p 20 `pidof qjackctl`<br />
Set qjackctl to realtime scheduling in the Linux kernel. </s> <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 />
<s>sudo schedtool -R -p 20 `pidof qmidiroute`</s><br />
<s>Set qmidiroute to realtime scheduling in the Linux kernel.</s><br />
<br />
yoshimi -S &<br />
Load the Yoshimi synthesizer, using the pre-saved default state.<br />
sleep 10<br />
Wait for the above to settle.<s> <br />
sudo schedtool -R -p 20 `pidof yoshimi`<br />
Set Yoshimi to realtime scheduling in the Linux kernel.<br />
</s><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 ({{Pkg|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 />
Also try running <br />
$ fuser /dev/snd/*<br />
and check the resulting PID's with<br />
$ ps ax | grep [PID here]<br />
This will hopefully show the conflicting programs.<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>Smogehttps://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=377914JACK Audio Connection Kit2015-06-08T18:26:50Z<p>Smoge: /* Details of the Shell-Based Example Setup */</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://www.linux-magazine.com/content/download/63041/486886/version/1/file/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 />
{{Warning|Be careful when using schedtool! DO NOT change scheduling policies of GUI applications, this will not make any good for audio... In fact this can make things worse}}<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 />
qjackctl &<br />
sleep 10<br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
sleep 10<br />
yoshimi -S &<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 />
<s> sudo schedtool -R -p 20 `pidof qjackctl`<br />
Set qjackctl to realtime scheduling in the Linux kernel. </s> <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 />
<s>sudo schedtool -R -p 20 `pidof qmidiroute`</s><br />
<s>Set qmidiroute to realtime scheduling in the Linux kernel.</s><br />
<br />
yoshimi -S &<br />
Load the Yoshimi synthesizer, using the pre-saved default state.<br />
sleep 10<br />
Wait for the above to settle.<s> <br />
sudo schedtool -R -p 20 `pidof yoshimi`<br />
Set Yoshimi to realtime scheduling in the Linux kernel.<br />
</s><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 ({{Pkg|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 />
Also try running <br />
$ fuser /dev/snd/*<br />
and check the resulting PID's with<br />
$ ps ax | grep [PID here]<br />
This will hopefully show the conflicting programs.<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>Smogehttps://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=377913JACK Audio Connection Kit2015-06-08T18:24:57Z<p>Smoge: /* Details of the Shell-Based Example Setup */</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://www.linux-magazine.com/content/download/63041/486886/version/1/file/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 />
{{Warning|Be careful when using schedtool! DO NOT change scheduling policies of GUI applications, this will not make any good for audio... In fact this can make things worse}}<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 />
qjackctl &<br />
sleep 10<br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
sleep 10<br />
yoshimi -S &<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 />
<s> sudo schedtool -R -p 20 `pidof qjackctl`<br />
Set qjackctl to realtime scheduling in the Linux kernel. </s> <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.<s><br />
sudo schedtool -R -p 20 `pidof qmidiroute`<br />
Set qmidiroute to realtime scheduling in the Linux kernel.<br />
</s><br />
yoshimi -S &<br />
Load the Yoshimi synthesizer, using the pre-saved default state.<br />
sleep 10<br />
Wait for the above to settle.<s> <br />
sudo schedtool -R -p 20 `pidof yoshimi`<br />
Set Yoshimi to realtime scheduling in the Linux kernel.<br />
</s><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 ({{Pkg|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 />
Also try running <br />
$ fuser /dev/snd/*<br />
and check the resulting PID's with<br />
$ ps ax | grep [PID here]<br />
This will hopefully show the conflicting programs.<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>Smogehttps://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=377912JACK Audio Connection Kit2015-06-08T18:24:13Z<p>Smoge: /* Details of the Shell-Based Example Setup */</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://www.linux-magazine.com/content/download/63041/486886/version/1/file/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 />
{{Warning|Be careful when using schedtool! DO NOT change scheduling policies of GUI applications, this will not make any good for audio... In fact this can make things worse}}<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 />
qjackctl &<br />
sleep 10<br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
sleep 10<br />
yoshimi -S &<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 />
<s> sudo schedtool -R -p 20 `pidof qjackctl`<br />
Set qjackctl to realtime scheduling in the Linux kernel. </s> <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 />
<s> sudo schedtool -R -p 20 `pidof qmidiroute`<br />
Set qmidiroute to realtime scheduling in the Linux kernel.</s><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 />
<s> sudo schedtool -R -p 20 `pidof yoshimi`<br />
Set Yoshimi to realtime scheduling in the Linux kernel.<s/><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 ({{Pkg|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 />
Also try running <br />
$ fuser /dev/snd/*<br />
and check the resulting PID's with<br />
$ ps ax | grep [PID here]<br />
This will hopefully show the conflicting programs.<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>Smogehttps://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=377911JACK Audio Connection Kit2015-06-08T18:22:49Z<p>Smoge: /* Details of the Shell-Based Example Setup */</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://www.linux-magazine.com/content/download/63041/486886/version/1/file/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 />
{{Warning|Be careful when using schedtool! DO NOT change scheduling policies of GUI applications, this will not make any good for audio... In fact this can make things worse}}<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 />
qjackctl &<br />
sleep 10<br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
sleep 10<br />
yoshimi -S &<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 />
<s>Wait for the above to settle.<br />
sudo schedtool -R -p 20 `pidof qjackctl`</s><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 />
<s>Wait for the above to settle.<br />
sudo schedtool -R -p 20 `pidof qmidiroute`</s><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 />
<s>Wait for the above to settle.<br />
sudo schedtool -R -p 20 `pidof yoshimi`</s><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 ({{Pkg|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 />
Also try running <br />
$ fuser /dev/snd/*<br />
and check the resulting PID's with<br />
$ ps ax | grep [PID here]<br />
This will hopefully show the conflicting programs.<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>Smogehttps://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=377910JACK Audio Connection Kit2015-06-08T18:20:58Z<p>Smoge: /* A Shell-Based Example Setup */</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://www.linux-magazine.com/content/download/63041/486886/version/1/file/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 />
{{Warning|Be careful when using schedtool! DO NOT change scheduling policies of GUI applications, this will not make any good for audio... In fact this can make things worse}}<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 />
qjackctl &<br />
sleep 10<br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
sleep 10<br />
yoshimi -S &<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 ({{Pkg|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 />
Also try running <br />
$ fuser /dev/snd/*<br />
and check the resulting PID's with<br />
$ ps ax | grep [PID here]<br />
This will hopefully show the conflicting programs.<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>Smogehttps://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=377909JACK Audio Connection Kit2015-06-08T18:20:12Z<p>Smoge: </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://www.linux-magazine.com/content/download/63041/486886/version/1/file/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 />
{{Warning|Be careful with using schedtool! DO NOT change scheduling policies of GUI applications, this will not make any good for audio... In fact this can make things worse}}<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 />
qjackctl &<br />
sleep 10<br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
sleep 10<br />
yoshimi -S &<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 ({{Pkg|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 />
Also try running <br />
$ fuser /dev/snd/*<br />
and check the resulting PID's with<br />
$ ps ax | grep [PID here]<br />
This will hopefully show the conflicting programs.<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>Smogehttps://wiki.archlinux.org/index.php?title=JACK_Audio_Connection_Kit&diff=377908JACK Audio Connection Kit2015-06-08T18:18:03Z<p>Smoge: </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://www.linux-magazine.com/content/download/63041/486886/version/1/file/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 />
{{Warning|Be careful with using schedtool! DO NOT change scheduling policies of GUI application, this will not make any good for audio, in fact this can make things worse}}<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 />
qjackctl &<br />
sleep 10<br />
qmidiroute /home/username/All2MIDI1.qmr &<br />
sleep 10<br />
yoshimi -S &<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 ({{Pkg|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 />
Also try running <br />
$ fuser /dev/snd/*<br />
and check the resulting PID's with<br />
$ ps ax | grep [PID here]<br />
This will hopefully show the conflicting programs.<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>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=229132Professional audio2012-10-16T23:29:43Z<p>Smoge: /* AUR */</p>
<hr />
<div>[[Category:Audio/Video]]<br />
{{Expansion|describe irqbalance}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Information on using Arch Linux for (semi-)professional audio}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary wiki|envy24control}}<br />
{{Article summary link|ArchAudio|http://archaudio.org/}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your (semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration. You could even run an industrial laser alongside your ''DAW'' (Digital audio workstation).<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt their very own dedicated machines for recording, mixing, mastering, sound-design, DSP programming, and what have you. More often than not, when a "linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown what has led to such fallacious thinking, but needless to say, "compiling", "learning" and "performance" have as much to do with each other as "differences in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, ''you just work'' ™. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S jack # or jack2, recommended if you have a multicore cpu<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi<br />
<br />
Additionally, if you are a '''multilib''' user of '''jack''' (which is jack1) on ''x86_64'' and you need a 32-bit version of the library (if not already installed by another hybrid package as a dependency):<br />
<br />
# pacman -S lib32-jack<br />
<br />
For '''jack2''', there is no need to install anything else, as there is '''jack2-multilib''' which should already be installed if you enabled the repository.<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* Traverso<br />
* [[Linuxsampler|QSampler]]<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
{{Tip|You may want to consider the following often seen system optimizations:<br />
- Install {{AUR|linux-rt}} kernel and include ''threadirqs'' in your kernel boot line (also possible with regular kernels >&#61;2.6.39).<br><br />
- Install the {{AUR|systemd-rtirq}} package and enable it with <br />
# systemctl enable rtirq<br />
- Add yourself to the ''audio'' [[Groups#Groups|group]].<br><br />
- Set the [[cpufreq]] governor to ''performance''.<br><br />
- Add ''noatime'' to the [[fstab|filesystem mount options]]; (see [[Maximizing_Performance#Mount_options|Maximizing Performance]].)<br><br />
<br />
Realtime configuration has mostly been automated. There is no longer any need to edit files like {{ic|/etc/security/limits.conf}} for realtime access. However, if you must change the settings, see {{ic|/etc/security/limits.d/99-audio.conf}} and {{ic|/lib/udev/rules.d/40-hpet-permissions.rules}} (these files are provided by {{pkg|jack}}). Additionaly, you may want to increase the highest requested RTC interrupt frequency (default is 64 Hz) by adding to {{ic|/etc/rc.local}} something like this:<br />
echo 2048 > /sys/class/rtc/rtc0/max_user_freq<br />
echo 2048 > /proc/sys/dev/hpet/max-user-freq<br />
<br />
By default, swap frequency defined by "swappiness" is set to 60. By reducing this number to 10, the system will wait much longer before trying to write to disk.<br />
Then, there's ''inotify'' which watches for changes to files and reports them to applications requesting this information. When working with lots of audio data, a lot of watches will need to be kept track of, so they will need to be increased.<br />
These two settings can be adjusted in {{ic|/etc/sysctl.conf}} (file owned by {{pkg|procps}}).<br />
vm.swappiness &#61; 10<br />
fs.inotify.max_user_watches &#61; 524288<br />
You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).<br />
$ setpci -v -d *:* latency_timer&#61;'''b0'''<br />
$ setpci -v -s ''$SOUND_CARD_PCI_ID'' latency_timer&#61;'''ff''' # eg. SOUND_CARD_PCI_ID&#61;03:00.0 (see below)<br />
The SOUND_CARD_PCI_ID can be obtained like so:<br />
$ lspci &#166; grep -i audio<br />
'''03:00.0''' Multimedia audio controller: Creative Labs SB Audigy (rev 03)<br />
'''03:01.0''' Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)<br />
}}<br />
<br />
The steps below are mostly to double-check that you have a working multimedia system:<br />
* Have I set up sound properly? See [[ALSA]] or [[OSS]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]] or [[OSS]].<br />
<br />
$ groups | grep audio<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device?<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. '''Frames/Period = 256''' is a sane starter. For onboard and USB devices, try '''Periods/Buffer = 3'''. Commonly used values are: 256/3, 256/2, 128/3.<br />
<br />
Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. Others include 44100 and 96000.<br />
<br />
Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in {{ic|/etc/security/limits.d/99-audio.conf}}); the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
{{pkg|QJackCtl}} and {{pkg|Patchage}} are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
{{Note|Once you set up JACK, try different audio applications to test your configuration results. I spent days trying to troubleshoot JACK xrun issues with LMMS which in the end turned out to be the problem with the latter.}}<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== JACK2 ====<br />
<br />
For jack2 you do not need qjackctl at all. You can use a lightweight alternative with less features. Applications like ardour or patchage already take care of client connections and smoothly adjusting the buffer size.<br />
<br />
==== FireWire ====<br />
{{Note|Nothing much is needed to be done as most things have been automated, especially with the introduction of the [https://ieee1394.wiki.kernel.org/articles/j/u/j/Juju_Migration_e8a6.html new FireWire stack], deprecation of [[HAL]] and more focus on [[udev]]. You should not need to edit device permissions, but if you suspect that your device may not be working due to such issues, see {{ic|/lib/udev/rules.d/60-ffado.rules}} and if needed, create and put your changes into {{ic|/etc/udev/rules.d/60-ffado.rules}}. Most often than not, your device will work with the {{AUR|libffado-svn}} development version of the driver].}}<br />
<br />
JACK(2) is built against FFADO, you only need to install it:<br />
<br />
# pacman -S libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) {{Ic|/etc/asound.conf}} (system wide settings) to have these lines:<br />
<br />
{{Bc|<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 />
}<br />
}}<br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of knobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [https://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
=== A General Example ===<br />
<br />
A general configuration example is [[JACK Audio Connection Kit#An Example of Startup and Configuration|here]].<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with {{Ic|CONFIG_PREEMPT&#61;y}}, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
{{note|Before you decide to use a patched kernel, see [http://jackaudio.org/realtime_vs_realtime_kernel http://jackaudio.org/realtime_vs_realtime_kernel].}}<br />
<br />
=== ABS ===<br />
<br />
You can use [[ABS]] to recompile {{Pkg|linux}} with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel (at least you should add {{Ic|linux}} to {{Ic|IgnorePkg}} array in {{Ic|/etc/rc.conf}}.<br />
<br />
=== AUR ===<br />
<br />
From the [[AUR]] itself, you have the following options:<br />
<br />
* {{AUR|linux-rt}}<br />
* {{AUR|linux-rt-lts}} (Long Term Support, stable release)<br />
* {{AUR|linux-rt-ice}}<br />
<br />
The first two are standard kernels with the CONFIG_PREEMPT_RT patch, while -ice includes patches some may consider to be nasty, while to others are a blessing.<br />
:''See: [https://rt.wiki.kernel.org/ Real-Time Linux Wiki]''<br />
<br />
== MIDI ==<br />
<br />
To work with MIDI you can it is highly recommended that you install a2j, a bridge between alsa midi and jack midi. It allows you to connect applications that only communicate with alsa midi to applications that only use jack midi. Laditray can also start/stop a2j.<br />
:''See: [[JACK#MIDI]]''<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a realtime or a recent kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads. Also available as {{AUR|systemd-rtirq}}.<br />
<br />
* Do not use the '''irqbalance''' daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
$ ls /var/run/daemons<br />
$ top # or htop, ps aux, whatever you are comfortable with<br />
$ killall -9 $processname<br />
# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with {{Pkg|nvidia}}, disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
The M-Audio Delta series cards are based on the VIA Ice1712 audio chipset.<br />
Cards using this chip require that you install the alsa-tools package, because <br />
it contains the [[envy24control]] program. [[Envy24control]] is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
$ envy24control<br />
<br />
This application can be more than a bit confusing; see [[envy24control]] for guidance<br />
on its use. That said, here is a very simple working setup for multitracking with Ardour.<br />
<br />
# On the "Monitor Inputs" and "Monitor PCMs" tabs, set all monitor inputs and monitor PCM's to around 20.<br />
# On the "Patchbay / Router" tab, set all to PCM out.<br />
# On the "Hardware Settings" tab, verify that the Master Clock setting matches what is set in Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== M-Audio Fast Track Pro ===<br />
<br />
The M-Audio Fast Track Pro is an USB 4x4 audio interface, working at 24bit/96kHz. Due to limitation of USB 1, this device requires additional setup to get access to all its features. Device works in one of two configuration:<br />
<br />
* Configuration 1, or "Class compliant mode" - with reduced functionality, only 16bit, 48kHz, analogue input (2 channels) and digital/analogue output (4 channels).<br />
* Configuration 2 - with access to all features of interface.<br />
<br />
Currently with stock kernel it runs in configuration 2, but if you want to make sure in what mode you are, you can check kernel log for entries:<br />
<br />
{{bc|<br />
usb-audio: Fast Track Pro switching to config #2<br />
usb-audio: Fast Track Pro config OK<br />
}}<br />
<br />
The interface also needs extra step of cofiguration to switch modes. It is done using option {{ic|device_setup}} during module loading. The recommended way to setup the interface is using file in {{ic|modprobe.d}}:<br />
{{hc|/etc/modprobe.d/ftp.conf|<nowiki><br />
options snd_usb_audio vid=0x763 pid=0x2012 device_setup=XXX index=YYY enable=1<br />
</nowiki>}}<br />
where {{ic|vid}} and {{ic|pid}} are vendor and product id for M-Audio Fast Track Pro, {{ic|index}} is desired device number and {{ic|device_setup}} is desired device setup. Possible values for {{ic|device_setup}} are:<br />
{| border="1"<br />
|+ device modes<br />
! device_setup value !! bit depth !! frequency !! analog output !! digital output !! analog input !! digital input !! IO mode<br />
|-<br />
| 0x0 || 16 bit || 48kHz || + || + || + || + || 4x4<br />
|-<br />
| 0x9 || 24 bit || 48kHz || + || + || + || - || 2x4<br />
|-<br />
| 0x13 || 24 bit || 48kHz || + || + || - || + || 2x4<br />
|-<br />
| 0x5 || 24 bit || 96kHz || * || * || * || * || 2x0 or 0x2<br />
|}<br />
<br />
The 24 bit/96kHz mode is special: it provides all input/output, but you can open only one of 4 interfaces at a time. If you for example open output interface and then try to open second output or input interface, you will see error in kernel log:<br />
{{bc|<br />
cannot submit datapipe for urb 0, error -28: not enough bandwidth<br />
}}<br />
which is perfectly normal, because this is USB 1 device and cannot provide enough bandwidth to support more than single (2 channel) destination/source of that quality at a time.<br />
<br />
Depending on the value of {{ic|index}} it will setup two devices: {{ic|hwYYY:0}} and {{ic|hwYYY:1}}, which will contain available inputs and outputs. First device is most likely to contain analog output and digital input, while second one will contain analog input and digital output. To find out which devices are linked where and if they are setup correctly, you can check {{ic|/proc/asound/cardYYY/stream{0,1} }}. Below is list of important endpoints that will help in correctly identifying card connections (it easy to mistake analog and digital input or output connections before you get used to the device):<br />
<br />
{{bc|<nowiki><br />
EP 3 (analgoue output = TRS on back, mirrored on RCA outputs 1 and 2 on back)<br />
EP 4 (digital output = S/PDIF output on back, mirrored on RCA outputs 3 and 4 on back)<br />
EP 5 (analogue input = balanced TRS or XLR microphone, unbalanced TS line on front)<br />
EP 6 (digital input = S/PDIF input on back)<br />
</nowiki>}}<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from command line or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10 channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[https://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio].<br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: https://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
For all your Arch- and ArchAudio-related audio issues hop on to '''IRC''': #archaudio @ Freenode<br />
<br />
== Linux and Arch Linux Pro Audio in the News ==<br />
* [http://www.linuxjournal.com/content/arch-tale An Arch Tale] - Article by fellow musician and writer Dave Phillips, October 2011<br />
<br />
* [http://www.itwire.com/opinion-and-analysis/open-sauce/36698-from-windows-to-linux-a-sound-decision From Windows to Linux: a sound decision] - Interview with Geoff "songshop" Beasley, February 2010</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=229131Professional audio2012-10-16T23:28:19Z<p>Smoge: /* System Configuration */</p>
<hr />
<div>[[Category:Audio/Video]]<br />
{{Expansion|describe irqbalance}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Information on using Arch Linux for (semi-)professional audio}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary wiki|envy24control}}<br />
{{Article summary link|ArchAudio|http://archaudio.org/}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your (semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration. You could even run an industrial laser alongside your ''DAW'' (Digital audio workstation).<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt their very own dedicated machines for recording, mixing, mastering, sound-design, DSP programming, and what have you. More often than not, when a "linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown what has led to such fallacious thinking, but needless to say, "compiling", "learning" and "performance" have as much to do with each other as "differences in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, ''you just work'' ™. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S jack # or jack2, recommended if you have a multicore cpu<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi<br />
<br />
Additionally, if you are a '''multilib''' user of '''jack''' (which is jack1) on ''x86_64'' and you need a 32-bit version of the library (if not already installed by another hybrid package as a dependency):<br />
<br />
# pacman -S lib32-jack<br />
<br />
For '''jack2''', there is no need to install anything else, as there is '''jack2-multilib''' which should already be installed if you enabled the repository.<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* Traverso<br />
* [[Linuxsampler|QSampler]]<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
{{Tip|You may want to consider the following often seen system optimizations:<br />
- Install {{AUR|linux-rt}} kernel and include ''threadirqs'' in your kernel boot line (also possible with regular kernels >&#61;2.6.39).<br><br />
- Install the {{AUR|systemd-rtirq}} package and enable it with <br />
# systemctl enable rtirq<br />
- Add yourself to the ''audio'' [[Groups#Groups|group]].<br><br />
- Set the [[cpufreq]] governor to ''performance''.<br><br />
- Add ''noatime'' to the [[fstab|filesystem mount options]]; (see [[Maximizing_Performance#Mount_options|Maximizing Performance]].)<br><br />
<br />
Realtime configuration has mostly been automated. There is no longer any need to edit files like {{ic|/etc/security/limits.conf}} for realtime access. However, if you must change the settings, see {{ic|/etc/security/limits.d/99-audio.conf}} and {{ic|/lib/udev/rules.d/40-hpet-permissions.rules}} (these files are provided by {{pkg|jack}}). Additionaly, you may want to increase the highest requested RTC interrupt frequency (default is 64 Hz) by adding to {{ic|/etc/rc.local}} something like this:<br />
echo 2048 > /sys/class/rtc/rtc0/max_user_freq<br />
echo 2048 > /proc/sys/dev/hpet/max-user-freq<br />
<br />
By default, swap frequency defined by "swappiness" is set to 60. By reducing this number to 10, the system will wait much longer before trying to write to disk.<br />
Then, there's ''inotify'' which watches for changes to files and reports them to applications requesting this information. When working with lots of audio data, a lot of watches will need to be kept track of, so they will need to be increased.<br />
These two settings can be adjusted in {{ic|/etc/sysctl.conf}} (file owned by {{pkg|procps}}).<br />
vm.swappiness &#61; 10<br />
fs.inotify.max_user_watches &#61; 524288<br />
You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).<br />
$ setpci -v -d *:* latency_timer&#61;'''b0'''<br />
$ setpci -v -s ''$SOUND_CARD_PCI_ID'' latency_timer&#61;'''ff''' # eg. SOUND_CARD_PCI_ID&#61;03:00.0 (see below)<br />
The SOUND_CARD_PCI_ID can be obtained like so:<br />
$ lspci &#166; grep -i audio<br />
'''03:00.0''' Multimedia audio controller: Creative Labs SB Audigy (rev 03)<br />
'''03:01.0''' Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)<br />
}}<br />
<br />
The steps below are mostly to double-check that you have a working multimedia system:<br />
* Have I set up sound properly? See [[ALSA]] or [[OSS]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]] or [[OSS]].<br />
<br />
$ groups | grep audio<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device?<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. '''Frames/Period = 256''' is a sane starter. For onboard and USB devices, try '''Periods/Buffer = 3'''. Commonly used values are: 256/3, 256/2, 128/3.<br />
<br />
Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. Others include 44100 and 96000.<br />
<br />
Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in {{ic|/etc/security/limits.d/99-audio.conf}}); the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
{{pkg|QJackCtl}} and {{pkg|Patchage}} are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
{{Note|Once you set up JACK, try different audio applications to test your configuration results. I spent days trying to troubleshoot JACK xrun issues with LMMS which in the end turned out to be the problem with the latter.}}<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== JACK2 ====<br />
<br />
For jack2 you do not need qjackctl at all. You can use a lightweight alternative with less features. Applications like ardour or patchage already take care of client connections and smoothly adjusting the buffer size.<br />
<br />
==== FireWire ====<br />
{{Note|Nothing much is needed to be done as most things have been automated, especially with the introduction of the [https://ieee1394.wiki.kernel.org/articles/j/u/j/Juju_Migration_e8a6.html new FireWire stack], deprecation of [[HAL]] and more focus on [[udev]]. You should not need to edit device permissions, but if you suspect that your device may not be working due to such issues, see {{ic|/lib/udev/rules.d/60-ffado.rules}} and if needed, create and put your changes into {{ic|/etc/udev/rules.d/60-ffado.rules}}. Most often than not, your device will work with the {{AUR|libffado-svn}} development version of the driver].}}<br />
<br />
JACK(2) is built against FFADO, you only need to install it:<br />
<br />
# pacman -S libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) {{Ic|/etc/asound.conf}} (system wide settings) to have these lines:<br />
<br />
{{Bc|<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 />
}<br />
}}<br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of knobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [https://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
=== A General Example ===<br />
<br />
A general configuration example is [[JACK Audio Connection Kit#An Example of Startup and Configuration|here]].<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with {{Ic|CONFIG_PREEMPT&#61;y}}, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
{{note|Before you decide to use a patched kernel, see [http://jackaudio.org/realtime_vs_realtime_kernel http://jackaudio.org/realtime_vs_realtime_kernel].}}<br />
<br />
=== ABS ===<br />
<br />
You can use [[ABS]] to recompile {{Pkg|linux}} with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel (at least you should add {{Ic|linux}} to {{Ic|IgnorePkg}} array in {{Ic|/etc/rc.conf}}.<br />
<br />
=== AUR ===<br />
<br />
From the [[AUR]] itself, you have the following options:<br />
<br />
* {{AUR|linux-rt}}<br />
* {{AUR|linux-rt-lts}} (Long Term Support; older, stable release)<br />
* {{AUR|linux-rt-ice}}<br />
<br />
The first two are standard kernels with the CONFIG_PREEMPT_RT patch, while -ice includes patches some may consider to be nasty, while to others are a blessing.<br />
:''See: [https://rt.wiki.kernel.org/ Real-Time Linux Wiki]''<br />
<br />
== MIDI ==<br />
<br />
To work with MIDI you can it is highly recommended that you install a2j, a bridge between alsa midi and jack midi. It allows you to connect applications that only communicate with alsa midi to applications that only use jack midi. Laditray can also start/stop a2j.<br />
:''See: [[JACK#MIDI]]''<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a realtime or a recent kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads. Also available as {{AUR|systemd-rtirq}}.<br />
<br />
* Do not use the '''irqbalance''' daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
$ ls /var/run/daemons<br />
$ top # or htop, ps aux, whatever you are comfortable with<br />
$ killall -9 $processname<br />
# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with {{Pkg|nvidia}}, disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
The M-Audio Delta series cards are based on the VIA Ice1712 audio chipset.<br />
Cards using this chip require that you install the alsa-tools package, because <br />
it contains the [[envy24control]] program. [[Envy24control]] is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
$ envy24control<br />
<br />
This application can be more than a bit confusing; see [[envy24control]] for guidance<br />
on its use. That said, here is a very simple working setup for multitracking with Ardour.<br />
<br />
# On the "Monitor Inputs" and "Monitor PCMs" tabs, set all monitor inputs and monitor PCM's to around 20.<br />
# On the "Patchbay / Router" tab, set all to PCM out.<br />
# On the "Hardware Settings" tab, verify that the Master Clock setting matches what is set in Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== M-Audio Fast Track Pro ===<br />
<br />
The M-Audio Fast Track Pro is an USB 4x4 audio interface, working at 24bit/96kHz. Due to limitation of USB 1, this device requires additional setup to get access to all its features. Device works in one of two configuration:<br />
<br />
* Configuration 1, or "Class compliant mode" - with reduced functionality, only 16bit, 48kHz, analogue input (2 channels) and digital/analogue output (4 channels).<br />
* Configuration 2 - with access to all features of interface.<br />
<br />
Currently with stock kernel it runs in configuration 2, but if you want to make sure in what mode you are, you can check kernel log for entries:<br />
<br />
{{bc|<br />
usb-audio: Fast Track Pro switching to config #2<br />
usb-audio: Fast Track Pro config OK<br />
}}<br />
<br />
The interface also needs extra step of cofiguration to switch modes. It is done using option {{ic|device_setup}} during module loading. The recommended way to setup the interface is using file in {{ic|modprobe.d}}:<br />
{{hc|/etc/modprobe.d/ftp.conf|<nowiki><br />
options snd_usb_audio vid=0x763 pid=0x2012 device_setup=XXX index=YYY enable=1<br />
</nowiki>}}<br />
where {{ic|vid}} and {{ic|pid}} are vendor and product id for M-Audio Fast Track Pro, {{ic|index}} is desired device number and {{ic|device_setup}} is desired device setup. Possible values for {{ic|device_setup}} are:<br />
{| border="1"<br />
|+ device modes<br />
! device_setup value !! bit depth !! frequency !! analog output !! digital output !! analog input !! digital input !! IO mode<br />
|-<br />
| 0x0 || 16 bit || 48kHz || + || + || + || + || 4x4<br />
|-<br />
| 0x9 || 24 bit || 48kHz || + || + || + || - || 2x4<br />
|-<br />
| 0x13 || 24 bit || 48kHz || + || + || - || + || 2x4<br />
|-<br />
| 0x5 || 24 bit || 96kHz || * || * || * || * || 2x0 or 0x2<br />
|}<br />
<br />
The 24 bit/96kHz mode is special: it provides all input/output, but you can open only one of 4 interfaces at a time. If you for example open output interface and then try to open second output or input interface, you will see error in kernel log:<br />
{{bc|<br />
cannot submit datapipe for urb 0, error -28: not enough bandwidth<br />
}}<br />
which is perfectly normal, because this is USB 1 device and cannot provide enough bandwidth to support more than single (2 channel) destination/source of that quality at a time.<br />
<br />
Depending on the value of {{ic|index}} it will setup two devices: {{ic|hwYYY:0}} and {{ic|hwYYY:1}}, which will contain available inputs and outputs. First device is most likely to contain analog output and digital input, while second one will contain analog input and digital output. To find out which devices are linked where and if they are setup correctly, you can check {{ic|/proc/asound/cardYYY/stream{0,1} }}. Below is list of important endpoints that will help in correctly identifying card connections (it easy to mistake analog and digital input or output connections before you get used to the device):<br />
<br />
{{bc|<nowiki><br />
EP 3 (analgoue output = TRS on back, mirrored on RCA outputs 1 and 2 on back)<br />
EP 4 (digital output = S/PDIF output on back, mirrored on RCA outputs 3 and 4 on back)<br />
EP 5 (analogue input = balanced TRS or XLR microphone, unbalanced TS line on front)<br />
EP 6 (digital input = S/PDIF input on back)<br />
</nowiki>}}<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from command line or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10 channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[https://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio].<br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: https://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
For all your Arch- and ArchAudio-related audio issues hop on to '''IRC''': #archaudio @ Freenode<br />
<br />
== Linux and Arch Linux Pro Audio in the News ==<br />
* [http://www.linuxjournal.com/content/arch-tale An Arch Tale] - Article by fellow musician and writer Dave Phillips, October 2011<br />
<br />
* [http://www.itwire.com/opinion-and-analysis/open-sauce/36698-from-windows-to-linux-a-sound-decision From Windows to Linux: a sound decision] - Interview with Geoff "songshop" Beasley, February 2010</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=229130Professional audio2012-10-16T23:27:25Z<p>Smoge: /* Tips and Tricks */</p>
<hr />
<div>[[Category:Audio/Video]]<br />
{{Expansion|describe irqbalance}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Information on using Arch Linux for (semi-)professional audio}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary wiki|envy24control}}<br />
{{Article summary link|ArchAudio|http://archaudio.org/}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your (semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration. You could even run an industrial laser alongside your ''DAW'' (Digital audio workstation).<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt their very own dedicated machines for recording, mixing, mastering, sound-design, DSP programming, and what have you. More often than not, when a "linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown what has led to such fallacious thinking, but needless to say, "compiling", "learning" and "performance" have as much to do with each other as "differences in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, ''you just work'' ™. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S jack # or jack2, recommended if you have a multicore cpu<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi<br />
<br />
Additionally, if you are a '''multilib''' user of '''jack''' (which is jack1) on ''x86_64'' and you need a 32-bit version of the library (if not already installed by another hybrid package as a dependency):<br />
<br />
# pacman -S lib32-jack<br />
<br />
For '''jack2''', there is no need to install anything else, as there is '''jack2-multilib''' which should already be installed if you enabled the repository.<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* Traverso<br />
* [[Linuxsampler|QSampler]]<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
{{Tip|You may want to consider the following often seen system optimizations:<br />
- Install {{AUR|linux-rt}} kernel and include ''threadirqs'' in your kernel boot line (>&#61;2.6.39).<br><br />
- Install the {{AUR|systemd-rtirq}} package and enable it with <br />
# systemctl enable rtirq<br />
- Add yourself to the ''audio'' [[Groups#Groups|group]].<br><br />
- Set the [[cpufreq]] governor to ''performance''.<br><br />
- Add ''noatime'' to the [[fstab|filesystem mount options]]; (see [[Maximizing_Performance#Mount_options|Maximizing Performance]].)<br><br />
<br />
Realtime configuration has mostly been automated. There is no longer any need to edit files like {{ic|/etc/security/limits.conf}} for realtime access. However, if you must change the settings, see {{ic|/etc/security/limits.d/99-audio.conf}} and {{ic|/lib/udev/rules.d/40-hpet-permissions.rules}} (these files are provided by {{pkg|jack}}). Additionaly, you may want to increase the highest requested RTC interrupt frequency (default is 64 Hz) by adding to {{ic|/etc/rc.local}} something like this:<br />
echo 2048 > /sys/class/rtc/rtc0/max_user_freq<br />
echo 2048 > /proc/sys/dev/hpet/max-user-freq<br />
<br />
By default, swap frequency defined by "swappiness" is set to 60. By reducing this number to 10, the system will wait much longer before trying to write to disk.<br />
Then, there's ''inotify'' which watches for changes to files and reports them to applications requesting this information. When working with lots of audio data, a lot of watches will need to be kept track of, so they will need to be increased.<br />
These two settings can be adjusted in {{ic|/etc/sysctl.conf}} (file owned by {{pkg|procps}}).<br />
vm.swappiness &#61; 10<br />
fs.inotify.max_user_watches &#61; 524288<br />
You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).<br />
$ setpci -v -d *:* latency_timer&#61;'''b0'''<br />
$ setpci -v -s ''$SOUND_CARD_PCI_ID'' latency_timer&#61;'''ff''' # eg. SOUND_CARD_PCI_ID&#61;03:00.0 (see below)<br />
The SOUND_CARD_PCI_ID can be obtained like so:<br />
$ lspci &#166; grep -i audio<br />
'''03:00.0''' Multimedia audio controller: Creative Labs SB Audigy (rev 03)<br />
'''03:01.0''' Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)<br />
}}<br />
<br />
The steps below are mostly to double-check that you have a working multimedia system:<br />
* Have I set up sound properly? See [[ALSA]] or [[OSS]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]] or [[OSS]].<br />
<br />
$ groups | grep audio<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device?<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. '''Frames/Period = 256''' is a sane starter. For onboard and USB devices, try '''Periods/Buffer = 3'''. Commonly used values are: 256/3, 256/2, 128/3.<br />
<br />
Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. Others include 44100 and 96000.<br />
<br />
Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in {{ic|/etc/security/limits.d/99-audio.conf}}); the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
{{pkg|QJackCtl}} and {{pkg|Patchage}} are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
{{Note|Once you set up JACK, try different audio applications to test your configuration results. I spent days trying to troubleshoot JACK xrun issues with LMMS which in the end turned out to be the problem with the latter.}}<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== JACK2 ====<br />
<br />
For jack2 you do not need qjackctl at all. You can use a lightweight alternative with less features. Applications like ardour or patchage already take care of client connections and smoothly adjusting the buffer size.<br />
<br />
==== FireWire ====<br />
{{Note|Nothing much is needed to be done as most things have been automated, especially with the introduction of the [https://ieee1394.wiki.kernel.org/articles/j/u/j/Juju_Migration_e8a6.html new FireWire stack], deprecation of [[HAL]] and more focus on [[udev]]. You should not need to edit device permissions, but if you suspect that your device may not be working due to such issues, see {{ic|/lib/udev/rules.d/60-ffado.rules}} and if needed, create and put your changes into {{ic|/etc/udev/rules.d/60-ffado.rules}}. Most often than not, your device will work with the {{AUR|libffado-svn}} development version of the driver].}}<br />
<br />
JACK(2) is built against FFADO, you only need to install it:<br />
<br />
# pacman -S libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) {{Ic|/etc/asound.conf}} (system wide settings) to have these lines:<br />
<br />
{{Bc|<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 />
}<br />
}}<br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of knobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [https://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
=== A General Example ===<br />
<br />
A general configuration example is [[JACK Audio Connection Kit#An Example of Startup and Configuration|here]].<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with {{Ic|CONFIG_PREEMPT&#61;y}}, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
{{note|Before you decide to use a patched kernel, see [http://jackaudio.org/realtime_vs_realtime_kernel http://jackaudio.org/realtime_vs_realtime_kernel].}}<br />
<br />
=== ABS ===<br />
<br />
You can use [[ABS]] to recompile {{Pkg|linux}} with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel (at least you should add {{Ic|linux}} to {{Ic|IgnorePkg}} array in {{Ic|/etc/rc.conf}}.<br />
<br />
=== AUR ===<br />
<br />
From the [[AUR]] itself, you have the following options:<br />
<br />
* {{AUR|linux-rt}}<br />
* {{AUR|linux-rt-lts}} (Long Term Support; older, stable release)<br />
* {{AUR|linux-rt-ice}}<br />
<br />
The first two are standard kernels with the CONFIG_PREEMPT_RT patch, while -ice includes patches some may consider to be nasty, while to others are a blessing.<br />
:''See: [https://rt.wiki.kernel.org/ Real-Time Linux Wiki]''<br />
<br />
== MIDI ==<br />
<br />
To work with MIDI you can it is highly recommended that you install a2j, a bridge between alsa midi and jack midi. It allows you to connect applications that only communicate with alsa midi to applications that only use jack midi. Laditray can also start/stop a2j.<br />
:''See: [[JACK#MIDI]]''<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a realtime or a recent kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads. Also available as {{AUR|systemd-rtirq}}.<br />
<br />
* Do not use the '''irqbalance''' daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
$ ls /var/run/daemons<br />
$ top # or htop, ps aux, whatever you are comfortable with<br />
$ killall -9 $processname<br />
# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with {{Pkg|nvidia}}, disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
The M-Audio Delta series cards are based on the VIA Ice1712 audio chipset.<br />
Cards using this chip require that you install the alsa-tools package, because <br />
it contains the [[envy24control]] program. [[Envy24control]] is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
$ envy24control<br />
<br />
This application can be more than a bit confusing; see [[envy24control]] for guidance<br />
on its use. That said, here is a very simple working setup for multitracking with Ardour.<br />
<br />
# On the "Monitor Inputs" and "Monitor PCMs" tabs, set all monitor inputs and monitor PCM's to around 20.<br />
# On the "Patchbay / Router" tab, set all to PCM out.<br />
# On the "Hardware Settings" tab, verify that the Master Clock setting matches what is set in Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== M-Audio Fast Track Pro ===<br />
<br />
The M-Audio Fast Track Pro is an USB 4x4 audio interface, working at 24bit/96kHz. Due to limitation of USB 1, this device requires additional setup to get access to all its features. Device works in one of two configuration:<br />
<br />
* Configuration 1, or "Class compliant mode" - with reduced functionality, only 16bit, 48kHz, analogue input (2 channels) and digital/analogue output (4 channels).<br />
* Configuration 2 - with access to all features of interface.<br />
<br />
Currently with stock kernel it runs in configuration 2, but if you want to make sure in what mode you are, you can check kernel log for entries:<br />
<br />
{{bc|<br />
usb-audio: Fast Track Pro switching to config #2<br />
usb-audio: Fast Track Pro config OK<br />
}}<br />
<br />
The interface also needs extra step of cofiguration to switch modes. It is done using option {{ic|device_setup}} during module loading. The recommended way to setup the interface is using file in {{ic|modprobe.d}}:<br />
{{hc|/etc/modprobe.d/ftp.conf|<nowiki><br />
options snd_usb_audio vid=0x763 pid=0x2012 device_setup=XXX index=YYY enable=1<br />
</nowiki>}}<br />
where {{ic|vid}} and {{ic|pid}} are vendor and product id for M-Audio Fast Track Pro, {{ic|index}} is desired device number and {{ic|device_setup}} is desired device setup. Possible values for {{ic|device_setup}} are:<br />
{| border="1"<br />
|+ device modes<br />
! device_setup value !! bit depth !! frequency !! analog output !! digital output !! analog input !! digital input !! IO mode<br />
|-<br />
| 0x0 || 16 bit || 48kHz || + || + || + || + || 4x4<br />
|-<br />
| 0x9 || 24 bit || 48kHz || + || + || + || - || 2x4<br />
|-<br />
| 0x13 || 24 bit || 48kHz || + || + || - || + || 2x4<br />
|-<br />
| 0x5 || 24 bit || 96kHz || * || * || * || * || 2x0 or 0x2<br />
|}<br />
<br />
The 24 bit/96kHz mode is special: it provides all input/output, but you can open only one of 4 interfaces at a time. If you for example open output interface and then try to open second output or input interface, you will see error in kernel log:<br />
{{bc|<br />
cannot submit datapipe for urb 0, error -28: not enough bandwidth<br />
}}<br />
which is perfectly normal, because this is USB 1 device and cannot provide enough bandwidth to support more than single (2 channel) destination/source of that quality at a time.<br />
<br />
Depending on the value of {{ic|index}} it will setup two devices: {{ic|hwYYY:0}} and {{ic|hwYYY:1}}, which will contain available inputs and outputs. First device is most likely to contain analog output and digital input, while second one will contain analog input and digital output. To find out which devices are linked where and if they are setup correctly, you can check {{ic|/proc/asound/cardYYY/stream{0,1} }}. Below is list of important endpoints that will help in correctly identifying card connections (it easy to mistake analog and digital input or output connections before you get used to the device):<br />
<br />
{{bc|<nowiki><br />
EP 3 (analgoue output = TRS on back, mirrored on RCA outputs 1 and 2 on back)<br />
EP 4 (digital output = S/PDIF output on back, mirrored on RCA outputs 3 and 4 on back)<br />
EP 5 (analogue input = balanced TRS or XLR microphone, unbalanced TS line on front)<br />
EP 6 (digital input = S/PDIF input on back)<br />
</nowiki>}}<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from command line or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10 channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[https://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio].<br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: https://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
For all your Arch- and ArchAudio-related audio issues hop on to '''IRC''': #archaudio @ Freenode<br />
<br />
== Linux and Arch Linux Pro Audio in the News ==<br />
* [http://www.linuxjournal.com/content/arch-tale An Arch Tale] - Article by fellow musician and writer Dave Phillips, October 2011<br />
<br />
* [http://www.itwire.com/opinion-and-analysis/open-sauce/36698-from-windows-to-linux-a-sound-decision From Windows to Linux: a sound decision] - Interview with Geoff "songshop" Beasley, February 2010</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=229129Professional audio2012-10-16T23:26:55Z<p>Smoge: /* Tips and Tricks */</p>
<hr />
<div>[[Category:Audio/Video]]<br />
{{Expansion|describe irqbalance}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Information on using Arch Linux for (semi-)professional audio}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary wiki|envy24control}}<br />
{{Article summary link|ArchAudio|http://archaudio.org/}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your (semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration. You could even run an industrial laser alongside your ''DAW'' (Digital audio workstation).<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt their very own dedicated machines for recording, mixing, mastering, sound-design, DSP programming, and what have you. More often than not, when a "linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown what has led to such fallacious thinking, but needless to say, "compiling", "learning" and "performance" have as much to do with each other as "differences in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, ''you just work'' ™. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S jack # or jack2, recommended if you have a multicore cpu<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi<br />
<br />
Additionally, if you are a '''multilib''' user of '''jack''' (which is jack1) on ''x86_64'' and you need a 32-bit version of the library (if not already installed by another hybrid package as a dependency):<br />
<br />
# pacman -S lib32-jack<br />
<br />
For '''jack2''', there is no need to install anything else, as there is '''jack2-multilib''' which should already be installed if you enabled the repository.<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* Traverso<br />
* [[Linuxsampler|QSampler]]<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
{{Tip|You may want to consider the following often seen system optimizations:<br />
- Install {{AUR|linux-rt}} kernel and include ''threadirqs'' in your kernel boot line (>&#61;2.6.39).<br><br />
- Install the {{AUR|systemd-rtirq}} package and enable it with <br />
# systemctl enable rtirq<br />
- Add yourself to the ''audio'' [[Groups#Groups|group]].<br><br />
- Set the [[cpufreq]] governor to ''performance''.<br><br />
- Add ''noatime'' to the [[fstab|filesystem mount options]]; (see [[Maximizing_Performance#Mount_options|Maximizing Performance]].)<br><br />
<br />
Realtime configuration has mostly been automated. There is no longer any need to edit files like {{ic|/etc/security/limits.conf}} for realtime access. However, if you must change the settings, see {{ic|/etc/security/limits.d/99-audio.conf}} and {{ic|/lib/udev/rules.d/40-hpet-permissions.rules}} (these files are provided by {{pkg|jack}}). Additionaly, you may want to increase the highest requested RTC interrupt frequency (default is 64 Hz) by adding to {{ic|/etc/rc.local}} something like this:<br />
echo 2048 > /sys/class/rtc/rtc0/max_user_freq<br />
echo 2048 > /proc/sys/dev/hpet/max-user-freq<br />
<br />
By default, swap frequency defined by "swappiness" is set to 60. By reducing this number to 10, the system will wait much longer before trying to write to disk.<br />
Then, there's ''inotify'' which watches for changes to files and reports them to applications requesting this information. When working with lots of audio data, a lot of watches will need to be kept track of, so they will need to be increased.<br />
These two settings can be adjusted in {{ic|/etc/sysctl.conf}} (file owned by {{pkg|procps}}).<br />
vm.swappiness &#61; 10<br />
fs.inotify.max_user_watches &#61; 524288<br />
You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).<br />
$ setpci -v -d *:* latency_timer&#61;'''b0'''<br />
$ setpci -v -s ''$SOUND_CARD_PCI_ID'' latency_timer&#61;'''ff''' # eg. SOUND_CARD_PCI_ID&#61;03:00.0 (see below)<br />
The SOUND_CARD_PCI_ID can be obtained like so:<br />
$ lspci &#166; grep -i audio<br />
'''03:00.0''' Multimedia audio controller: Creative Labs SB Audigy (rev 03)<br />
'''03:01.0''' Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)<br />
}}<br />
<br />
The steps below are mostly to double-check that you have a working multimedia system:<br />
* Have I set up sound properly? See [[ALSA]] or [[OSS]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]] or [[OSS]].<br />
<br />
$ groups | grep audio<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device?<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. '''Frames/Period = 256''' is a sane starter. For onboard and USB devices, try '''Periods/Buffer = 3'''. Commonly used values are: 256/3, 256/2, 128/3.<br />
<br />
Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. Others include 44100 and 96000.<br />
<br />
Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in {{ic|/etc/security/limits.d/99-audio.conf}}); the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
{{pkg|QJackCtl}} and {{pkg|Patchage}} are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
{{Note|Once you set up JACK, try different audio applications to test your configuration results. I spent days trying to troubleshoot JACK xrun issues with LMMS which in the end turned out to be the problem with the latter.}}<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== JACK2 ====<br />
<br />
For jack2 you do not need qjackctl at all. You can use a lightweight alternative with less features. Applications like ardour or patchage already take care of client connections and smoothly adjusting the buffer size.<br />
<br />
==== FireWire ====<br />
{{Note|Nothing much is needed to be done as most things have been automated, especially with the introduction of the [https://ieee1394.wiki.kernel.org/articles/j/u/j/Juju_Migration_e8a6.html new FireWire stack], deprecation of [[HAL]] and more focus on [[udev]]. You should not need to edit device permissions, but if you suspect that your device may not be working due to such issues, see {{ic|/lib/udev/rules.d/60-ffado.rules}} and if needed, create and put your changes into {{ic|/etc/udev/rules.d/60-ffado.rules}}. Most often than not, your device will work with the {{AUR|libffado-svn}} development version of the driver].}}<br />
<br />
JACK(2) is built against FFADO, you only need to install it:<br />
<br />
# pacman -S libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) {{Ic|/etc/asound.conf}} (system wide settings) to have these lines:<br />
<br />
{{Bc|<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 />
}<br />
}}<br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of knobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [https://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
=== A General Example ===<br />
<br />
A general configuration example is [[JACK Audio Connection Kit#An Example of Startup and Configuration|here]].<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with {{Ic|CONFIG_PREEMPT&#61;y}}, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
{{note|Before you decide to use a patched kernel, see [http://jackaudio.org/realtime_vs_realtime_kernel http://jackaudio.org/realtime_vs_realtime_kernel].}}<br />
<br />
=== ABS ===<br />
<br />
You can use [[ABS]] to recompile {{Pkg|linux}} with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel (at least you should add {{Ic|linux}} to {{Ic|IgnorePkg}} array in {{Ic|/etc/rc.conf}}.<br />
<br />
=== AUR ===<br />
<br />
From the [[AUR]] itself, you have the following options:<br />
<br />
* {{AUR|linux-rt}}<br />
* {{AUR|linux-rt-lts}} (Long Term Support; older, stable release)<br />
* {{AUR|linux-rt-ice}}<br />
<br />
The first two are standard kernels with the CONFIG_PREEMPT_RT patch, while -ice includes patches some may consider to be nasty, while to others are a blessing.<br />
:''See: [https://rt.wiki.kernel.org/ Real-Time Linux Wiki]''<br />
<br />
== MIDI ==<br />
<br />
To work with MIDI you can it is highly recommended that you install a2j, a bridge between alsa midi and jack midi. It allows you to connect applications that only communicate with alsa midi to applications that only use jack midi. Laditray can also start/stop a2j.<br />
:''See: [[JACK#MIDI]]''<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a realtime or a recent kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads. Also available as in AUR {{AUR|systemd-rtirq}}.<br />
<br />
* Do not use the '''irqbalance''' daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
$ ls /var/run/daemons<br />
$ top # or htop, ps aux, whatever you are comfortable with<br />
$ killall -9 $processname<br />
# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with {{Pkg|nvidia}}, disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
The M-Audio Delta series cards are based on the VIA Ice1712 audio chipset.<br />
Cards using this chip require that you install the alsa-tools package, because <br />
it contains the [[envy24control]] program. [[Envy24control]] is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
$ envy24control<br />
<br />
This application can be more than a bit confusing; see [[envy24control]] for guidance<br />
on its use. That said, here is a very simple working setup for multitracking with Ardour.<br />
<br />
# On the "Monitor Inputs" and "Monitor PCMs" tabs, set all monitor inputs and monitor PCM's to around 20.<br />
# On the "Patchbay / Router" tab, set all to PCM out.<br />
# On the "Hardware Settings" tab, verify that the Master Clock setting matches what is set in Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== M-Audio Fast Track Pro ===<br />
<br />
The M-Audio Fast Track Pro is an USB 4x4 audio interface, working at 24bit/96kHz. Due to limitation of USB 1, this device requires additional setup to get access to all its features. Device works in one of two configuration:<br />
<br />
* Configuration 1, or "Class compliant mode" - with reduced functionality, only 16bit, 48kHz, analogue input (2 channels) and digital/analogue output (4 channels).<br />
* Configuration 2 - with access to all features of interface.<br />
<br />
Currently with stock kernel it runs in configuration 2, but if you want to make sure in what mode you are, you can check kernel log for entries:<br />
<br />
{{bc|<br />
usb-audio: Fast Track Pro switching to config #2<br />
usb-audio: Fast Track Pro config OK<br />
}}<br />
<br />
The interface also needs extra step of cofiguration to switch modes. It is done using option {{ic|device_setup}} during module loading. The recommended way to setup the interface is using file in {{ic|modprobe.d}}:<br />
{{hc|/etc/modprobe.d/ftp.conf|<nowiki><br />
options snd_usb_audio vid=0x763 pid=0x2012 device_setup=XXX index=YYY enable=1<br />
</nowiki>}}<br />
where {{ic|vid}} and {{ic|pid}} are vendor and product id for M-Audio Fast Track Pro, {{ic|index}} is desired device number and {{ic|device_setup}} is desired device setup. Possible values for {{ic|device_setup}} are:<br />
{| border="1"<br />
|+ device modes<br />
! device_setup value !! bit depth !! frequency !! analog output !! digital output !! analog input !! digital input !! IO mode<br />
|-<br />
| 0x0 || 16 bit || 48kHz || + || + || + || + || 4x4<br />
|-<br />
| 0x9 || 24 bit || 48kHz || + || + || + || - || 2x4<br />
|-<br />
| 0x13 || 24 bit || 48kHz || + || + || - || + || 2x4<br />
|-<br />
| 0x5 || 24 bit || 96kHz || * || * || * || * || 2x0 or 0x2<br />
|}<br />
<br />
The 24 bit/96kHz mode is special: it provides all input/output, but you can open only one of 4 interfaces at a time. If you for example open output interface and then try to open second output or input interface, you will see error in kernel log:<br />
{{bc|<br />
cannot submit datapipe for urb 0, error -28: not enough bandwidth<br />
}}<br />
which is perfectly normal, because this is USB 1 device and cannot provide enough bandwidth to support more than single (2 channel) destination/source of that quality at a time.<br />
<br />
Depending on the value of {{ic|index}} it will setup two devices: {{ic|hwYYY:0}} and {{ic|hwYYY:1}}, which will contain available inputs and outputs. First device is most likely to contain analog output and digital input, while second one will contain analog input and digital output. To find out which devices are linked where and if they are setup correctly, you can check {{ic|/proc/asound/cardYYY/stream{0,1} }}. Below is list of important endpoints that will help in correctly identifying card connections (it easy to mistake analog and digital input or output connections before you get used to the device):<br />
<br />
{{bc|<nowiki><br />
EP 3 (analgoue output = TRS on back, mirrored on RCA outputs 1 and 2 on back)<br />
EP 4 (digital output = S/PDIF output on back, mirrored on RCA outputs 3 and 4 on back)<br />
EP 5 (analogue input = balanced TRS or XLR microphone, unbalanced TS line on front)<br />
EP 6 (digital input = S/PDIF input on back)<br />
</nowiki>}}<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from command line or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10 channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[https://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio].<br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: https://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
For all your Arch- and ArchAudio-related audio issues hop on to '''IRC''': #archaudio @ Freenode<br />
<br />
== Linux and Arch Linux Pro Audio in the News ==<br />
* [http://www.linuxjournal.com/content/arch-tale An Arch Tale] - Article by fellow musician and writer Dave Phillips, October 2011<br />
<br />
* [http://www.itwire.com/opinion-and-analysis/open-sauce/36698-from-windows-to-linux-a-sound-decision From Windows to Linux: a sound decision] - Interview with Geoff "songshop" Beasley, February 2010</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=229128Professional audio2012-10-16T23:25:05Z<p>Smoge: /* System Configuration */</p>
<hr />
<div>[[Category:Audio/Video]]<br />
{{Expansion|describe irqbalance}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Information on using Arch Linux for (semi-)professional audio}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary wiki|envy24control}}<br />
{{Article summary link|ArchAudio|http://archaudio.org/}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your (semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration. You could even run an industrial laser alongside your ''DAW'' (Digital audio workstation).<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt their very own dedicated machines for recording, mixing, mastering, sound-design, DSP programming, and what have you. More often than not, when a "linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown what has led to such fallacious thinking, but needless to say, "compiling", "learning" and "performance" have as much to do with each other as "differences in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, ''you just work'' ™. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S jack # or jack2, recommended if you have a multicore cpu<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi<br />
<br />
Additionally, if you are a '''multilib''' user of '''jack''' (which is jack1) on ''x86_64'' and you need a 32-bit version of the library (if not already installed by another hybrid package as a dependency):<br />
<br />
# pacman -S lib32-jack<br />
<br />
For '''jack2''', there is no need to install anything else, as there is '''jack2-multilib''' which should already be installed if you enabled the repository.<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* Traverso<br />
* [[Linuxsampler|QSampler]]<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
{{Tip|You may want to consider the following often seen system optimizations:<br />
- Install {{AUR|linux-rt}} kernel and include ''threadirqs'' in your kernel boot line (>&#61;2.6.39).<br><br />
- Install the {{AUR|systemd-rtirq}} package and enable it with <br />
# systemctl enable rtirq<br />
- Add yourself to the ''audio'' [[Groups#Groups|group]].<br><br />
- Set the [[cpufreq]] governor to ''performance''.<br><br />
- Add ''noatime'' to the [[fstab|filesystem mount options]]; (see [[Maximizing_Performance#Mount_options|Maximizing Performance]].)<br><br />
<br />
Realtime configuration has mostly been automated. There is no longer any need to edit files like {{ic|/etc/security/limits.conf}} for realtime access. However, if you must change the settings, see {{ic|/etc/security/limits.d/99-audio.conf}} and {{ic|/lib/udev/rules.d/40-hpet-permissions.rules}} (these files are provided by {{pkg|jack}}). Additionaly, you may want to increase the highest requested RTC interrupt frequency (default is 64 Hz) by adding to {{ic|/etc/rc.local}} something like this:<br />
echo 2048 > /sys/class/rtc/rtc0/max_user_freq<br />
echo 2048 > /proc/sys/dev/hpet/max-user-freq<br />
<br />
By default, swap frequency defined by "swappiness" is set to 60. By reducing this number to 10, the system will wait much longer before trying to write to disk.<br />
Then, there's ''inotify'' which watches for changes to files and reports them to applications requesting this information. When working with lots of audio data, a lot of watches will need to be kept track of, so they will need to be increased.<br />
These two settings can be adjusted in {{ic|/etc/sysctl.conf}} (file owned by {{pkg|procps}}).<br />
vm.swappiness &#61; 10<br />
fs.inotify.max_user_watches &#61; 524288<br />
You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).<br />
$ setpci -v -d *:* latency_timer&#61;'''b0'''<br />
$ setpci -v -s ''$SOUND_CARD_PCI_ID'' latency_timer&#61;'''ff''' # eg. SOUND_CARD_PCI_ID&#61;03:00.0 (see below)<br />
The SOUND_CARD_PCI_ID can be obtained like so:<br />
$ lspci &#166; grep -i audio<br />
'''03:00.0''' Multimedia audio controller: Creative Labs SB Audigy (rev 03)<br />
'''03:01.0''' Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)<br />
}}<br />
<br />
The steps below are mostly to double-check that you have a working multimedia system:<br />
* Have I set up sound properly? See [[ALSA]] or [[OSS]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]] or [[OSS]].<br />
<br />
$ groups | grep audio<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device?<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. '''Frames/Period = 256''' is a sane starter. For onboard and USB devices, try '''Periods/Buffer = 3'''. Commonly used values are: 256/3, 256/2, 128/3.<br />
<br />
Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. Others include 44100 and 96000.<br />
<br />
Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in {{ic|/etc/security/limits.d/99-audio.conf}}); the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
{{pkg|QJackCtl}} and {{pkg|Patchage}} are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
{{Note|Once you set up JACK, try different audio applications to test your configuration results. I spent days trying to troubleshoot JACK xrun issues with LMMS which in the end turned out to be the problem with the latter.}}<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== JACK2 ====<br />
<br />
For jack2 you do not need qjackctl at all. You can use a lightweight alternative with less features. Applications like ardour or patchage already take care of client connections and smoothly adjusting the buffer size.<br />
<br />
==== FireWire ====<br />
{{Note|Nothing much is needed to be done as most things have been automated, especially with the introduction of the [https://ieee1394.wiki.kernel.org/articles/j/u/j/Juju_Migration_e8a6.html new FireWire stack], deprecation of [[HAL]] and more focus on [[udev]]. You should not need to edit device permissions, but if you suspect that your device may not be working due to such issues, see {{ic|/lib/udev/rules.d/60-ffado.rules}} and if needed, create and put your changes into {{ic|/etc/udev/rules.d/60-ffado.rules}}. Most often than not, your device will work with the {{AUR|libffado-svn}} development version of the driver].}}<br />
<br />
JACK(2) is built against FFADO, you only need to install it:<br />
<br />
# pacman -S libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) {{Ic|/etc/asound.conf}} (system wide settings) to have these lines:<br />
<br />
{{Bc|<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 />
}<br />
}}<br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of knobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [https://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
=== A General Example ===<br />
<br />
A general configuration example is [[JACK Audio Connection Kit#An Example of Startup and Configuration|here]].<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with {{Ic|CONFIG_PREEMPT&#61;y}}, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
{{note|Before you decide to use a patched kernel, see [http://jackaudio.org/realtime_vs_realtime_kernel http://jackaudio.org/realtime_vs_realtime_kernel].}}<br />
<br />
=== ABS ===<br />
<br />
You can use [[ABS]] to recompile {{Pkg|linux}} with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel (at least you should add {{Ic|linux}} to {{Ic|IgnorePkg}} array in {{Ic|/etc/rc.conf}}.<br />
<br />
=== AUR ===<br />
<br />
From the [[AUR]] itself, you have the following options:<br />
<br />
* {{AUR|linux-rt}}<br />
* {{AUR|linux-rt-lts}} (Long Term Support; older, stable release)<br />
* {{AUR|linux-rt-ice}}<br />
<br />
The first two are standard kernels with the CONFIG_PREEMPT_RT patch, while -ice includes patches some may consider to be nasty, while to others are a blessing.<br />
:''See: [https://rt.wiki.kernel.org/ Real-Time Linux Wiki]''<br />
<br />
== MIDI ==<br />
<br />
To work with MIDI you can it is highly recommended that you install a2j, a bridge between alsa midi and jack midi. It allows you to connect applications that only communicate with alsa midi to applications that only use jack midi. Laditray can also start/stop a2j.<br />
:''See: [[JACK#MIDI]]''<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a realtime or a recent kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads. A systemd package can be found here: [https://aur.archlinux.org/packages.php?ID=63617&detail=1 systemd-rtirq].<br />
<br />
* Do not use the '''irqbalance''' daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
$ ls /var/run/daemons<br />
$ top # or htop, ps aux, whatever you are comfortable with<br />
$ killall -9 $processname<br />
# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with {{Pkg|nvidia}}, disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
The M-Audio Delta series cards are based on the VIA Ice1712 audio chipset.<br />
Cards using this chip require that you install the alsa-tools package, because <br />
it contains the [[envy24control]] program. [[Envy24control]] is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
$ envy24control<br />
<br />
This application can be more than a bit confusing; see [[envy24control]] for guidance<br />
on its use. That said, here is a very simple working setup for multitracking with Ardour.<br />
<br />
# On the "Monitor Inputs" and "Monitor PCMs" tabs, set all monitor inputs and monitor PCM's to around 20.<br />
# On the "Patchbay / Router" tab, set all to PCM out.<br />
# On the "Hardware Settings" tab, verify that the Master Clock setting matches what is set in Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== M-Audio Fast Track Pro ===<br />
<br />
The M-Audio Fast Track Pro is an USB 4x4 audio interface, working at 24bit/96kHz. Due to limitation of USB 1, this device requires additional setup to get access to all its features. Device works in one of two configuration:<br />
<br />
* Configuration 1, or "Class compliant mode" - with reduced functionality, only 16bit, 48kHz, analogue input (2 channels) and digital/analogue output (4 channels).<br />
* Configuration 2 - with access to all features of interface.<br />
<br />
Currently with stock kernel it runs in configuration 2, but if you want to make sure in what mode you are, you can check kernel log for entries:<br />
<br />
{{bc|<br />
usb-audio: Fast Track Pro switching to config #2<br />
usb-audio: Fast Track Pro config OK<br />
}}<br />
<br />
The interface also needs extra step of cofiguration to switch modes. It is done using option {{ic|device_setup}} during module loading. The recommended way to setup the interface is using file in {{ic|modprobe.d}}:<br />
{{hc|/etc/modprobe.d/ftp.conf|<nowiki><br />
options snd_usb_audio vid=0x763 pid=0x2012 device_setup=XXX index=YYY enable=1<br />
</nowiki>}}<br />
where {{ic|vid}} and {{ic|pid}} are vendor and product id for M-Audio Fast Track Pro, {{ic|index}} is desired device number and {{ic|device_setup}} is desired device setup. Possible values for {{ic|device_setup}} are:<br />
{| border="1"<br />
|+ device modes<br />
! device_setup value !! bit depth !! frequency !! analog output !! digital output !! analog input !! digital input !! IO mode<br />
|-<br />
| 0x0 || 16 bit || 48kHz || + || + || + || + || 4x4<br />
|-<br />
| 0x9 || 24 bit || 48kHz || + || + || + || - || 2x4<br />
|-<br />
| 0x13 || 24 bit || 48kHz || + || + || - || + || 2x4<br />
|-<br />
| 0x5 || 24 bit || 96kHz || * || * || * || * || 2x0 or 0x2<br />
|}<br />
<br />
The 24 bit/96kHz mode is special: it provides all input/output, but you can open only one of 4 interfaces at a time. If you for example open output interface and then try to open second output or input interface, you will see error in kernel log:<br />
{{bc|<br />
cannot submit datapipe for urb 0, error -28: not enough bandwidth<br />
}}<br />
which is perfectly normal, because this is USB 1 device and cannot provide enough bandwidth to support more than single (2 channel) destination/source of that quality at a time.<br />
<br />
Depending on the value of {{ic|index}} it will setup two devices: {{ic|hwYYY:0}} and {{ic|hwYYY:1}}, which will contain available inputs and outputs. First device is most likely to contain analog output and digital input, while second one will contain analog input and digital output. To find out which devices are linked where and if they are setup correctly, you can check {{ic|/proc/asound/cardYYY/stream{0,1} }}. Below is list of important endpoints that will help in correctly identifying card connections (it easy to mistake analog and digital input or output connections before you get used to the device):<br />
<br />
{{bc|<nowiki><br />
EP 3 (analgoue output = TRS on back, mirrored on RCA outputs 1 and 2 on back)<br />
EP 4 (digital output = S/PDIF output on back, mirrored on RCA outputs 3 and 4 on back)<br />
EP 5 (analogue input = balanced TRS or XLR microphone, unbalanced TS line on front)<br />
EP 6 (digital input = S/PDIF input on back)<br />
</nowiki>}}<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from command line or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10 channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[https://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio].<br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: https://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
For all your Arch- and ArchAudio-related audio issues hop on to '''IRC''': #archaudio @ Freenode<br />
<br />
== Linux and Arch Linux Pro Audio in the News ==<br />
* [http://www.linuxjournal.com/content/arch-tale An Arch Tale] - Article by fellow musician and writer Dave Phillips, October 2011<br />
<br />
* [http://www.itwire.com/opinion-and-analysis/open-sauce/36698-from-windows-to-linux-a-sound-decision From Windows to Linux: a sound decision] - Interview with Geoff "songshop" Beasley, February 2010</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=229127Professional audio2012-10-16T23:24:38Z<p>Smoge: /* System Configuration */</p>
<hr />
<div>[[Category:Audio/Video]]<br />
{{Expansion|describe irqbalance}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Information on using Arch Linux for (semi-)professional audio}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary wiki|envy24control}}<br />
{{Article summary link|ArchAudio|http://archaudio.org/}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your (semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration. You could even run an industrial laser alongside your ''DAW'' (Digital audio workstation).<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt their very own dedicated machines for recording, mixing, mastering, sound-design, DSP programming, and what have you. More often than not, when a "linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown what has led to such fallacious thinking, but needless to say, "compiling", "learning" and "performance" have as much to do with each other as "differences in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, ''you just work'' ™. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S jack # or jack2, recommended if you have a multicore cpu<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi<br />
<br />
Additionally, if you are a '''multilib''' user of '''jack''' (which is jack1) on ''x86_64'' and you need a 32-bit version of the library (if not already installed by another hybrid package as a dependency):<br />
<br />
# pacman -S lib32-jack<br />
<br />
For '''jack2''', there is no need to install anything else, as there is '''jack2-multilib''' which should already be installed if you enabled the repository.<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* Traverso<br />
* [[Linuxsampler|QSampler]]<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
{{Tip|You may want to consider the following often seen system optimizations:<br />
- Install {{AUR|linux-rt}} kernel and include ''threadirqs'' in your kernel boot line (>&#61;2.6.39).<br><br />
- Install the {{AUR|systemd-rtirq}} package for any FireWire audio devices and enable it with <br />
# systemctl enable rtirq<br />
- Add yourself to the ''audio'' [[Groups#Groups|group]].<br><br />
- Set the [[cpufreq]] governor to ''performance''.<br><br />
- Add ''noatime'' to the [[fstab|filesystem mount options]]; (see [[Maximizing_Performance#Mount_options|Maximizing Performance]].)<br><br />
<br />
Realtime configuration has mostly been automated. There is no longer any need to edit files like {{ic|/etc/security/limits.conf}} for realtime access. However, if you must change the settings, see {{ic|/etc/security/limits.d/99-audio.conf}} and {{ic|/lib/udev/rules.d/40-hpet-permissions.rules}} (these files are provided by {{pkg|jack}}). Additionaly, you may want to increase the highest requested RTC interrupt frequency (default is 64 Hz) by adding to {{ic|/etc/rc.local}} something like this:<br />
echo 2048 > /sys/class/rtc/rtc0/max_user_freq<br />
echo 2048 > /proc/sys/dev/hpet/max-user-freq<br />
<br />
By default, swap frequency defined by "swappiness" is set to 60. By reducing this number to 10, the system will wait much longer before trying to write to disk.<br />
Then, there's ''inotify'' which watches for changes to files and reports them to applications requesting this information. When working with lots of audio data, a lot of watches will need to be kept track of, so they will need to be increased.<br />
These two settings can be adjusted in {{ic|/etc/sysctl.conf}} (file owned by {{pkg|procps}}).<br />
vm.swappiness &#61; 10<br />
fs.inotify.max_user_watches &#61; 524288<br />
You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).<br />
$ setpci -v -d *:* latency_timer&#61;'''b0'''<br />
$ setpci -v -s ''$SOUND_CARD_PCI_ID'' latency_timer&#61;'''ff''' # eg. SOUND_CARD_PCI_ID&#61;03:00.0 (see below)<br />
The SOUND_CARD_PCI_ID can be obtained like so:<br />
$ lspci &#166; grep -i audio<br />
'''03:00.0''' Multimedia audio controller: Creative Labs SB Audigy (rev 03)<br />
'''03:01.0''' Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)<br />
}}<br />
<br />
The steps below are mostly to double-check that you have a working multimedia system:<br />
* Have I set up sound properly? See [[ALSA]] or [[OSS]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]] or [[OSS]].<br />
<br />
$ groups | grep audio<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device?<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. '''Frames/Period = 256''' is a sane starter. For onboard and USB devices, try '''Periods/Buffer = 3'''. Commonly used values are: 256/3, 256/2, 128/3.<br />
<br />
Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. Others include 44100 and 96000.<br />
<br />
Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in {{ic|/etc/security/limits.d/99-audio.conf}}); the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
{{pkg|QJackCtl}} and {{pkg|Patchage}} are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
{{Note|Once you set up JACK, try different audio applications to test your configuration results. I spent days trying to troubleshoot JACK xrun issues with LMMS which in the end turned out to be the problem with the latter.}}<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== JACK2 ====<br />
<br />
For jack2 you do not need qjackctl at all. You can use a lightweight alternative with less features. Applications like ardour or patchage already take care of client connections and smoothly adjusting the buffer size.<br />
<br />
==== FireWire ====<br />
{{Note|Nothing much is needed to be done as most things have been automated, especially with the introduction of the [https://ieee1394.wiki.kernel.org/articles/j/u/j/Juju_Migration_e8a6.html new FireWire stack], deprecation of [[HAL]] and more focus on [[udev]]. You should not need to edit device permissions, but if you suspect that your device may not be working due to such issues, see {{ic|/lib/udev/rules.d/60-ffado.rules}} and if needed, create and put your changes into {{ic|/etc/udev/rules.d/60-ffado.rules}}. Most often than not, your device will work with the {{AUR|libffado-svn}} development version of the driver].}}<br />
<br />
JACK(2) is built against FFADO, you only need to install it:<br />
<br />
# pacman -S libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) {{Ic|/etc/asound.conf}} (system wide settings) to have these lines:<br />
<br />
{{Bc|<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 />
}<br />
}}<br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of knobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [https://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
=== A General Example ===<br />
<br />
A general configuration example is [[JACK Audio Connection Kit#An Example of Startup and Configuration|here]].<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with {{Ic|CONFIG_PREEMPT&#61;y}}, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
{{note|Before you decide to use a patched kernel, see [http://jackaudio.org/realtime_vs_realtime_kernel http://jackaudio.org/realtime_vs_realtime_kernel].}}<br />
<br />
=== ABS ===<br />
<br />
You can use [[ABS]] to recompile {{Pkg|linux}} with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel (at least you should add {{Ic|linux}} to {{Ic|IgnorePkg}} array in {{Ic|/etc/rc.conf}}.<br />
<br />
=== AUR ===<br />
<br />
From the [[AUR]] itself, you have the following options:<br />
<br />
* {{AUR|linux-rt}}<br />
* {{AUR|linux-rt-lts}} (Long Term Support; older, stable release)<br />
* {{AUR|linux-rt-ice}}<br />
<br />
The first two are standard kernels with the CONFIG_PREEMPT_RT patch, while -ice includes patches some may consider to be nasty, while to others are a blessing.<br />
:''See: [https://rt.wiki.kernel.org/ Real-Time Linux Wiki]''<br />
<br />
== MIDI ==<br />
<br />
To work with MIDI you can it is highly recommended that you install a2j, a bridge between alsa midi and jack midi. It allows you to connect applications that only communicate with alsa midi to applications that only use jack midi. Laditray can also start/stop a2j.<br />
:''See: [[JACK#MIDI]]''<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a realtime or a recent kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads. A systemd package can be found here: [https://aur.archlinux.org/packages.php?ID=63617&detail=1 systemd-rtirq].<br />
<br />
* Do not use the '''irqbalance''' daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
$ ls /var/run/daemons<br />
$ top # or htop, ps aux, whatever you are comfortable with<br />
$ killall -9 $processname<br />
# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with {{Pkg|nvidia}}, disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
The M-Audio Delta series cards are based on the VIA Ice1712 audio chipset.<br />
Cards using this chip require that you install the alsa-tools package, because <br />
it contains the [[envy24control]] program. [[Envy24control]] is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
$ envy24control<br />
<br />
This application can be more than a bit confusing; see [[envy24control]] for guidance<br />
on its use. That said, here is a very simple working setup for multitracking with Ardour.<br />
<br />
# On the "Monitor Inputs" and "Monitor PCMs" tabs, set all monitor inputs and monitor PCM's to around 20.<br />
# On the "Patchbay / Router" tab, set all to PCM out.<br />
# On the "Hardware Settings" tab, verify that the Master Clock setting matches what is set in Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== M-Audio Fast Track Pro ===<br />
<br />
The M-Audio Fast Track Pro is an USB 4x4 audio interface, working at 24bit/96kHz. Due to limitation of USB 1, this device requires additional setup to get access to all its features. Device works in one of two configuration:<br />
<br />
* Configuration 1, or "Class compliant mode" - with reduced functionality, only 16bit, 48kHz, analogue input (2 channels) and digital/analogue output (4 channels).<br />
* Configuration 2 - with access to all features of interface.<br />
<br />
Currently with stock kernel it runs in configuration 2, but if you want to make sure in what mode you are, you can check kernel log for entries:<br />
<br />
{{bc|<br />
usb-audio: Fast Track Pro switching to config #2<br />
usb-audio: Fast Track Pro config OK<br />
}}<br />
<br />
The interface also needs extra step of cofiguration to switch modes. It is done using option {{ic|device_setup}} during module loading. The recommended way to setup the interface is using file in {{ic|modprobe.d}}:<br />
{{hc|/etc/modprobe.d/ftp.conf|<nowiki><br />
options snd_usb_audio vid=0x763 pid=0x2012 device_setup=XXX index=YYY enable=1<br />
</nowiki>}}<br />
where {{ic|vid}} and {{ic|pid}} are vendor and product id for M-Audio Fast Track Pro, {{ic|index}} is desired device number and {{ic|device_setup}} is desired device setup. Possible values for {{ic|device_setup}} are:<br />
{| border="1"<br />
|+ device modes<br />
! device_setup value !! bit depth !! frequency !! analog output !! digital output !! analog input !! digital input !! IO mode<br />
|-<br />
| 0x0 || 16 bit || 48kHz || + || + || + || + || 4x4<br />
|-<br />
| 0x9 || 24 bit || 48kHz || + || + || + || - || 2x4<br />
|-<br />
| 0x13 || 24 bit || 48kHz || + || + || - || + || 2x4<br />
|-<br />
| 0x5 || 24 bit || 96kHz || * || * || * || * || 2x0 or 0x2<br />
|}<br />
<br />
The 24 bit/96kHz mode is special: it provides all input/output, but you can open only one of 4 interfaces at a time. If you for example open output interface and then try to open second output or input interface, you will see error in kernel log:<br />
{{bc|<br />
cannot submit datapipe for urb 0, error -28: not enough bandwidth<br />
}}<br />
which is perfectly normal, because this is USB 1 device and cannot provide enough bandwidth to support more than single (2 channel) destination/source of that quality at a time.<br />
<br />
Depending on the value of {{ic|index}} it will setup two devices: {{ic|hwYYY:0}} and {{ic|hwYYY:1}}, which will contain available inputs and outputs. First device is most likely to contain analog output and digital input, while second one will contain analog input and digital output. To find out which devices are linked where and if they are setup correctly, you can check {{ic|/proc/asound/cardYYY/stream{0,1} }}. Below is list of important endpoints that will help in correctly identifying card connections (it easy to mistake analog and digital input or output connections before you get used to the device):<br />
<br />
{{bc|<nowiki><br />
EP 3 (analgoue output = TRS on back, mirrored on RCA outputs 1 and 2 on back)<br />
EP 4 (digital output = S/PDIF output on back, mirrored on RCA outputs 3 and 4 on back)<br />
EP 5 (analogue input = balanced TRS or XLR microphone, unbalanced TS line on front)<br />
EP 6 (digital input = S/PDIF input on back)<br />
</nowiki>}}<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from command line or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10 channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[https://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio].<br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: https://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
For all your Arch- and ArchAudio-related audio issues hop on to '''IRC''': #archaudio @ Freenode<br />
<br />
== Linux and Arch Linux Pro Audio in the News ==<br />
* [http://www.linuxjournal.com/content/arch-tale An Arch Tale] - Article by fellow musician and writer Dave Phillips, October 2011<br />
<br />
* [http://www.itwire.com/opinion-and-analysis/open-sauce/36698-from-windows-to-linux-a-sound-decision From Windows to Linux: a sound decision] - Interview with Geoff "songshop" Beasley, February 2010</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=229126Professional audio2012-10-16T23:24:02Z<p>Smoge: /* System Configuration */</p>
<hr />
<div>[[Category:Audio/Video]]<br />
{{Expansion|describe irqbalance}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Information on using Arch Linux for (semi-)professional audio}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary wiki|envy24control}}<br />
{{Article summary link|ArchAudio|http://archaudio.org/}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your (semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration. You could even run an industrial laser alongside your ''DAW'' (Digital audio workstation).<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt their very own dedicated machines for recording, mixing, mastering, sound-design, DSP programming, and what have you. More often than not, when a "linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown what has led to such fallacious thinking, but needless to say, "compiling", "learning" and "performance" have as much to do with each other as "differences in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, ''you just work'' ™. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S jack # or jack2, recommended if you have a multicore cpu<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi<br />
<br />
Additionally, if you are a '''multilib''' user of '''jack''' (which is jack1) on ''x86_64'' and you need a 32-bit version of the library (if not already installed by another hybrid package as a dependency):<br />
<br />
# pacman -S lib32-jack<br />
<br />
For '''jack2''', there is no need to install anything else, as there is '''jack2-multilib''' which should already be installed if you enabled the repository.<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* Traverso<br />
* [[Linuxsampler|QSampler]]<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
{{Tip|You may want to consider the following often seen system optimizations:<br />
- Install {{AUR|linux-rt}} kernel and include ''threadirqs'' in your kernel boot line (>&#61;2.6.39).<br><br />
- Install the {{AUR|systemd-rtirq}} package for any FireWire audio devices and enable it with ''# systemctl enable rtirq''<br><br />
- Add yourself to the ''audio'' [[Groups#Groups|group]].<br><br />
- Set the [[cpufreq]] governor to ''performance''.<br><br />
- Add ''noatime'' to the [[fstab|filesystem mount options]]; (see [[Maximizing_Performance#Mount_options|Maximizing Performance]].)<br><br />
<br />
Realtime configuration has mostly been automated. There is no longer any need to edit files like {{ic|/etc/security/limits.conf}} for realtime access. However, if you must change the settings, see {{ic|/etc/security/limits.d/99-audio.conf}} and {{ic|/lib/udev/rules.d/40-hpet-permissions.rules}} (these files are provided by {{pkg|jack}}). Additionaly, you may want to increase the highest requested RTC interrupt frequency (default is 64 Hz) by adding to {{ic|/etc/rc.local}} something like this:<br />
echo 2048 > /sys/class/rtc/rtc0/max_user_freq<br />
echo 2048 > /proc/sys/dev/hpet/max-user-freq<br />
<br />
By default, swap frequency defined by "swappiness" is set to 60. By reducing this number to 10, the system will wait much longer before trying to write to disk.<br />
Then, there's ''inotify'' which watches for changes to files and reports them to applications requesting this information. When working with lots of audio data, a lot of watches will need to be kept track of, so they will need to be increased.<br />
These two settings can be adjusted in {{ic|/etc/sysctl.conf}} (file owned by {{pkg|procps}}).<br />
vm.swappiness &#61; 10<br />
fs.inotify.max_user_watches &#61; 524288<br />
You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).<br />
$ setpci -v -d *:* latency_timer&#61;'''b0'''<br />
$ setpci -v -s ''$SOUND_CARD_PCI_ID'' latency_timer&#61;'''ff''' # eg. SOUND_CARD_PCI_ID&#61;03:00.0 (see below)<br />
The SOUND_CARD_PCI_ID can be obtained like so:<br />
$ lspci &#166; grep -i audio<br />
'''03:00.0''' Multimedia audio controller: Creative Labs SB Audigy (rev 03)<br />
'''03:01.0''' Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)<br />
}}<br />
<br />
The steps below are mostly to double-check that you have a working multimedia system:<br />
* Have I set up sound properly? See [[ALSA]] or [[OSS]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]] or [[OSS]].<br />
<br />
$ groups | grep audio<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device?<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. '''Frames/Period = 256''' is a sane starter. For onboard and USB devices, try '''Periods/Buffer = 3'''. Commonly used values are: 256/3, 256/2, 128/3.<br />
<br />
Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. Others include 44100 and 96000.<br />
<br />
Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in {{ic|/etc/security/limits.d/99-audio.conf}}); the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
{{pkg|QJackCtl}} and {{pkg|Patchage}} are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
{{Note|Once you set up JACK, try different audio applications to test your configuration results. I spent days trying to troubleshoot JACK xrun issues with LMMS which in the end turned out to be the problem with the latter.}}<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== JACK2 ====<br />
<br />
For jack2 you do not need qjackctl at all. You can use a lightweight alternative with less features. Applications like ardour or patchage already take care of client connections and smoothly adjusting the buffer size.<br />
<br />
==== FireWire ====<br />
{{Note|Nothing much is needed to be done as most things have been automated, especially with the introduction of the [https://ieee1394.wiki.kernel.org/articles/j/u/j/Juju_Migration_e8a6.html new FireWire stack], deprecation of [[HAL]] and more focus on [[udev]]. You should not need to edit device permissions, but if you suspect that your device may not be working due to such issues, see {{ic|/lib/udev/rules.d/60-ffado.rules}} and if needed, create and put your changes into {{ic|/etc/udev/rules.d/60-ffado.rules}}. Most often than not, your device will work with the {{AUR|libffado-svn}} development version of the driver].}}<br />
<br />
JACK(2) is built against FFADO, you only need to install it:<br />
<br />
# pacman -S libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) {{Ic|/etc/asound.conf}} (system wide settings) to have these lines:<br />
<br />
{{Bc|<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 />
}<br />
}}<br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of knobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [https://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
=== A General Example ===<br />
<br />
A general configuration example is [[JACK Audio Connection Kit#An Example of Startup and Configuration|here]].<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with {{Ic|CONFIG_PREEMPT&#61;y}}, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
{{note|Before you decide to use a patched kernel, see [http://jackaudio.org/realtime_vs_realtime_kernel http://jackaudio.org/realtime_vs_realtime_kernel].}}<br />
<br />
=== ABS ===<br />
<br />
You can use [[ABS]] to recompile {{Pkg|linux}} with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel (at least you should add {{Ic|linux}} to {{Ic|IgnorePkg}} array in {{Ic|/etc/rc.conf}}.<br />
<br />
=== AUR ===<br />
<br />
From the [[AUR]] itself, you have the following options:<br />
<br />
* {{AUR|linux-rt}}<br />
* {{AUR|linux-rt-lts}} (Long Term Support; older, stable release)<br />
* {{AUR|linux-rt-ice}}<br />
<br />
The first two are standard kernels with the CONFIG_PREEMPT_RT patch, while -ice includes patches some may consider to be nasty, while to others are a blessing.<br />
:''See: [https://rt.wiki.kernel.org/ Real-Time Linux Wiki]''<br />
<br />
== MIDI ==<br />
<br />
To work with MIDI you can it is highly recommended that you install a2j, a bridge between alsa midi and jack midi. It allows you to connect applications that only communicate with alsa midi to applications that only use jack midi. Laditray can also start/stop a2j.<br />
:''See: [[JACK#MIDI]]''<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a realtime or a recent kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads. A systemd package can be found here: [https://aur.archlinux.org/packages.php?ID=63617&detail=1 systemd-rtirq].<br />
<br />
* Do not use the '''irqbalance''' daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
$ ls /var/run/daemons<br />
$ top # or htop, ps aux, whatever you are comfortable with<br />
$ killall -9 $processname<br />
# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with {{Pkg|nvidia}}, disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
The M-Audio Delta series cards are based on the VIA Ice1712 audio chipset.<br />
Cards using this chip require that you install the alsa-tools package, because <br />
it contains the [[envy24control]] program. [[Envy24control]] is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
$ envy24control<br />
<br />
This application can be more than a bit confusing; see [[envy24control]] for guidance<br />
on its use. That said, here is a very simple working setup for multitracking with Ardour.<br />
<br />
# On the "Monitor Inputs" and "Monitor PCMs" tabs, set all monitor inputs and monitor PCM's to around 20.<br />
# On the "Patchbay / Router" tab, set all to PCM out.<br />
# On the "Hardware Settings" tab, verify that the Master Clock setting matches what is set in Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== M-Audio Fast Track Pro ===<br />
<br />
The M-Audio Fast Track Pro is an USB 4x4 audio interface, working at 24bit/96kHz. Due to limitation of USB 1, this device requires additional setup to get access to all its features. Device works in one of two configuration:<br />
<br />
* Configuration 1, or "Class compliant mode" - with reduced functionality, only 16bit, 48kHz, analogue input (2 channels) and digital/analogue output (4 channels).<br />
* Configuration 2 - with access to all features of interface.<br />
<br />
Currently with stock kernel it runs in configuration 2, but if you want to make sure in what mode you are, you can check kernel log for entries:<br />
<br />
{{bc|<br />
usb-audio: Fast Track Pro switching to config #2<br />
usb-audio: Fast Track Pro config OK<br />
}}<br />
<br />
The interface also needs extra step of cofiguration to switch modes. It is done using option {{ic|device_setup}} during module loading. The recommended way to setup the interface is using file in {{ic|modprobe.d}}:<br />
{{hc|/etc/modprobe.d/ftp.conf|<nowiki><br />
options snd_usb_audio vid=0x763 pid=0x2012 device_setup=XXX index=YYY enable=1<br />
</nowiki>}}<br />
where {{ic|vid}} and {{ic|pid}} are vendor and product id for M-Audio Fast Track Pro, {{ic|index}} is desired device number and {{ic|device_setup}} is desired device setup. Possible values for {{ic|device_setup}} are:<br />
{| border="1"<br />
|+ device modes<br />
! device_setup value !! bit depth !! frequency !! analog output !! digital output !! analog input !! digital input !! IO mode<br />
|-<br />
| 0x0 || 16 bit || 48kHz || + || + || + || + || 4x4<br />
|-<br />
| 0x9 || 24 bit || 48kHz || + || + || + || - || 2x4<br />
|-<br />
| 0x13 || 24 bit || 48kHz || + || + || - || + || 2x4<br />
|-<br />
| 0x5 || 24 bit || 96kHz || * || * || * || * || 2x0 or 0x2<br />
|}<br />
<br />
The 24 bit/96kHz mode is special: it provides all input/output, but you can open only one of 4 interfaces at a time. If you for example open output interface and then try to open second output or input interface, you will see error in kernel log:<br />
{{bc|<br />
cannot submit datapipe for urb 0, error -28: not enough bandwidth<br />
}}<br />
which is perfectly normal, because this is USB 1 device and cannot provide enough bandwidth to support more than single (2 channel) destination/source of that quality at a time.<br />
<br />
Depending on the value of {{ic|index}} it will setup two devices: {{ic|hwYYY:0}} and {{ic|hwYYY:1}}, which will contain available inputs and outputs. First device is most likely to contain analog output and digital input, while second one will contain analog input and digital output. To find out which devices are linked where and if they are setup correctly, you can check {{ic|/proc/asound/cardYYY/stream{0,1} }}. Below is list of important endpoints that will help in correctly identifying card connections (it easy to mistake analog and digital input or output connections before you get used to the device):<br />
<br />
{{bc|<nowiki><br />
EP 3 (analgoue output = TRS on back, mirrored on RCA outputs 1 and 2 on back)<br />
EP 4 (digital output = S/PDIF output on back, mirrored on RCA outputs 3 and 4 on back)<br />
EP 5 (analogue input = balanced TRS or XLR microphone, unbalanced TS line on front)<br />
EP 6 (digital input = S/PDIF input on back)<br />
</nowiki>}}<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from command line or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10 channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[https://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio].<br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: https://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
For all your Arch- and ArchAudio-related audio issues hop on to '''IRC''': #archaudio @ Freenode<br />
<br />
== Linux and Arch Linux Pro Audio in the News ==<br />
* [http://www.linuxjournal.com/content/arch-tale An Arch Tale] - Article by fellow musician and writer Dave Phillips, October 2011<br />
<br />
* [http://www.itwire.com/opinion-and-analysis/open-sauce/36698-from-windows-to-linux-a-sound-decision From Windows to Linux: a sound decision] - Interview with Geoff "songshop" Beasley, February 2010</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=229125Professional audio2012-10-16T23:23:42Z<p>Smoge: /* System Configuration */</p>
<hr />
<div>[[Category:Audio/Video]]<br />
{{Expansion|describe irqbalance}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Information on using Arch Linux for (semi-)professional audio}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary wiki|envy24control}}<br />
{{Article summary link|ArchAudio|http://archaudio.org/}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your (semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration. You could even run an industrial laser alongside your ''DAW'' (Digital audio workstation).<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt their very own dedicated machines for recording, mixing, mastering, sound-design, DSP programming, and what have you. More often than not, when a "linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown what has led to such fallacious thinking, but needless to say, "compiling", "learning" and "performance" have as much to do with each other as "differences in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, ''you just work'' ™. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S jack # or jack2, recommended if you have a multicore cpu<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi<br />
<br />
Additionally, if you are a '''multilib''' user of '''jack''' (which is jack1) on ''x86_64'' and you need a 32-bit version of the library (if not already installed by another hybrid package as a dependency):<br />
<br />
# pacman -S lib32-jack<br />
<br />
For '''jack2''', there is no need to install anything else, as there is '''jack2-multilib''' which should already be installed if you enabled the repository.<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* Traverso<br />
* [[Linuxsampler|QSampler]]<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
{{Tip|You may want to consider the following often seen system optimizations:<br />
- Install {{AUR|linux-rt}} kernel and include ''threadirqs'' in your kernel boot line (>&#61;2.6.39).<br><br />
- Install the {{AUR|systemd-rtirq}} package for any FireWire audio devices and enable it with ''# systemctl enable rtirq''<br />
- Add yourself to the ''audio'' [[Groups#Groups|group]].<br><br />
- Set the [[cpufreq]] governor to ''performance''.<br><br />
- Add ''noatime'' to the [[fstab|filesystem mount options]]; (see [[Maximizing_Performance#Mount_options|Maximizing Performance]].)<br><br />
<br />
Realtime configuration has mostly been automated. There is no longer any need to edit files like {{ic|/etc/security/limits.conf}} for realtime access. However, if you must change the settings, see {{ic|/etc/security/limits.d/99-audio.conf}} and {{ic|/lib/udev/rules.d/40-hpet-permissions.rules}} (these files are provided by {{pkg|jack}}). Additionaly, you may want to increase the highest requested RTC interrupt frequency (default is 64 Hz) by adding to {{ic|/etc/rc.local}} something like this:<br />
echo 2048 > /sys/class/rtc/rtc0/max_user_freq<br />
echo 2048 > /proc/sys/dev/hpet/max-user-freq<br />
<br />
By default, swap frequency defined by "swappiness" is set to 60. By reducing this number to 10, the system will wait much longer before trying to write to disk.<br />
Then, there's ''inotify'' which watches for changes to files and reports them to applications requesting this information. When working with lots of audio data, a lot of watches will need to be kept track of, so they will need to be increased.<br />
These two settings can be adjusted in {{ic|/etc/sysctl.conf}} (file owned by {{pkg|procps}}).<br />
vm.swappiness &#61; 10<br />
fs.inotify.max_user_watches &#61; 524288<br />
You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).<br />
$ setpci -v -d *:* latency_timer&#61;'''b0'''<br />
$ setpci -v -s ''$SOUND_CARD_PCI_ID'' latency_timer&#61;'''ff''' # eg. SOUND_CARD_PCI_ID&#61;03:00.0 (see below)<br />
The SOUND_CARD_PCI_ID can be obtained like so:<br />
$ lspci &#166; grep -i audio<br />
'''03:00.0''' Multimedia audio controller: Creative Labs SB Audigy (rev 03)<br />
'''03:01.0''' Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)<br />
}}<br />
<br />
The steps below are mostly to double-check that you have a working multimedia system:<br />
* Have I set up sound properly? See [[ALSA]] or [[OSS]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]] or [[OSS]].<br />
<br />
$ groups | grep audio<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device?<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. '''Frames/Period = 256''' is a sane starter. For onboard and USB devices, try '''Periods/Buffer = 3'''. Commonly used values are: 256/3, 256/2, 128/3.<br />
<br />
Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. Others include 44100 and 96000.<br />
<br />
Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in {{ic|/etc/security/limits.d/99-audio.conf}}); the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
{{pkg|QJackCtl}} and {{pkg|Patchage}} are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
{{Note|Once you set up JACK, try different audio applications to test your configuration results. I spent days trying to troubleshoot JACK xrun issues with LMMS which in the end turned out to be the problem with the latter.}}<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== JACK2 ====<br />
<br />
For jack2 you do not need qjackctl at all. You can use a lightweight alternative with less features. Applications like ardour or patchage already take care of client connections and smoothly adjusting the buffer size.<br />
<br />
==== FireWire ====<br />
{{Note|Nothing much is needed to be done as most things have been automated, especially with the introduction of the [https://ieee1394.wiki.kernel.org/articles/j/u/j/Juju_Migration_e8a6.html new FireWire stack], deprecation of [[HAL]] and more focus on [[udev]]. You should not need to edit device permissions, but if you suspect that your device may not be working due to such issues, see {{ic|/lib/udev/rules.d/60-ffado.rules}} and if needed, create and put your changes into {{ic|/etc/udev/rules.d/60-ffado.rules}}. Most often than not, your device will work with the {{AUR|libffado-svn}} development version of the driver].}}<br />
<br />
JACK(2) is built against FFADO, you only need to install it:<br />
<br />
# pacman -S libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) {{Ic|/etc/asound.conf}} (system wide settings) to have these lines:<br />
<br />
{{Bc|<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 />
}<br />
}}<br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of knobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [https://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
=== A General Example ===<br />
<br />
A general configuration example is [[JACK Audio Connection Kit#An Example of Startup and Configuration|here]].<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with {{Ic|CONFIG_PREEMPT&#61;y}}, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
{{note|Before you decide to use a patched kernel, see [http://jackaudio.org/realtime_vs_realtime_kernel http://jackaudio.org/realtime_vs_realtime_kernel].}}<br />
<br />
=== ABS ===<br />
<br />
You can use [[ABS]] to recompile {{Pkg|linux}} with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel (at least you should add {{Ic|linux}} to {{Ic|IgnorePkg}} array in {{Ic|/etc/rc.conf}}.<br />
<br />
=== AUR ===<br />
<br />
From the [[AUR]] itself, you have the following options:<br />
<br />
* {{AUR|linux-rt}}<br />
* {{AUR|linux-rt-lts}} (Long Term Support; older, stable release)<br />
* {{AUR|linux-rt-ice}}<br />
<br />
The first two are standard kernels with the CONFIG_PREEMPT_RT patch, while -ice includes patches some may consider to be nasty, while to others are a blessing.<br />
:''See: [https://rt.wiki.kernel.org/ Real-Time Linux Wiki]''<br />
<br />
== MIDI ==<br />
<br />
To work with MIDI you can it is highly recommended that you install a2j, a bridge between alsa midi and jack midi. It allows you to connect applications that only communicate with alsa midi to applications that only use jack midi. Laditray can also start/stop a2j.<br />
:''See: [[JACK#MIDI]]''<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a realtime or a recent kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads. A systemd package can be found here: [https://aur.archlinux.org/packages.php?ID=63617&detail=1 systemd-rtirq].<br />
<br />
* Do not use the '''irqbalance''' daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
$ ls /var/run/daemons<br />
$ top # or htop, ps aux, whatever you are comfortable with<br />
$ killall -9 $processname<br />
# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with {{Pkg|nvidia}}, disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
The M-Audio Delta series cards are based on the VIA Ice1712 audio chipset.<br />
Cards using this chip require that you install the alsa-tools package, because <br />
it contains the [[envy24control]] program. [[Envy24control]] is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
$ envy24control<br />
<br />
This application can be more than a bit confusing; see [[envy24control]] for guidance<br />
on its use. That said, here is a very simple working setup for multitracking with Ardour.<br />
<br />
# On the "Monitor Inputs" and "Monitor PCMs" tabs, set all monitor inputs and monitor PCM's to around 20.<br />
# On the "Patchbay / Router" tab, set all to PCM out.<br />
# On the "Hardware Settings" tab, verify that the Master Clock setting matches what is set in Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== M-Audio Fast Track Pro ===<br />
<br />
The M-Audio Fast Track Pro is an USB 4x4 audio interface, working at 24bit/96kHz. Due to limitation of USB 1, this device requires additional setup to get access to all its features. Device works in one of two configuration:<br />
<br />
* Configuration 1, or "Class compliant mode" - with reduced functionality, only 16bit, 48kHz, analogue input (2 channels) and digital/analogue output (4 channels).<br />
* Configuration 2 - with access to all features of interface.<br />
<br />
Currently with stock kernel it runs in configuration 2, but if you want to make sure in what mode you are, you can check kernel log for entries:<br />
<br />
{{bc|<br />
usb-audio: Fast Track Pro switching to config #2<br />
usb-audio: Fast Track Pro config OK<br />
}}<br />
<br />
The interface also needs extra step of cofiguration to switch modes. It is done using option {{ic|device_setup}} during module loading. The recommended way to setup the interface is using file in {{ic|modprobe.d}}:<br />
{{hc|/etc/modprobe.d/ftp.conf|<nowiki><br />
options snd_usb_audio vid=0x763 pid=0x2012 device_setup=XXX index=YYY enable=1<br />
</nowiki>}}<br />
where {{ic|vid}} and {{ic|pid}} are vendor and product id for M-Audio Fast Track Pro, {{ic|index}} is desired device number and {{ic|device_setup}} is desired device setup. Possible values for {{ic|device_setup}} are:<br />
{| border="1"<br />
|+ device modes<br />
! device_setup value !! bit depth !! frequency !! analog output !! digital output !! analog input !! digital input !! IO mode<br />
|-<br />
| 0x0 || 16 bit || 48kHz || + || + || + || + || 4x4<br />
|-<br />
| 0x9 || 24 bit || 48kHz || + || + || + || - || 2x4<br />
|-<br />
| 0x13 || 24 bit || 48kHz || + || + || - || + || 2x4<br />
|-<br />
| 0x5 || 24 bit || 96kHz || * || * || * || * || 2x0 or 0x2<br />
|}<br />
<br />
The 24 bit/96kHz mode is special: it provides all input/output, but you can open only one of 4 interfaces at a time. If you for example open output interface and then try to open second output or input interface, you will see error in kernel log:<br />
{{bc|<br />
cannot submit datapipe for urb 0, error -28: not enough bandwidth<br />
}}<br />
which is perfectly normal, because this is USB 1 device and cannot provide enough bandwidth to support more than single (2 channel) destination/source of that quality at a time.<br />
<br />
Depending on the value of {{ic|index}} it will setup two devices: {{ic|hwYYY:0}} and {{ic|hwYYY:1}}, which will contain available inputs and outputs. First device is most likely to contain analog output and digital input, while second one will contain analog input and digital output. To find out which devices are linked where and if they are setup correctly, you can check {{ic|/proc/asound/cardYYY/stream{0,1} }}. Below is list of important endpoints that will help in correctly identifying card connections (it easy to mistake analog and digital input or output connections before you get used to the device):<br />
<br />
{{bc|<nowiki><br />
EP 3 (analgoue output = TRS on back, mirrored on RCA outputs 1 and 2 on back)<br />
EP 4 (digital output = S/PDIF output on back, mirrored on RCA outputs 3 and 4 on back)<br />
EP 5 (analogue input = balanced TRS or XLR microphone, unbalanced TS line on front)<br />
EP 6 (digital input = S/PDIF input on back)<br />
</nowiki>}}<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from command line or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10 channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[https://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio].<br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: https://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
For all your Arch- and ArchAudio-related audio issues hop on to '''IRC''': #archaudio @ Freenode<br />
<br />
== Linux and Arch Linux Pro Audio in the News ==<br />
* [http://www.linuxjournal.com/content/arch-tale An Arch Tale] - Article by fellow musician and writer Dave Phillips, October 2011<br />
<br />
* [http://www.itwire.com/opinion-and-analysis/open-sauce/36698-from-windows-to-linux-a-sound-decision From Windows to Linux: a sound decision] - Interview with Geoff "songshop" Beasley, February 2010</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=229124Professional audio2012-10-16T23:21:11Z<p>Smoge: /* Tips and Tricks */</p>
<hr />
<div>[[Category:Audio/Video]]<br />
{{Expansion|describe irqbalance}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Information on using Arch Linux for (semi-)professional audio}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary wiki|envy24control}}<br />
{{Article summary link|ArchAudio|http://archaudio.org/}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your (semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration. You could even run an industrial laser alongside your ''DAW'' (Digital audio workstation).<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt their very own dedicated machines for recording, mixing, mastering, sound-design, DSP programming, and what have you. More often than not, when a "linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown what has led to such fallacious thinking, but needless to say, "compiling", "learning" and "performance" have as much to do with each other as "differences in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, ''you just work'' ™. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S jack # or jack2, recommended if you have a multicore cpu<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi<br />
<br />
Additionally, if you are a '''multilib''' user of '''jack''' (which is jack1) on ''x86_64'' and you need a 32-bit version of the library (if not already installed by another hybrid package as a dependency):<br />
<br />
# pacman -S lib32-jack<br />
<br />
For '''jack2''', there is no need to install anything else, as there is '''jack2-multilib''' which should already be installed if you enabled the repository.<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* Traverso<br />
* [[Linuxsampler|QSampler]]<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
{{Tip|You may want to consider the following often seen system optimizations:<br />
- Install {{AUR|linux-rt}} kernel and include ''threadirqs'' in your kernel boot line (>&#61;2.6.39).<br><br />
- Install the {{AUR|rtirq}} package for any FireWire audio devices and include it in the [[Daemon|DAEMONS]] array in {{ic|/etc/rc.conf}}.<br><br />
- Add yourself to the ''audio'' [[Groups#Groups|group]].<br><br />
- Set the [[cpufreq]] governor to ''performance''.<br><br />
- Add ''noatime'' to the [[fstab|filesystem mount options]]; (see [[Maximizing_Performance#Mount_options|Maximizing Performance]].)<br><br />
<br />
Realtime configuration has mostly been automated. There is no longer any need to edit files like {{ic|/etc/security/limits.conf}} for realtime access. However, if you must change the settings, see {{ic|/etc/security/limits.d/99-audio.conf}} and {{ic|/lib/udev/rules.d/40-hpet-permissions.rules}} (these files are provided by {{pkg|jack}}). Additionaly, you may want to increase the highest requested RTC interrupt frequency (default is 64 Hz) by adding to {{ic|/etc/rc.local}} something like this:<br />
echo 2048 > /sys/class/rtc/rtc0/max_user_freq<br />
echo 2048 > /proc/sys/dev/hpet/max-user-freq<br />
<br />
By default, swap frequency defined by "swappiness" is set to 60. By reducing this number to 10, the system will wait much longer before trying to write to disk.<br />
Then, there's ''inotify'' which watches for changes to files and reports them to applications requesting this information. When working with lots of audio data, a lot of watches will need to be kept track of, so they will need to be increased.<br />
These two settings can be adjusted in {{ic|/etc/sysctl.conf}} (file owned by {{pkg|procps}}).<br />
vm.swappiness &#61; 10<br />
fs.inotify.max_user_watches &#61; 524288<br />
You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).<br />
$ setpci -v -d *:* latency_timer&#61;'''b0'''<br />
$ setpci -v -s ''$SOUND_CARD_PCI_ID'' latency_timer&#61;'''ff''' # eg. SOUND_CARD_PCI_ID&#61;03:00.0 (see below)<br />
The SOUND_CARD_PCI_ID can be obtained like so:<br />
$ lspci &#166; grep -i audio<br />
'''03:00.0''' Multimedia audio controller: Creative Labs SB Audigy (rev 03)<br />
'''03:01.0''' Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)<br />
}}<br />
<br />
The steps below are mostly to double-check that you have a working multimedia system:<br />
* Have I set up sound properly? See [[ALSA]] or [[OSS]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]] or [[OSS]].<br />
<br />
$ groups | grep audio<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device?<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. '''Frames/Period = 256''' is a sane starter. For onboard and USB devices, try '''Periods/Buffer = 3'''. Commonly used values are: 256/3, 256/2, 128/3.<br />
<br />
Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. Others include 44100 and 96000.<br />
<br />
Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in {{ic|/etc/security/limits.d/99-audio.conf}}); the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
{{pkg|QJackCtl}} and {{pkg|Patchage}} are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
{{Note|Once you set up JACK, try different audio applications to test your configuration results. I spent days trying to troubleshoot JACK xrun issues with LMMS which in the end turned out to be the problem with the latter.}}<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== JACK2 ====<br />
<br />
For jack2 you do not need qjackctl at all. You can use a lightweight alternative with less features. Applications like ardour or patchage already take care of client connections and smoothly adjusting the buffer size.<br />
<br />
==== FireWire ====<br />
{{Note|Nothing much is needed to be done as most things have been automated, especially with the introduction of the [https://ieee1394.wiki.kernel.org/articles/j/u/j/Juju_Migration_e8a6.html new FireWire stack], deprecation of [[HAL]] and more focus on [[udev]]. You should not need to edit device permissions, but if you suspect that your device may not be working due to such issues, see {{ic|/lib/udev/rules.d/60-ffado.rules}} and if needed, create and put your changes into {{ic|/etc/udev/rules.d/60-ffado.rules}}. Most often than not, your device will work with the {{AUR|libffado-svn}} development version of the driver].}}<br />
<br />
JACK(2) is built against FFADO, you only need to install it:<br />
<br />
# pacman -S libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) {{Ic|/etc/asound.conf}} (system wide settings) to have these lines:<br />
<br />
{{Bc|<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 />
}<br />
}}<br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of knobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [https://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
=== A General Example ===<br />
<br />
A general configuration example is [[JACK Audio Connection Kit#An Example of Startup and Configuration|here]].<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with {{Ic|CONFIG_PREEMPT&#61;y}}, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
{{note|Before you decide to use a patched kernel, see [http://jackaudio.org/realtime_vs_realtime_kernel http://jackaudio.org/realtime_vs_realtime_kernel].}}<br />
<br />
=== ABS ===<br />
<br />
You can use [[ABS]] to recompile {{Pkg|linux}} with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel (at least you should add {{Ic|linux}} to {{Ic|IgnorePkg}} array in {{Ic|/etc/rc.conf}}.<br />
<br />
=== AUR ===<br />
<br />
From the [[AUR]] itself, you have the following options:<br />
<br />
* {{AUR|linux-rt}}<br />
* {{AUR|linux-rt-lts}} (Long Term Support; older, stable release)<br />
* {{AUR|linux-rt-ice}}<br />
<br />
The first two are standard kernels with the CONFIG_PREEMPT_RT patch, while -ice includes patches some may consider to be nasty, while to others are a blessing.<br />
:''See: [https://rt.wiki.kernel.org/ Real-Time Linux Wiki]''<br />
<br />
== MIDI ==<br />
<br />
To work with MIDI you can it is highly recommended that you install a2j, a bridge between alsa midi and jack midi. It allows you to connect applications that only communicate with alsa midi to applications that only use jack midi. Laditray can also start/stop a2j.<br />
:''See: [[JACK#MIDI]]''<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a realtime or a recent kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads. A systemd package can be found here: [https://aur.archlinux.org/packages.php?ID=63617&detail=1 systemd-rtirq].<br />
<br />
* Do not use the '''irqbalance''' daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
$ ls /var/run/daemons<br />
$ top # or htop, ps aux, whatever you are comfortable with<br />
$ killall -9 $processname<br />
# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with {{Pkg|nvidia}}, disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
The M-Audio Delta series cards are based on the VIA Ice1712 audio chipset.<br />
Cards using this chip require that you install the alsa-tools package, because <br />
it contains the [[envy24control]] program. [[Envy24control]] is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
$ envy24control<br />
<br />
This application can be more than a bit confusing; see [[envy24control]] for guidance<br />
on its use. That said, here is a very simple working setup for multitracking with Ardour.<br />
<br />
# On the "Monitor Inputs" and "Monitor PCMs" tabs, set all monitor inputs and monitor PCM's to around 20.<br />
# On the "Patchbay / Router" tab, set all to PCM out.<br />
# On the "Hardware Settings" tab, verify that the Master Clock setting matches what is set in Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== M-Audio Fast Track Pro ===<br />
<br />
The M-Audio Fast Track Pro is an USB 4x4 audio interface, working at 24bit/96kHz. Due to limitation of USB 1, this device requires additional setup to get access to all its features. Device works in one of two configuration:<br />
<br />
* Configuration 1, or "Class compliant mode" - with reduced functionality, only 16bit, 48kHz, analogue input (2 channels) and digital/analogue output (4 channels).<br />
* Configuration 2 - with access to all features of interface.<br />
<br />
Currently with stock kernel it runs in configuration 2, but if you want to make sure in what mode you are, you can check kernel log for entries:<br />
<br />
{{bc|<br />
usb-audio: Fast Track Pro switching to config #2<br />
usb-audio: Fast Track Pro config OK<br />
}}<br />
<br />
The interface also needs extra step of cofiguration to switch modes. It is done using option {{ic|device_setup}} during module loading. The recommended way to setup the interface is using file in {{ic|modprobe.d}}:<br />
{{hc|/etc/modprobe.d/ftp.conf|<nowiki><br />
options snd_usb_audio vid=0x763 pid=0x2012 device_setup=XXX index=YYY enable=1<br />
</nowiki>}}<br />
where {{ic|vid}} and {{ic|pid}} are vendor and product id for M-Audio Fast Track Pro, {{ic|index}} is desired device number and {{ic|device_setup}} is desired device setup. Possible values for {{ic|device_setup}} are:<br />
{| border="1"<br />
|+ device modes<br />
! device_setup value !! bit depth !! frequency !! analog output !! digital output !! analog input !! digital input !! IO mode<br />
|-<br />
| 0x0 || 16 bit || 48kHz || + || + || + || + || 4x4<br />
|-<br />
| 0x9 || 24 bit || 48kHz || + || + || + || - || 2x4<br />
|-<br />
| 0x13 || 24 bit || 48kHz || + || + || - || + || 2x4<br />
|-<br />
| 0x5 || 24 bit || 96kHz || * || * || * || * || 2x0 or 0x2<br />
|}<br />
<br />
The 24 bit/96kHz mode is special: it provides all input/output, but you can open only one of 4 interfaces at a time. If you for example open output interface and then try to open second output or input interface, you will see error in kernel log:<br />
{{bc|<br />
cannot submit datapipe for urb 0, error -28: not enough bandwidth<br />
}}<br />
which is perfectly normal, because this is USB 1 device and cannot provide enough bandwidth to support more than single (2 channel) destination/source of that quality at a time.<br />
<br />
Depending on the value of {{ic|index}} it will setup two devices: {{ic|hwYYY:0}} and {{ic|hwYYY:1}}, which will contain available inputs and outputs. First device is most likely to contain analog output and digital input, while second one will contain analog input and digital output. To find out which devices are linked where and if they are setup correctly, you can check {{ic|/proc/asound/cardYYY/stream{0,1} }}. Below is list of important endpoints that will help in correctly identifying card connections (it easy to mistake analog and digital input or output connections before you get used to the device):<br />
<br />
{{bc|<nowiki><br />
EP 3 (analgoue output = TRS on back, mirrored on RCA outputs 1 and 2 on back)<br />
EP 4 (digital output = S/PDIF output on back, mirrored on RCA outputs 3 and 4 on back)<br />
EP 5 (analogue input = balanced TRS or XLR microphone, unbalanced TS line on front)<br />
EP 6 (digital input = S/PDIF input on back)<br />
</nowiki>}}<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from command line or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10 channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[https://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio].<br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: https://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
For all your Arch- and ArchAudio-related audio issues hop on to '''IRC''': #archaudio @ Freenode<br />
<br />
== Linux and Arch Linux Pro Audio in the News ==<br />
* [http://www.linuxjournal.com/content/arch-tale An Arch Tale] - Article by fellow musician and writer Dave Phillips, October 2011<br />
<br />
* [http://www.itwire.com/opinion-and-analysis/open-sauce/36698-from-windows-to-linux-a-sound-decision From Windows to Linux: a sound decision] - Interview with Geoff "songshop" Beasley, February 2010</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=229123Professional audio2012-10-16T23:20:44Z<p>Smoge: /* Tips and Tricks */</p>
<hr />
<div>[[Category:Audio/Video]]<br />
{{Expansion|describe irqbalance}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Information on using Arch Linux for (semi-)professional audio}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary wiki|envy24control}}<br />
{{Article summary link|ArchAudio|http://archaudio.org/}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your (semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration. You could even run an industrial laser alongside your ''DAW'' (Digital audio workstation).<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt their very own dedicated machines for recording, mixing, mastering, sound-design, DSP programming, and what have you. More often than not, when a "linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown what has led to such fallacious thinking, but needless to say, "compiling", "learning" and "performance" have as much to do with each other as "differences in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, ''you just work'' ™. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S jack # or jack2, recommended if you have a multicore cpu<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi<br />
<br />
Additionally, if you are a '''multilib''' user of '''jack''' (which is jack1) on ''x86_64'' and you need a 32-bit version of the library (if not already installed by another hybrid package as a dependency):<br />
<br />
# pacman -S lib32-jack<br />
<br />
For '''jack2''', there is no need to install anything else, as there is '''jack2-multilib''' which should already be installed if you enabled the repository.<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* Traverso<br />
* [[Linuxsampler|QSampler]]<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
{{Tip|You may want to consider the following often seen system optimizations:<br />
- Install {{AUR|linux-rt}} kernel and include ''threadirqs'' in your kernel boot line (>&#61;2.6.39).<br><br />
- Install the {{AUR|rtirq}} package for any FireWire audio devices and include it in the [[Daemon|DAEMONS]] array in {{ic|/etc/rc.conf}}.<br><br />
- Add yourself to the ''audio'' [[Groups#Groups|group]].<br><br />
- Set the [[cpufreq]] governor to ''performance''.<br><br />
- Add ''noatime'' to the [[fstab|filesystem mount options]]; (see [[Maximizing_Performance#Mount_options|Maximizing Performance]].)<br><br />
<br />
Realtime configuration has mostly been automated. There is no longer any need to edit files like {{ic|/etc/security/limits.conf}} for realtime access. However, if you must change the settings, see {{ic|/etc/security/limits.d/99-audio.conf}} and {{ic|/lib/udev/rules.d/40-hpet-permissions.rules}} (these files are provided by {{pkg|jack}}). Additionaly, you may want to increase the highest requested RTC interrupt frequency (default is 64 Hz) by adding to {{ic|/etc/rc.local}} something like this:<br />
echo 2048 > /sys/class/rtc/rtc0/max_user_freq<br />
echo 2048 > /proc/sys/dev/hpet/max-user-freq<br />
<br />
By default, swap frequency defined by "swappiness" is set to 60. By reducing this number to 10, the system will wait much longer before trying to write to disk.<br />
Then, there's ''inotify'' which watches for changes to files and reports them to applications requesting this information. When working with lots of audio data, a lot of watches will need to be kept track of, so they will need to be increased.<br />
These two settings can be adjusted in {{ic|/etc/sysctl.conf}} (file owned by {{pkg|procps}}).<br />
vm.swappiness &#61; 10<br />
fs.inotify.max_user_watches &#61; 524288<br />
You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).<br />
$ setpci -v -d *:* latency_timer&#61;'''b0'''<br />
$ setpci -v -s ''$SOUND_CARD_PCI_ID'' latency_timer&#61;'''ff''' # eg. SOUND_CARD_PCI_ID&#61;03:00.0 (see below)<br />
The SOUND_CARD_PCI_ID can be obtained like so:<br />
$ lspci &#166; grep -i audio<br />
'''03:00.0''' Multimedia audio controller: Creative Labs SB Audigy (rev 03)<br />
'''03:01.0''' Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)<br />
}}<br />
<br />
The steps below are mostly to double-check that you have a working multimedia system:<br />
* Have I set up sound properly? See [[ALSA]] or [[OSS]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]] or [[OSS]].<br />
<br />
$ groups | grep audio<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device?<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. '''Frames/Period = 256''' is a sane starter. For onboard and USB devices, try '''Periods/Buffer = 3'''. Commonly used values are: 256/3, 256/2, 128/3.<br />
<br />
Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. Others include 44100 and 96000.<br />
<br />
Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in {{ic|/etc/security/limits.d/99-audio.conf}}); the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
{{pkg|QJackCtl}} and {{pkg|Patchage}} are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
{{Note|Once you set up JACK, try different audio applications to test your configuration results. I spent days trying to troubleshoot JACK xrun issues with LMMS which in the end turned out to be the problem with the latter.}}<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== JACK2 ====<br />
<br />
For jack2 you do not need qjackctl at all. You can use a lightweight alternative with less features. Applications like ardour or patchage already take care of client connections and smoothly adjusting the buffer size.<br />
<br />
==== FireWire ====<br />
{{Note|Nothing much is needed to be done as most things have been automated, especially with the introduction of the [https://ieee1394.wiki.kernel.org/articles/j/u/j/Juju_Migration_e8a6.html new FireWire stack], deprecation of [[HAL]] and more focus on [[udev]]. You should not need to edit device permissions, but if you suspect that your device may not be working due to such issues, see {{ic|/lib/udev/rules.d/60-ffado.rules}} and if needed, create and put your changes into {{ic|/etc/udev/rules.d/60-ffado.rules}}. Most often than not, your device will work with the {{AUR|libffado-svn}} development version of the driver].}}<br />
<br />
JACK(2) is built against FFADO, you only need to install it:<br />
<br />
# pacman -S libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) {{Ic|/etc/asound.conf}} (system wide settings) to have these lines:<br />
<br />
{{Bc|<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 />
}<br />
}}<br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of knobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [https://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
=== A General Example ===<br />
<br />
A general configuration example is [[JACK Audio Connection Kit#An Example of Startup and Configuration|here]].<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with {{Ic|CONFIG_PREEMPT&#61;y}}, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
{{note|Before you decide to use a patched kernel, see [http://jackaudio.org/realtime_vs_realtime_kernel http://jackaudio.org/realtime_vs_realtime_kernel].}}<br />
<br />
=== ABS ===<br />
<br />
You can use [[ABS]] to recompile {{Pkg|linux}} with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel (at least you should add {{Ic|linux}} to {{Ic|IgnorePkg}} array in {{Ic|/etc/rc.conf}}.<br />
<br />
=== AUR ===<br />
<br />
From the [[AUR]] itself, you have the following options:<br />
<br />
* {{AUR|linux-rt}}<br />
* {{AUR|linux-rt-lts}} (Long Term Support; older, stable release)<br />
* {{AUR|linux-rt-ice}}<br />
<br />
The first two are standard kernels with the CONFIG_PREEMPT_RT patch, while -ice includes patches some may consider to be nasty, while to others are a blessing.<br />
:''See: [https://rt.wiki.kernel.org/ Real-Time Linux Wiki]''<br />
<br />
== MIDI ==<br />
<br />
To work with MIDI you can it is highly recommended that you install a2j, a bridge between alsa midi and jack midi. It allows you to connect applications that only communicate with alsa midi to applications that only use jack midi. Laditray can also start/stop a2j.<br />
:''See: [[JACK#MIDI]]''<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a realtime or a recent kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads. A systemd package can be found here: [https://aur.archlinux.org/packages.php?ID=63617&detail=1 systemd-rtirq]<br />
<br />
* Do not use the '''irqbalance''' daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
$ ls /var/run/daemons<br />
$ top # or htop, ps aux, whatever you are comfortable with<br />
$ killall -9 $processname<br />
# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with {{Pkg|nvidia}}, disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
The M-Audio Delta series cards are based on the VIA Ice1712 audio chipset.<br />
Cards using this chip require that you install the alsa-tools package, because <br />
it contains the [[envy24control]] program. [[Envy24control]] is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
$ envy24control<br />
<br />
This application can be more than a bit confusing; see [[envy24control]] for guidance<br />
on its use. That said, here is a very simple working setup for multitracking with Ardour.<br />
<br />
# On the "Monitor Inputs" and "Monitor PCMs" tabs, set all monitor inputs and monitor PCM's to around 20.<br />
# On the "Patchbay / Router" tab, set all to PCM out.<br />
# On the "Hardware Settings" tab, verify that the Master Clock setting matches what is set in Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== M-Audio Fast Track Pro ===<br />
<br />
The M-Audio Fast Track Pro is an USB 4x4 audio interface, working at 24bit/96kHz. Due to limitation of USB 1, this device requires additional setup to get access to all its features. Device works in one of two configuration:<br />
<br />
* Configuration 1, or "Class compliant mode" - with reduced functionality, only 16bit, 48kHz, analogue input (2 channels) and digital/analogue output (4 channels).<br />
* Configuration 2 - with access to all features of interface.<br />
<br />
Currently with stock kernel it runs in configuration 2, but if you want to make sure in what mode you are, you can check kernel log for entries:<br />
<br />
{{bc|<br />
usb-audio: Fast Track Pro switching to config #2<br />
usb-audio: Fast Track Pro config OK<br />
}}<br />
<br />
The interface also needs extra step of cofiguration to switch modes. It is done using option {{ic|device_setup}} during module loading. The recommended way to setup the interface is using file in {{ic|modprobe.d}}:<br />
{{hc|/etc/modprobe.d/ftp.conf|<nowiki><br />
options snd_usb_audio vid=0x763 pid=0x2012 device_setup=XXX index=YYY enable=1<br />
</nowiki>}}<br />
where {{ic|vid}} and {{ic|pid}} are vendor and product id for M-Audio Fast Track Pro, {{ic|index}} is desired device number and {{ic|device_setup}} is desired device setup. Possible values for {{ic|device_setup}} are:<br />
{| border="1"<br />
|+ device modes<br />
! device_setup value !! bit depth !! frequency !! analog output !! digital output !! analog input !! digital input !! IO mode<br />
|-<br />
| 0x0 || 16 bit || 48kHz || + || + || + || + || 4x4<br />
|-<br />
| 0x9 || 24 bit || 48kHz || + || + || + || - || 2x4<br />
|-<br />
| 0x13 || 24 bit || 48kHz || + || + || - || + || 2x4<br />
|-<br />
| 0x5 || 24 bit || 96kHz || * || * || * || * || 2x0 or 0x2<br />
|}<br />
<br />
The 24 bit/96kHz mode is special: it provides all input/output, but you can open only one of 4 interfaces at a time. If you for example open output interface and then try to open second output or input interface, you will see error in kernel log:<br />
{{bc|<br />
cannot submit datapipe for urb 0, error -28: not enough bandwidth<br />
}}<br />
which is perfectly normal, because this is USB 1 device and cannot provide enough bandwidth to support more than single (2 channel) destination/source of that quality at a time.<br />
<br />
Depending on the value of {{ic|index}} it will setup two devices: {{ic|hwYYY:0}} and {{ic|hwYYY:1}}, which will contain available inputs and outputs. First device is most likely to contain analog output and digital input, while second one will contain analog input and digital output. To find out which devices are linked where and if they are setup correctly, you can check {{ic|/proc/asound/cardYYY/stream{0,1} }}. Below is list of important endpoints that will help in correctly identifying card connections (it easy to mistake analog and digital input or output connections before you get used to the device):<br />
<br />
{{bc|<nowiki><br />
EP 3 (analgoue output = TRS on back, mirrored on RCA outputs 1 and 2 on back)<br />
EP 4 (digital output = S/PDIF output on back, mirrored on RCA outputs 3 and 4 on back)<br />
EP 5 (analogue input = balanced TRS or XLR microphone, unbalanced TS line on front)<br />
EP 6 (digital input = S/PDIF input on back)<br />
</nowiki>}}<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from command line or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10 channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[https://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio].<br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: https://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
For all your Arch- and ArchAudio-related audio issues hop on to '''IRC''': #archaudio @ Freenode<br />
<br />
== Linux and Arch Linux Pro Audio in the News ==<br />
* [http://www.linuxjournal.com/content/arch-tale An Arch Tale] - Article by fellow musician and writer Dave Phillips, October 2011<br />
<br />
* [http://www.itwire.com/opinion-and-analysis/open-sauce/36698-from-windows-to-linux-a-sound-decision From Windows to Linux: a sound decision] - Interview with Geoff "songshop" Beasley, February 2010</div>Smogehttps://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=187274Unofficial user repositories2012-03-03T03:32:13Z<p>Smoge: /* x86_64 only */</p>
<hr />
<div>[[Category: Package management (English)]]<br />
{{i18n|Unofficial User Repositories}}<br />
<br />
==Why unofficial user repositories==<br />
Since the AUR only allows users to upload PKGBUILD and other package build related files, but does not provide a means for distributing a binary package, a user may want to create a binary repository of their packages elsewhere.<br />
<br />
==The future of Unofficial repos==<br />
I'd like to see more work of this type. Sometimes there are certain projects that don't mesh well with other things, such as the community repo. The 'kdemod' project is a good example. If you want to contribute with your own builds, you can check page [[Custom local repository]].<br />
<br />
In the future, well-thought-out user repositories may be ideal for lots of supplementary things. Forming a "web of trust" is important in cases like this, so we may begin keeping a list of "recommended" repositories somewhere, in order to make it seem more official and trustworthy.<br />
<br />
[[User:Phrakture|Phrakture]] 12:50, 18 May 2007 (EDT)<br />
<br />
==List of PUR (unofficial user repositories)==<br />
===Any===<br />
"Any" repos are architecture-independent, i.e. they can be used on both i686 and x86_64 systems.<br />
{{bc|<nowiki><br />
[arch-fonts]<br />
# Prebuilt packages for font packages found in AUR<br />
# This should be faster than building from source<br />
# as many have download speed of 10KB/s. If you find<br />
# missing font, email to <gmail.com: jesse.jaara><br />
Server = http://huulivoide.pp.fi/Arch/arch-fonts<br />
<br />
[herecura-stable-any]<br />
# Just some stuff; a few java apps, wallpapers, small scripts, xbmc-skin<br />
Server = http://repo.herecura.be/herecura-stable/any<br />
<br />
[herecura-testing-any]<br />
# Some any testing stuff, xbmc-svn skin<br />
Server = http://repo.herecura.be/herecura-testing/any<br />
<br />
[xyne-any]<br />
# The home of Xyne's contributions.<br />
# More info including a package list can be found at http://xyne.archlinux.ca/repos<br />
Server = http://xyne.archlinux.ca/repos/xyne-any/<br />
</nowiki>}}<br />
<br />
===Both i686 and x86_64===<br />
====Signed====<br />
{{bc|<nowiki><br />
[allanbrokeit]<br />
# http://allanmcrae.com/2011/06/the-allanbrokeit-repo-that-might-really-break-your-system/<br />
SigLevel = PackageOptional<br />
Server = http://allanmcrae.com/$repo/$arch<br />
<br />
[crypto]<br />
# Includes tomb, tomb-git and other related software<br />
SigLevel = Required<br />
Server = http://tomb.dyne.org/arch_repo/$arch<br />
<br />
[heftig]<br />
# Includes linux-zen and aurora (firefox development build - works alongside firefox in extra.)<br />
# https://bbs.archlinux.org/viewtopic.php?id=117157<br />
SigLevel = PackageOptional<br />
Server = http://pkgbuild.com/~heftig/repo/$arch<br />
</nowiki>}}<br />
<br />
====Unsigned====<br />
Repositories with both i686 and x86_64 versions. The $arch variable will be set automatically by pacman.<br />
{{bc|<nowiki><br />
[archaudio-production]<br />
# verified PKGBUILDs AND tested packages<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
<br />
[archaudio-preview]<br />
# unverified PKGBUILDs AND/OR untested packages<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
<br />
[archaudio-nightly]<br />
# verified devel PKGBUILDs<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
<br />
[archaudio-experimental]<br />
# unverified devel PKGBUILDs<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
<br />
[archlinuxfr]<br />
# The French Arch Linux communities packages.<br />
Server = http://repo.archlinux.fr/$arch<br />
<br />
[archstuff]<br />
# AUR's most voted and many bin32-* and lib32-* packages.<br />
Server = http://archstuff.vs169092.vserver.de/$arch<br />
<br />
[arsch]<br />
# From users of orgizm.net<br />
Server = http://arsch.orgizm.net/$arch<br />
<br />
[burg]<br />
# Burg bootloader repo<br />
# More info : http://archydeb.wordpress.com/<br />
Server = http://dl.dropbox.com/u/11529444/repos/archlinux/burg/$arch<br />
<br />
[catalyst]<br />
# ATI Catalyst proprietary drivers.<br />
Server = http://catalyst.apocalypsus.net/repo/catalyst/$arch<br />
<br />
[haskell]<br />
# ArchHaskell repository<br />
Server = http://www.kiwilight.com/$repo/$arch<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/$arch<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/$arch<br />
<br />
[kxstudio-free]<br />
# KXStudio Free<br />
Server = http://kxstudio.sf.net/repo/arch/$arch<br />
<br />
[kxstudio-non-free]<br />
# KXStudio Non-Free<br />
Server = http://kxstudio.sf.net/repo/arch/$arch <br />
<br />
[mate]<br />
# Contains official mate desktop packages (gnome2 fork)<br />
Server = http://matsusoft.com.ar/repository/archlinux/mate/$arch<br />
Server = ftp://tridex.net/mate/$arch<br />
<br />
[pfkernel]<br />
# Generic and optimized binaries of the ARCH kernel patched with BFS, TuxOnIce, BFQ, Aufs3<br />
# linux-pf, kernel26-pf, gdm-old, nvidia-pf, nvidia-96xx, xchat-greek, arora-git<br />
Server = http://dl.dropbox.com/u/11734958/$arch<br />
<br />
[radeon]<br />
# ATI Radeon X.Org drivers, bleeding edge 'git' builds.<br />
Server = http://spiralinear.org/perry3d/$arch<br />
<br />
[repo-ck]<br />
# ARCH kernel and modules with Brain Fuck Scheduler and all the goodies in the ck1 patch set<br />
# See the linux-ck wiki page for more<br />
Server = http://repo-ck.com/$arch<br />
<br />
[sergej-repo]<br />
# ion3 and some other stuff.<br />
# http://code.google.com/p/archlinux-stuff/source/browse/trunk<br />
Server = http://repo.p5n.pp.ru/sergej-repo/$arch/<br />
<br />
[suckless]<br />
# suckless.org packages<br />
Server = http://dl.suckless.org/arch/$arch<br />
</nowiki>}}<br />
<br />
===i686 only===<br />
{{bc|<nowiki><br />
[adslgr32]<br />
# The Hellenic (Greek) archlinux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/i686<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.org/linux/repository<br />
Server = http://repo.andrwe.org/i686<br />
<br />
[ayatana]<br />
# GNOME apps: emerillon, glabels, gnome-subtitles, gnome-web-photo, nautilus-sound-converter, ocrfeeder, pdfmod, planner, rygel, transmageddon…<br />
# Mapping apps: bt747, foxtrotgps, gpsprune, marble, merkaartor, navit…<br />
# Other apps with Ayatana support: audio-recorder, cloudsn, deja-dup, gnome-activity-journal, gtg, gwibber, onboard, sbackup, synapse, uget…<br />
# Other apps: backintime, covergloobus, desktopnova, gdesklets, gloobus-preview, keepnote, kompozer, nautilus-terminal, pinta, xnoise…<br />
# Packages from Ubuntu: humanity-icon-theme, ubuntu-light-themes, ubuntuone-client, ubuntu-sounds, notify-osd, indicator-applet…<br />
# More info: http://ayatana.info/<br />
Server = http://repo.ayatana.info/<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
# Updated to June 2008.<br />
Server = http://compiz.dreamz-box.de/i686<br />
<br />
[eee-ck]<br />
# kernel and modules for Asus Eee PC 701, with -ck patchset.<br />
Server = http://dl.dropbox.com/u/15563529/eee-ck<br />
<br />
[esclinux]<br />
# Mostly games, interactive fiction and abc notation stuffs already on AUR.<br />
Server = http://download.tuxfamily.org/esclinuxcd/ressources/repo/i686/<br />
<br />
[jose1711]<br />
# Most of the packages I maintain in AUR (games, tools)<br />
Server = http://arch.l33t.in/i686/<br />
<br />
[kde4-eyecandy-32]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/i686<br />
<br />
[kpiche]<br />
# Stable OpenSync packages.<br />
Server = http://kpiche.archlinux.ca/repo<br />
<br />
[kernel26-pae]<br />
# PAE-enabled 32-bit kernel 2.6.39<br />
Server = http://kernel26-pae.archlinux.ca/<br />
<br />
[linux-pae]<br />
# PAE-enabled 32-bit kernel 3.0<br />
Server = http://pae.archlinux.ca/<br />
<br />
[march]<br />
# most common packages in aur<br />
# readme: http://dl.dropbox.com/u/10527821/repo/i686/readme.txt<br />
# packages: http://dl.dropbox.com/u/10527821/repo/i686/pkglst.txt<br />
Server = http://dl.dropbox.com/u/10527821/repo/i686/<br />
<br />
[mingw32]<br />
# Libs & tools for crosscompiling for Win32, mainly taken from AUR.<br />
# Contact: Alexander 'hatred' Drozdov <adrozdoff [at] gmail (dot) com> (Russian-speaked guys can write on Russian :-)<br />
Server = http://hatred.homelinux.net/archlinux/mingw32/os/i686<br />
<br />
[rfad]<br />
# Repository made by haxit | Contact at: requiem [at] archlinux.us for package suggestions!<br />
Server = http://web.ncf.ca/ey723/archlinux/repo/<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/i686<br />
<br />
[sylar_repo]<br />
# My built packages.<br />
# Additional info and package list: see http://dl.dropbox.com/u/8192972/arch_repo/arch_repo.html<br />
Server = http://dl.dropbox.com/u/8192972/arch_repo/repo<br />
</nowiki>}}<br />
<br />
===x86_64 only===<br />
{{bc|<nowiki><br />
[adslgr64]<br />
# The Hellenic (Greek) archlinux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/x86_64<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.dyndns.org/doku.php/blog/repository<br />
Server = http://repo.andrwe.org/x86_64<br />
<br />
[archstudio]<br />
# Audio and Music Packages <br />
# optimized for Intel Core i3,i5 i7 <br />
# Detais: https://www.xsounds.org/~archstudio<br />
Server = http://www.xsounds.org/~archstudio/x86_64<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
Server = http://compiz.dreamz-box.de/x86_64<br />
<br />
[kde4-eyecandy-64]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/x86_64<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://bugs.arch-nightly.net<br />
Server = http://arch-nightly.net/repo/x86_64<br />
<br />
[pyropeter]<br />
# My AUR packages: https://aur.archlinux.org/packages.php?SeB=m&K=pyropeter<br />
Server = http://keks.selfip.org/arch/pyropeter<br />
<br />
[seiichiro]<br />
# VDR and some plugins, mms, foo2zjs-drivers<br />
Server = http://repo.seiichiro0185.org/x86_64<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/x86_64<br />
<br />
[zen]<br />
# Various and zengeist' AUR packages.<br />
Server = http://zloduch.cz/archlinux/x86_64<br />
</nowiki>}}<br />
<br />
==Add your own repository to this list==<br />
If you have your own repository, please add this to this list, so that all other users knows where to find your packages.</div>Smogehttps://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=179894Unofficial user repositories2012-01-23T18:42:40Z<p>Smoge: /* x86_64 only */</p>
<hr />
<div>[[Category: Package management (English)]]<br />
{{i18n|Unofficial User Repositories}}<br />
<br />
==Why unofficial user repositories==<br />
Since the AUR only allows users to upload PKGBUILD and other package build related files, but does not provide a means for distributing a binary package, a user may want to create a binary repository of their packages elsewhere.<br />
<br />
==The future of Unofficial repos==<br />
I'd like to see more work of this type. Sometimes there are certain projects that don't mesh well with other things, such as the community repo. The 'kdemod' project is a good example. If you want to contribute with your own builds, you can check page [[Custom local repository]].<br />
<br />
In the future, well-thought-out user repositories may be ideal for lots of supplementary things. Forming a "web of trust" is important in cases like this, so we may begin keeping a list of "recommended" repositories somewhere, in order to make it seem more official and trustworthy.<br />
<br />
[[User:Phrakture|Phrakture]] 12:50, 18 May 2007 (EDT)<br />
<br />
==List of PUR (unofficial user repositories)==<br />
===Any===<br />
"Any" repos are architecture-independent, i.e. they can be used on both i686 and x86_64 systems.<br />
{{bc|<nowiki><br />
[herecura-stable-any]<br />
# Just some stuff; a few java apps, wallpapers, small scripts, xbmc-skin<br />
Server = http://repo.herecura.be/herecura-stable/any<br />
<br />
[herecura-testing-any]<br />
# Some any testing stuff, xbmc-svn skin<br />
Server = http://repo.herecura.be/herecura-testing/any<br />
<br />
[xyne-any]<br />
# The home of Xyne's contributions.<br />
# More info including a package list can be found at http://xyne.archlinux.ca/repos<br />
Server = http://xyne.archlinux.ca/repos/xyne-any/<br />
<br />
[arch-fonts]<br />
# Prebuilt packages for font packages found in AUR<br />
# This should be faster than building from source<br />
# as many have download speed of 10KB/s. If you find<br />
# missing font, email to <gmail.com: jesse.jaara><br />
Server = http://huulivoide.pp.fi/Arch/arch-fonts<br />
</nowiki>}}<br />
<br />
===Both i686 and x86_64===<br />
====Signed====<br />
{{bc|<nowiki><br />
[allanbrokeit]<br />
# http://allanmcrae.com/2011/06/the-allanbrokeit-repo-that-might-really-break-your-system/<br />
SigLevel = PackageOptional<br />
Server = http://allanmcrae.com/$repo/$arch<br />
<br />
[heftig]<br />
# Includes linux-zen and aurora (firefox development build - works alongside firefox in extra.)<br />
# https://bbs.archlinux.org/viewtopic.php?id=117157<br />
SigLevel = PackageOptional<br />
Server = http://pkgbuild.com/~heftig/repo/$arch<br />
</nowiki>}}<br />
<br />
====Unsigned====<br />
<!--Not exactly same as 'any' repositories, this section should probably be separate.--><br />
Repositories with both i686 and x86_64 versions. The $arch variable will be set automatically by pacman.<br />
{{bc|<nowiki><br />
[adslgr]<br />
# The Hellenic (Greek) archlinux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/$arch<br />
<br />
[archlinuxfr]<br />
# The French Arch Linux communities packages.<br />
Server = http://repo.archlinux.fr/$arch<br />
<br />
[archaudio-production]<br />
# verified PKGBUILDs AND tested packages<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
<br />
[archaudio-preview]<br />
# unverified PKGBUILDs AND/OR untested packages<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
<br />
[archaudio-nightly]<br />
# verified devel PKGBUILDs<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
<br />
[archaudio-experimental]<br />
# unverified devel PKGBUILDs<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
<br />
[archstuff]<br />
# AUR's most voted and many bin32-* and lib32-* packages.<br />
Server = http://archstuff.vs169092.vserver.de/$arch<br />
<br />
[arsch]<br />
# From users of orgizm.net<br />
Server = http//arsch.orgizm.net/$arch<br />
<br />
[burg]<br />
# Burg bootloader repo<br />
# More info : http://archydeb.wordpress.com/<br />
Server = http://dl.dropbox.com/u/11529444/repos/archlinux/burg/$arch<br />
<br />
[catalyst]<br />
# ATI Catalyst proprietary drivers.<br />
Server = http://catalyst.apocalypsus.net/repo/catalyst/$arch<br />
<br />
[haskell]<br />
# ArchHaskell repository<br />
Server = http://www.kiwilight.com/$repo/$arch<br />
<br />
[repo-ck]<br />
# ARCH kernel and modules with Brain Fuck Scheduler and all the goodies in the ck1 patch set<br />
# See the linux-ck wiki page for more<br />
Server = http://repo-ck.com/$arch<br />
<br />
[kittyserve]<br />
# Contains kittykatt's packages and packages from friends of kittykatt, as well as most mint-related packages<br />
Server = http://repo.kattz.tk/$arch<br />
<br />
[kxstudio-free]<br />
# KXStudio Free<br />
Server = http://kxstudio.sf.net/repo/arch/$arch<br />
<br />
[kxstudio-non-free]<br />
# KXStudio Non-Free<br />
Server = http://kxstudio.sf.net/repo/arch/$arch <br />
<br />
[mate]<br />
# Contains official mate desktop packages (gnome2 fork)<br />
Server = http://matsusoft.com.ar/repository/archlinux/mate/$arch<br />
Server = ftp://tridex.net/mate/$arch<br />
<br />
[radeon]<br />
# ATI Radeon X.Org drivers, bleeding edge 'git' builds.<br />
Server = http://spiralinear.org/perry3d/$arch<br />
<br />
[sergej-repo]<br />
# ion3 and some other stuff.<br />
# http://code.google.com/p/archlinux-stuff/source/browse/trunk<br />
Server = http://repo.p5n.pp.ru/sergej-repo/$arch/<br />
<br />
[suckless]<br />
# suckless.org packages<br />
Server = http://dl.suckless.org/arch/$arch<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/$arch<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/$arch<br />
</nowiki>}}<br />
<br />
===i686 only===<br />
{{bc|<nowiki><br />
[andrwe]<br />
# For a list of packages see: http://andrwe.org/doku.php/linux/repository<br />
Server = http://repo.andrwe.org/i686<br />
<br />
[arch-graphics]<br />
# Repository aimed to provide applications mainly for 3D graphics.<br />
# For more info, look at http://arch-graphics.kx.cz/<br />
Server = http://arch-graphics.kx.cz/repo/i686<br />
<br />
[cgr-i686]<br />
# Packages for some ChicoGeek's PKGBUILDs.<br />
Server = http://cgr.i686.googlepages.com/<br />
<br />
[chaox-stable]<br />
# Pentesting packages and custom kernel patched for WIFI injection.<br />
Server = http://repo.chaox.net/stable<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
# Updated to June 2008.<br />
Server = http://compiz.dreamz-box.de/i686<br />
<br />
[esclinux]<br />
# Mostly games, interactive fiction and abc notation stuffs already on AUR.<br />
Server = http://download.tuxfamily.org/esclinuxcd/ressources/repo/i686/<br />
<br />
[fukawi]<br />
# Some Nagios Stuff; molly-guard; celtx and various networking tools.<br />
Server = http://repo.fukawi2.nl/i686/<br />
Server = ftp://repo.fukawi2.nl/i686/<br />
<br />
[jose1711]<br />
# Most of the packages I maintain in AUR (games, tools)<br />
Server = http://arch.l33t.in/i686/<br />
<br />
[kde4-eyecandy-32]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/i686<br />
<br />
[kpiche]<br />
# Stable OpenSync packages.<br />
Server = http://kpiche.archlinux.ca/repo<br />
<br />
[rfad]<br />
# Repository made by haxit | Contact at: requiem [at] archlinux.us for package suggestions!<br />
Server = http://web.ncf.ca/ey723/archlinux/repo/<br />
<br />
[xdemon-repo]<br />
# madwimax, kismet-svn and aircrack-svn, etc...<br />
Server=http://repo.x-demon.org/archlinux/os/i686<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/i686<br />
<br />
[mingw32]<br />
# Libs & tools for crosscompiling for Win32, mainly taken from AUR.<br />
# Contact: Alexander 'hatred' Drozdov <adrozdoff [at] gmail (dot) com> (Russian-speaked guys can write on Russian :-)<br />
Server = http://hatred.homelinux.net/archlinux/mingw32/os/i686<br />
<br />
[ayatana]<br />
# GNOME apps: emerillon, glabels, gnome-subtitles, gnome-web-photo, nautilus-sound-converter, ocrfeeder, pdfmod, planner, rygel, transmageddon…<br />
# Mapping apps: bt747, foxtrotgps, gpsprune, marble, merkaartor, navit…<br />
# Other apps with Ayatana support: audio-recorder, cloudsn, deja-dup, gnome-activity-journal, gtg, gwibber, onboard, sbackup, synapse, uget…<br />
# Other apps: backintime, covergloobus, desktopnova, gdesklets, gloobus-preview, keepnote, kompozer, nautilus-terminal, pinta, xnoise…<br />
# Packages from Ubuntu: humanity-icon-theme, ubuntu-light-themes, ubuntuone-client, ubuntu-sounds, notify-osd, indicator-applet…<br />
# More info: http://ayatana.info/<br />
Server = http://repo.ayatana.info/<br />
<br />
[sylar_repo]<br />
# My built packages.<br />
# Additional info and package list: see http://dl.dropbox.com/u/8192972/arch_repo/arch_repo.html<br />
Server = http://dl.dropbox.com/u/8192972/arch_repo/repo<br />
<br />
[kernel26-pae]<br />
# PAE-enabled 32-bit kernel 2.6.39<br />
Server = http://kernel26-pae.archlinux.ca/<br />
<br />
[linux-pae]<br />
# PAE-enabled 32-bit kernel 3.0<br />
Server = http://pae.archlinux.ca/<br />
<br />
[aur]<br />
# most common packages in aur<br />
# readme: http://dl.dropbox.com/u/10527821/repo/i686/readme.txt<br />
# packages: http://dl.dropbox.com/u/10527821/repo/i686/pkglst.txt<br />
http://dl.dropbox.com/u/10527821/repo/i686/<br />
<br />
</nowiki>}}<br />
<br />
===x86_64 only===<br />
{{bc|<nowiki><br />
[andrwe]<br />
# For a list of packages see: http://andrwe.dyndns.org/doku.php/blog/repository<br />
Server = http://repo.andrwe.org/x86_64<br />
<br />
[archstudio]<br />
# Pro Audio Packages <br />
# optimized for Intel Core {i3,i5,i7} CPU <br />
# Detais: http://www.bbarros.com/archstudio<br />
Server = http://www.bbarros.com/archstudio/x86_64<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
Server = http://compiz.dreamz-box.de/x86_64<br />
<br />
[kde4-eyecandy-64]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/x86_64<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://bugs.arch-nightly.net<br />
Server = http://arch-nightly.net/repo/x86_64<br />
<br />
[zen]<br />
# Various and zengeist' AUR packages.<br />
Server = http://zloduch.cz/archlinux/x86_64<br />
<br />
[seiichiro]<br />
# VDR and some plugins, mms, foo2zjs-drivers<br />
Server = http://repo.seiichiro0185.org/x86_64<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/x86_64<br />
<br />
[pyropeter]<br />
# My AUR packages: https://aur.archlinux.org/packages.php?SeB=m&K=pyropeter<br />
Server = http://keks.selfip.org/arch/pyropeter<br />
</nowiki>}}<br />
<br />
==Add your own repository to this list==<br />
If you have your own repository, please add this to this list, so that all other users knows where to find your packages.</div>Smogehttps://wiki.archlinux.org/index.php?title=List_of_applications&diff=170180List of applications2011-11-15T19:18:51Z<p>Smoge: /* BitTorrent Clients */</p>
<hr />
<div>[[Category:Software (English)]]<br />
{{i18n|Common Applications}}<br />
==Backup programs==<br />
{{Box||See the article on this subject: [[Backup Programs]]|#E5E5FF|#FCFCFC}}<br />
*{{App|[[Wikipedia:DAR (Disk Archiver)|DAR]]|A full-featured command-line backup tool, short for Disk ARchive|http://dar.linux.free.fr/|{{Pkg|dar}}}}<br />
*{{App|[[Duplicity|duplicity]]|A utility for encrypted, bandwidth-efficient backups using the rsync algorithm|http://www.nongnu.org/duplicity/|{{Pkg|duplicity}}}}<br />
*{{App|Packrat|A simple, modular backup system that uses dar to take full/incremental backups of files and can store them locally, on a remote system via SSH, or on Amazon S3|http://www.zeroflux.org/projects|{{AUR|packrat}}}}<br />
*{{App|[[Wikipedia:Rsync#Variations|rdiff-backup]]|A utility for local/remote mirroring and incremental backups|http://www.nongnu.org/rdiff-backup/|{{Pkg|rdiff-backup}}}}<br />
*{{App|rsnapshot|A remote filesystem snapshot utility|http://www.rsnapshot.org/|{{Pkg|rsnapshot}}}}<br />
*{{App|[[Rsync|rsync]]|A file transfer program to keep remote files in sync|http://rsync.samba.org/|{{Pkg|rsync}}}}<br />
*{{App|Safekeep|A client/server backup system which enhances the power of rdiff-backup|http://safekeep.sourceforge.net/|{{AUR|safekeep}}}}<br />
*{{App|Unison|Synchronizes files between two machines over network (Lan or Inet) using smart diff method + rsync, allows one to interactively choose which changes to push, pull, or merge. |http://www.cis.upenn.edu/~bcpierce/unison/|{{Pkg|unison}}}}<br />
<br />
==Internet==<br />
===BitTorrent Clients===<br />
<!--Keep in sync with [[Lightweight Applications]] and use the App template.--><br />
{{Wikipedia|Comparison of BitTorrent clients}}<br />
*{{App|[[aria2]]|Command-line download manager that supports HTTP/HTTPS, FTP, BitTorrent and MetaLink protocols|http://aria2.sourceforge.net/|{{Pkg|aria2}}}}<br />
*{{App|[[Deluge]]|User-friendly BitTorrent client written in Python and wrapped with PyGTK|http://deluge-torrent.org/|{{Pkg|deluge}}}}<br />
*{{App|[[Wikipedia:KTorrent|KTorrent]]|Feature-rich BitTorrent client developed using Qt|http://ktorrent.org/|{{Pkg|ktorrent}}}}<br />
*{{App|[[Wikipedia:MLDonkey|MLDonkey]]|Multi-protocol P2P client supporting BitTorrent|http://mldonkey.sourceforge.net/|{{Pkg|mldonkey}}}}<br />
*{{App|[[Wikipedia:QBittorrent|qBittorrent]]|The closest open source (GNU GPL v2 license) equivalent to µtorrent|http://qbittorrent.sourceforge.net/|{{Pkg|qbittorrent}}}}<br />
*{{App|[[rTorrent]]|Simple and lightweight ncurses BitTorrent client|http://libtorrent.rakshasa.no/|{{Pkg|rtorrent}}}}<br />
*{{App|[[Wikipedia:Transmission (BitTorrent client)|Transmission]]|Simple and easy-to-use BitTorrent client with daemon version, GTK+, Qt GUI, web and CLI front-ends|http://www.transmissionbt.com/|{{Pkg|transmission}}}}<br />
*{{App|[[Wikipedia:Vuze|Vuze]]|Feature-rich BitTorrent client written in Java (formerly Azureus)|http://www.vuze.com/|{{Pkg|vuze}}}}<br />
<br />
===eDonkey Clients===<br />
eDonkey is still the second-largest p2p network (see [http://www.ipoque.com/en/resources/internet-studies Internet Study 2008/2009]).<br />
*{{App|[[aMule]]|Well-known eDonkey/Kad client with daemon version and GTK, web, and CLI front-ends|http://www.amule.org/|{{Pkg|amule}}}}<br />
<br />
===Chat Clients===<br />
====IRC Clients====<br />
{{Wikipedia|Comparison of Internet_Relay_Chat_clients}}<br />
* {{App|Conspire|Lightweight, simple, and powerful|http://nenolod.net/|{{AUR|conspire-client}}}}<br />
* {{App|ERC|A powerful, modular, and extensible IRC client for [[Emacs]]|http://erc.sourceforge.net/|{{AUR|erc-git}}}}<br />
* {{App|II|A featherweight IRC client, literally `tail -f` the convo and `echo` back your replies|http://tools.suckless.org/ii|{{AUR|ii}}}}<br />
* {{App|Ircfs|A file system interface to irc written in [http://limbo.cat-v.org Limbo]|http://www.ueber.net/code/r/ircfs|}}<br />
* {{App|[[Irssi]]|Highly-configurable ncurses-based IRC client|http://www.irssi.org/|{{Pkg|irssi}}}}<br />
* {{App|[[Wikipedia:Konversation|Konversation]]|Qt-based IRC client for the KDE4 desktop|http://konversation.kde.org/|{{Pkg|konversation}}}}<br />
* {{App|[[Wikipedia:KVIrc|KVIrc]]|Qt-based IRC client featuring extensive themes support|http://www.kvirc.net/|{{Pkg|kvirc}}}}<br />
* {{App|Loqui|A GTK IRC client with only one dependency|https://launchpad.net/loqui|{{AUR|loqui}}}}<br />
* {{App|LostIRC|A simple IRC client|http://lostirc.sourceforge.net|{{AUR|lostirc}}}}<br />
* {{App|pcw|A frontend for [http://tools.suckless.org/ii ii] that opens a new terminal for each channel (depends on [http://bitbucket.org/emg/srw srw] by default)|http://bitbucket.org/emg/pcw|{{AUR|pcw-hg}}}}<br />
* {{App|ScrollZ|An advanced IRC client based on ircII|http://www.scrollz.com|{{AUR|scrollz}}}}<br />
* {{App|[[Wikipedia:WeeChat|WeeChat]]|Modular, lightweight ncurses-based IRC client|http://www.weechat.org/|{{Pkg|weechat}}}}<br />
* {{App|[[Wikipedia:XChat|XChat]]|GTK-based IRC client|http://xchat.org/|{{Pkg|xchat}}}}<br />
<br />
==== Jabber/XMPP Clients ====<br />
* {{App|Finch| A CLI Jabber/aim/etc/etc chat client based on libpurple (part of Pidgin) |http://developer.pidgin.im/wiki/Using%20Finch|{{Pkg|finch}}}}<br />
* {{App|Freetalk|A console based Jabber client|http://www.gnu.org/software/freetalk/|{{Pkg|freetalk}}}}<br />
* {{App|[[Wikipedia:Gajim|Gajim]]|Jabber client written in PyGTK|http://www.gajim.org/|{{Pkg|gajim}}}}<br />
* {{App|jabber.el|A minimal jabber client for emacs|http://emacs-jabber.sourceforge.net/|{{AUR|emacs-jabber}}}}<br />
* {{App|[[Wikipedia:MCabber|MCabber]]|A small Jabber console client, includes features: SSL, PGP, MUC, and UTF8|http://mcabber.com/|{{Pkg|mcabber}}}}<br />
* {{App|[[Wikipedia:Psi (instant messaging client)|Psi]]|A Qt based Jabber client|http://psi-im.org/|{{Pkg|psi}}}}<br />
* {{App|Psi+|Psi+ is an enhanced version of Psi Jabber client.|http://code.google.com/p/psi-dev/|{{AUR|psi-plus}}}}<br />
<br />
==== MSN Clients ====<br />
* {{App|[[Wikipedia:AMSN|aMSN]]|MSN client written in Tcl/Tk|http://www.amsn-project.net/|{{Pkg|amsn}}}}<br />
* {{App|[[Wikipedia:Emesene|Emesene]]|A pygtk MSN Messenger client|http://www.emesene.org/|{{Pkg|emesene}}}}<br />
* {{App|Galaxium Messenger|A multi-protocol instant messenger application designed for the GNOME desktop|http://code.google.com/p/galaxium/|{{AUR|galaxium}}}}<br />
* {{App|[[Wikipedia:Kmess|KMess]]|KMess is a MSN Messenger client for Linux|http://kmess.org/|{{Pkg|kmess}}}}<br />
* {{App|[[Wikipedia:Mercury Messenger|Mercury]]|Java Based MSN client|http://www.mercury.im/|{{Pkg|mercury}}}}<br />
<br />
==== Multi-Protocol Clients ====<br />
{{Wikipedia|Comparison of instant messaging clients}}<br />
<br />
* {{App|BarnOwl|A console chat client for the AIM, IRC, Jabber, and Zephyr protocols|http://barnowl.mit.edu/|{{AUR|barnowl}}}}<br />
* {{App|[[Bitlbee]]|A way to use other IM to your [[#IRC]] client|http://www.bitlbee.org/|{{Pkg|bitlbee}}}}<br />
* {{App|Carrier|Pidgin fork providing minor GUI enhancements (formerly funpidgin)|http://funpidgin.sourceforge.net/|{{AUR|carrier}}}}<br />
* {{App|[[Wikipedia:Centericq|CenterIM]]|Fork of CenterICQ - A text mode menu- and window-driven IM interface|http://www.centerim.org/index.php/Main_Page|{{Pkg|centerim}}}}<br />
* {{App|[[Wikipedia:Emesene|Emesene]]|A Python/GTK+ instant messenger for the Windows Live Messenger network|http://www.emesene.org/|{{Pkg|emesene}}}}<br />
* {{App|[[Wikipedia:Empathy (software)|Empathy]]|A GNOME instant messaging client using the Telepathy framework|http://live.gnome.org/Empathy|{{Pkg|empathy}}}}<br />
* {{App|Finch|A ncurses-based messaging client|http://pidgin.im/|{{Pkg|finch}}}}<br />
* {{App|[[Wikipedia:Instantbird|Instantbird]]|Multiprotocol chat client using Mozilla's XUL and libpurple.|http://www.instantbird.com/|{{AUR|instantbird}}}}<br />
* {{App|[[Wikipedia:Kopete|Kopete]]|Instant Messenger|http://www.kde.org/|{{Pkg|kopete}}}}<br />
* {{App|[[Pidgin]]|Multi-protocol instant messaging client|http://pidgin.im/|{{Pkg|pidgin}}}}<br />
** {{App|Pidgin Light|A light Pidgin version without gstreamer, tcl, tk, xscreensaver support|http://www.pidgin.im/|{{AUR|pidgin-light}}}}<br />
* {{App|[[Wikipedia:QutIM|qutIM]]|Multiplatform instant messenger|http://qutim.org/|{{AUR|qutim}}}}<br />
<br />
===Email clients===<br />
<!--Keep in sync with [[Lightweight Applications]] and use the App template.--><br />
{{Wikipedia|Comparison of e-mail clients}}<br />
====Console====<br />
*{{App|[[Alpine]]|The Apache-licensed PINE (a tool for reading, sending, and managing electronic messages)|http://www.washington.edu/alpine|{{Pkg|alpine}}}}<br />
*{{App|[[Wikipedia:Gnus|Gnus]]|mail, nntp, rss client for Emacs.|http://www.gnus.org/|[[package]]}}<br />
*{{App|[[Wikipedia:mailx|heirloom-mailx]]|A full-featured command-line MUA derived from Berkeley Mail.|http://heirloom.sourceforge.net/mailx.html|{{Pkg|heirloom-mailx}}}}<br />
*{{App|[[mutt]]|Small but very powerful text-based mail client.|http://www.mutt.org/|{{Pkg|mutt}}}}<br />
*{{App|[[Sup]]|A CLI mail client with very fast searching, tagging, threading and gmail like operation.|http://sup.rubyforge.org/|{{AUR|sup}}}}<br />
<br />
====Graphical====<br />
*{{App|[[Wikipedia:Claws Mail|Claws Mail]]|A GTK+ based e-mail client|http://www.claws-mail.org/|{{Pkg|claws-mail}}}}<br />
*{{App|[[Evolution]]|A mature and feature-rich e-mail client used in GNOME by default.|http://projects.gnome.org/evolution/|{{Pkg|evolution}}}}<br />
*{{App|[[Wikipedia:Kmail|Kmail]]|A mature and feature-rich e-mail client part of the kde project.|http://kontact.kde.org/kmail/{{Linkrot|2011|09|03}}|{{Pkg|kmail}}}}<br />
*{{App|[[Postler]]|simple desktop mail client built in vala.|http://git.xfce.org/apps/postler|{{AUR|postler}}}}<br />
*{{App|[[Wikipedia:Sylpheed|Sylpheed]]|Lightweight and user-friendly e-mail client (GTK)|http://sylpheed.sraoss.jp/en/|{{AUR|sylpheed}}}}<br />
*{{App|[[Thunderbird]]|Mozilla's GTK2-based client.|http://www.mozillamessaging.com/en-US/|{{Pkg|thunderbird}}}}<br />
<br />
===Network Managers===<br />
<!--Use the App template.--><br />
*{{App|[[netcfg]]|Network configuration and profile scripts|http://projects.archlinux.org/netcfg.git/|{{Pkg|netcfg}}}}<br />
*{{App|[[Wicd|wicd]]|Manages wireless and wired interfaces, requiring fewer dependencies than other network managers. In addition to GUI interfaces, a curses version is also available.|http://wicd.sourceforge.net/|{{Pkg|wicd}}}}<br />
*{{App|[[networkmanager|networkmanager]]|Networkmanager provides wired, wireless, mobile broadband and OpenVPN detection and configuration allowing automatic connection to a network.|http://projects.gnome.org/NetworkManager/|{{Pkg|networkmanager}}}}<br />
<br />
===News Aggregators===<br />
{{Wikipedia|Comparison of feed aggregators}}<br />
* [[Akregator]] - KDE's news aggregator (in kdepim package)<br />
* [[BlogBridge]] - Another excellent java-based aggregator http://www.blogbridge.com<br />
* {{App|[[Wikipedia:Canto_(news_aggregator)|Canto]]|A ncurses RSS aggregator|http://codezen.org/canto/|{{AUR|canto}}}}<br />
* {{App|[[Wikipedia:Gnus|Gnus]]|A mail, nntp, rss client for Emacs|http://www.gnus.org/|{{AUR|emacs-gnus-git}}}}<br />
* {{App|[[Liferea]] | A GTK desktop news aggregator for online news feeds and weblogs| http://liferea.sourceforge.net|{{AUR|liferea}}}}<br />
* {{App|Newsbeuter|A ncurses RSS aggregator with layout and keybinding similar to mutt. Does not use the traditional 3 panes setup|http://www.newsbeuter.org/|{{Pkg|newsbeuter}}}}<br />
* {{App|Rawdog|A "RSS Aggregator Without Delusions Of Grandeur" that parses RSS/CDF/Atom feeds into a static HTML page of articles in date order|http://offog.org/code/rawdog.html|{{AUR|rawdog}}}}<br />
* [[Rssowl]] - A powerful java-based RSS reader http://boreal.rssowl.org<br />
* {{App|Snownews|Text mode RSS newsreader|http://kiza.kcore.de/software/snownews/|{{Pkg|snownews}}}}<br />
* [[Thunderbird]] - A mail client from Mozilla which also functions as a pretty nice news aggregator<br />
<br />
=== Web Browsers ===<br />
{{Wikipedia|Comparison of web browsers}}<br />
==== Text Based ====<br />
* {{App|[[Wikipedia:ELinks|ELinks]]|An advanced and well-established feature-rich text mode web browser|http://elinks.or.cz/|{{Pkg|elinks}}}}<br />
* {{App|[[Wikipedia:Links (web browser)|Links]]|A text WWW browser, similar to Lynx|http://links.twibright.com/|{{Pkg|links}}}}<br />
* [[Lynx]] A text browser for the World Wide Web http://lynx.isc.org<br />
* [[w3m]] A pager/text-based WWW browser http://w3m.sourceforge.net/<br />
<br />
==== Graphical ====<br />
* {{App|[[Wikipedia:Abaco (web browser)|Abaco]]|A multi-page graphical web browser|http://lab-fgb.com/abaco/|{{AUR|abaco}}}}<br />
* {{App|[[Wikipedia:Arora (browser)|Arora]]|A cross platform web browser built using Qt and WebKit|http://code.google.com/p/arora/|{{Pkg|arora}}}}<br />
* {{App|[[Wikipedia:Conkeror|Conkeror]]|A highly programmable web browser based on Mozilla XULRunner|http://conkeror.org/|{{Pkg|conkeror}}}}<br />
* [[Chromium]] - The open-source project behind Google Chrome, a web browser developed by Google that uses the WebKit layout engine and application framework. http://code.google.com/chromium/<br />
* {{App|[[Wikipedia:Dillo|Dillo]]|A small, fast graphical web browser built on FLTK|http://www.dillo.org/|{{Pkg|dillo}}}}<br />
* [[Epiphany]] - The default GNOME browser, which uses the webkit rendering engine. http://projects.gnome.org/epiphany/<br />
* [[Firefox]] - [https://addons.mozilla.org/firefox/ Extensible] GTK2 browser based on Gecko with fast rendering. http://www.mozilla.com/firefox/<br />
* {{App|Hv3|A minimalist web browser based on tkhtml3|http://tkhtml.tcl.tk/hv3.html|{{AUR|hv3}}}}<br />
* {{App|[[Jumanji]]|A highly customizable and functional web browser|http://pwmt.org/projects/jumanji|{{AUR|jumanji}}}}<br />
* [[Kazehakase]] - A much lighter, but rather feature-lacking alternative to other browsers (GTK2 and Gecko). http://kazehakase.sourceforge.jp/<br />
* [[Konqueror]] - Qt- and KHTML-based browser. A part of the KDE desktop. http://www.konqueror.org/<br />
* {{App|Luakit| A highly configurable, micro-browser framework based on the WebKit web content engine and the GTK+ toolkit. It is very fast, extensible by Lua and licensed under the GNU GPLv3 license|http://luakit.org/projects/luakit/|{{Pkg|luakit}}}}<br />
* {{App|[[Wikipedia:Midori (web browser)|Midori]]| A lightweight web browser based on Gtk and WebKit. It passes the ACID3 test|http://www.twotoasts.de/index.php?/pages/midori_summary.html|{{Pkg|midori}}}}<br />
* {{App|[[Wikipedia:NetSurf|NetSurf]]| A featherweight browser written in C. Notable is its lack of JavaScript support and fast rendering through its own custom rendering engine|http://www.netsurf-browser.org Netsurf|{{Pkg|netsurf}}}}<br />
* [[Opera]] - Highly customizable browser with focuses on an adherence to web rendering standards http://www.opera.com/<br />
* {{App|[[wikipedia:Rekonq|Rekonq]]| A WebKit based web browser for KDE|http://rekonq.kde.org/|{{Pkg|rekonq}}}}<br />
* {{App|Sb|A very lightweight webkit-based browser that uses keybindings to perform most things the URL bar would usually do|https://github.com/mutantturkey/sb/|{{AUR|sb-git}}}} <br />
* {{App|Surf|Another lightweight WebKit-based browser, which follows the [[suck less philosophy|suckless ideology]]. Which means, the software is even more lightweight (basically, the browser itself is a single C source file)|http://surf.suckless.org|{{AUR|surf-hg}}}}<br />
* {{App|[[Wikipedia:Uzbl|Uzbl]]|Web interface tools which adhere to the unix philosophy|http://www.uzbl.org/|{{Pkg|uzbl-browser}}}}<br />
* {{App|[[Vimprobable]]|A browser that behaves like the Vimperator plugin available for Mozilla Firefox. It is based on the WebKit engine (using GTK bindings)|http://vimprobable.org/|{{AUR|vimprobable}}}}<br />
<br />
=== Microblogging Clients ===<br />
* [[Gwibber]] - Gwibber is an open source microblogging client for Linux. It brings the most popular social networking web services to your desktop and gives you the ability to control how you communicate. http://gwibber.com/<br />
* [[Hotot]] - Hotot, is a lightweight & open source Microblogging Client, coding using Python language and designed for Linux. http://hotot.org<br />
* [[Pino]] - Pino is a simple and fast X11 client for Twitter and Identi.ca. It is compiled to native code, which assures small size and speed, and thanks to use of Vala language it can perfectly integrate into your Gnome or XFCE desktop. http://pino-app.appspot.com/<br />
<br />
===FTP Clients===<br />
*{{App|[[curlftp]]| A filesystem for acessing FTP hosts based on FUSE and libcurl. |http://curlftpfs.sourceforge.net/|{{Pkg|curlftpfs}}}}<br />
*{{App|[[fuseftp]]| FTP filesystem written in Perl, using FUSE|http://freshmeat.net/projects/fuseftp/|{{AUR|fuseftp}}}}<br />
<br />
== Document Indexers ==<br />
* [[pinot]] - Personal search and metasearch tool http://pinot.berlios.de/<br />
* [[recoll]] - Full text search tool based on Xapian backend http://www.lesbonscomptes.com/recoll/<br />
<br />
== Document Readers ==<br />
*{{App|apvlv|A lightweight PDF viewer with VIM key bindings|http://code.google.com/p/apvlv/|{{Pkg|apvlv}}}}<br />
*{{App|ePDFView|A free lightweight PDF document viewer using Poppler and GTK+ libraries|http://www.emma-soft.com/projects/epdfview/|{{Pkg|epdfview}}}}<br />
*[[Evince]] - Document viewer for multiple document formats. Supports pdf, postscript, djvu, tiff and dvi http://projects.gnome.org/evince/<br />
*[[Foxit Reader]] - A small, fast PDF viewer http://www.foxitsoftware.com/pdf/desklinux/<br />
*{{App|fbpdf|A small framebuffer PDF viewer based off of MuPDF, with VIM keybindings, written in C|http://repo.or.cz/w/fbpdf.git|{{AUR|fbpdf-git}}}}<br />
*{{App|llpp|A very fast PDF reader based off of MuPDF, that supports continuous page scrolling, bookmarking, and text search through the whole document|http://repo.or.cz/w/llpp.git|{{AUR|llpp}}}}<br />
*{{App|MuPDF|A very fast PDF viewer and toolkit written in portable C. Features CJK font support|http://ccxvii.net/mupdf|{{Pkg|mupdf}}}}<br />
*[[Okular]] r for KDE. http://okular.kde.org/<br />
*{{App|Xpdf|A viewer for Portable Document Format (PDF) files|http://www.foolabs.com/xpdf/|{{Pkg|xpdf}}}}<br />
*{{App|zathura|Another lightweight PDF viewer similar to apvlv, only lighter|http://zathura.pwmt.org/projects/zathura|{{Pkg|zathura}}}}<br />
<br />
== Multimedia ==<br />
=== Audio ===<br />
{{Wikipedia|Comparison of audio player software}}<br />
====Music player daemon and clients====<br />
<br />
[[Music Player Daemon]] - a lightweight and scalable choice for music management<br />
*{{App|Ario|A very feature-rich GTK2 GUI client for mpd, inspired by Rhythmbox|http://ario-player.sourceforge.net/|{{Pkg|ario}}}}<br />
*{{App|ncmpc|A curses client for mpd|http://mpd.wikia.com/wiki/Client:Ncmpc|{{Pkg|ncmpc}}}}<br />
*{{App|ncmpcpp|An almost exact clone of ncmpc with some new features|http://unkart.ovh.org/ncmpcpp/|{{Pkg|ncmpcpp}}}}<br />
*{{App|QmpdClient|A GUI client Qt4 based for mpd|http://bitcheese.net/wiki/QMPDClient|{{Pkg|qmpdclient}}}}<br />
*{{App|Sonata|An elegant GTK+ music GUI client for mpd|http://sonata.berlios.de/|{{Pkg|sonata}}}}<br />
<br />
====Command line players====<br />
*{{App|Herrie|A minimalistic console-based music player with native AudioScrobbler support|http://herrie.info/|{{AUR|herrie}}}}<br />
*{{App|[[Wikipedia:Mpg123|Mpg123]]|A fast free MP3 console audio player for Linux, FreeBSD, Solaris, Hpux and near all other UNIX systems. Also decodes mp1 and mp2 files|http://www.mpg123.org/|{{Pkg|mpg123}}}}<br />
<br />
====GUI players====<br />
* [[Amarok]] - A mature Qt-based player known for its plethora of features<br />
* [http://www.atunes.org/ aTunes] - An audio-player written in Java<br />
* [[Audacious]] - A Winamp clone like Beep and old XMMS versions<br />
* [http://banshee.fm/ Banshee] - yet another GTK2 iTunes clone, yet more feature-rich and more actively developed.<br />
* [http://www.clementine-player.org/ Clementine] - Amarok 1.4 ported to QT4<br />
* {{App|DeaDBeeF|A light and fast music player with many features, no GNOME or KDE dependencies, supports console-only and as well GTK2-gui, comes with many plugins, and has a metadata editor|http://deadbeef.sourceforge.net/|{{Pkg|deadbeef}}}}<br />
* [[Exaile]] - A GTK2 clone of Amarok<br />
* {{App|[[Goggles Music Manager]]|A music collection manager and player that automatically categorizes your music, supports gapless playback, features easy tag editing, and internet radio support. Uses the [[Fox Toolkit]].|http://code.google.com/p/gogglesmm/|{{Pkg|gogglesmm}}}}<br />
* [http://guayadeque.org/ Guayadeque] - A full featured media player that can easily manage large collections and uses the Gstreamer media framework.<br />
* {{App|Potamus|A lightweight, intuitive GTK+ audio player with an emphasis on high audio quality|http://offog.org/code/potamus.html|{{AUR|potamus}}}}<br />
* {{App|Pragha|A GTK+ music manager that was a fork of Consonance Music Manager|http://pragha.wikispaces.com/|{{Pkg|pragha}}}}<br />
* [http://code.google.com/p/quodlibet/ Quod Libet] - an audio player written with pygtk and gstreamer<br />
* [[Rhythmbox]] - A GTK2 clone of iTunes, used by default in GNOME<br />
* [http://getnightingale.com/ Nightingale] - ([http://getsongbird.com/ Songbird] for linux) an open source clone of iTunes that uses Mozilla technologies as well as Gstreamer and is being developed by the team that made WinAMP<br />
* [http://legacy.xmms2.org/ XMMS] - A skinnable GTK+1 standalone media player similar to winamp<br />
<br />
====Text user interface players====<br />
* {{App|[[Wikipedia:cmus|cmus]]|A very feature-rich ncurses-based music player|http://cmus.sourceforge.net/|{{Pkg|cmus}}}}<br />
* {{App|cplay|A curses front-end for various audio players|http://sourceforge.net/projects/cplay/{{Linkrot|2011|09|04}}|{{AUR|cplay}}}}<br />
* {{App|[[Moc]]|A ncurses console audio player with support for the MP3, Ogg, and WAV formats|http://moc.daper.net/|{{Pkg|moc}}}}<br />
* [http://www.luga.de/pytone/ PyTone] - An advanced music jukebox with a console interface<br />
<br />
====Ripping from CD====<br />
*{{App|abcde|Comprehensive command line tool for ripping audio CDs|http://lly.org/~rcw/abcde/page/|{{Pkg|abcde}}}}<br />
<br />
==== Visualization ====<br />
* [http://projectm.sourceforge.net/ projectM]<br />
<br />
==== Editing ====<br />
* [http://audacity.sourceforge.net/ Audacity]<br />
* [http://kwave.sourceforge.net/ Kwave]<br />
<br />
=== Graphics and Image Manipulation ===<br />
* [[Blender]]<br />
* {{App|darktable|A photography workflow and RAW development application|http://www.darktable.org//|{{Pkg|darktable}}}}<br />
* [[Dia]]<br />
* [[Gimp]]<br />
* [[graphicsmagick]]<br />
* [[imagemagick]]<br />
* [[Inkscape]]<br />
* [[Krita]]<br />
* {{App|mtPaint|A graphic editing program geared towards creating indexed palette images and pixel art|http://mtpaint.sourceforge.net/|{{Pkg|mtpaint}}}}<br />
* [[mypaint]]<br />
* [[Nathive]]<br />
* [[Shotwell]]<br />
* [[Xara]]<br />
<br />
===Image Viewers===<br />
{{Wikipedia|Comparison of image viewers}}<br />
*{{App|[[Feh]]|A fast, lightweight image viewer that uses imlib2|http://linuxbrit.co.uk/feh/|{{Pkg|feh}}}}<br />
*{{App|GalaPix|OpenGL-based image viewer for simultaneously viewing and zooming large collection of image files|http://code.google.com/p/galapix/|{{AUR|galapix}}}}<br />
*{{App|GpicView|A simple and fast image viewer for X. Made by the developers of [[LXDE]]|http://lxde.sourceforge.net/gpicview/|{{Pkg|gpicview}}}}<br />
*{{App|[[Wikipedia:GQview|GQview]]|An image browser that features single click access to view images and move around the directory tree|http://gqview.sourceforge.net/|{{Pkg|gqview}}}}<br />
*{{App|Geeqie|An image browser/viewer fork of GQview. Adds additional functionality such as support for RAW files|http://geeqie.sourceforge.net/|{{Pkg|geeqie}}}}<br />
*{{App|Mirage|PyGTK image viewer featuring support for crop and resize, custom actions and a thumbnail panel|http://mirageiv.berlios.de|{{Pkg|mirage}}}}<br />
*{{App|QIV|A very small and fast gdk/Imlib image viewer|http://spiegl.de/qiv/|{{Pkg|qiv}}}}<br />
*{{App|Ristretto|A fast and lightweight picture-viewer for the Xfce desktop environment|http://goodies.xfce.org/projects/applications/ristretto|{{Pkg|ristretto}}}}<br />
*{{App|SXIV|Simple X Image Viewer; works well with tiling window managers, uses imlib2|http://github.com/muennich/sxiv|{{AUR|sxiv}}}}<br />
*{{App|Viewnior|Minimalistic GTK2 viewer featuring support for flip, rotate, animations and configurable mouse actions|http://xsisqox.github.com/Viewnior/about.html|{{Pkg|viewnior}}}}<br />
*{{App|Xloadimage|The classic X image viewer|http://web.archive.org/web/19981207030422/http://world.std.com/~jimf/xloadimage.html|{{Pkg|xloadimage}}}}<br />
*{{App|XnView|An efficient image viewer, browser and converter|http://www.xnview.com/|{{AUR|xnview}}}}<br />
<!-- Broken links, need to be turned into App Templates.<br />
* [[Background Setter]]<br />
* [[eog]]<br />
* [[GQview]]<br />
* [[gThumb]]<br />
* [[Quick Image Viewer]]<br />
* [[XnView]]<br />
* [[xv]]<br />
* [[Picasa]]<br />
--><br />
<br />
=== Phone ===<br />
* [[moto4lin]]<br />
<br />
=== Video Players===<br />
{{Wikipedia|Comparison of video player software}}<br />
====Console====<br />
*{{App|[[mplayer]]|Support a complete and versatile array of video/audio formats|http://www.mplayerhq.hu/design7/news.html|{{Pkg|mplayer}}}}<br />
<br />
====Graphical====<br />
*{{App|[[Wikipedia:Kdemultimedia#Dragon Player|Dragon Player]]|A simple video player for KDE 4 developed by Ian Monroe.|http://www.dragonplayer.net/|{{Pkg|kdemultimedia-dragonplayer}}}}<br />
*{{App|Gnome-Mplayer|A simple GTK-based GUI for [[mplayer]]|http://kdekorte.googlepages.com/gnomemplayer|{{Pkg|gnome-mplayer}}}}<br />
*{{App|[[Parole]]|A modern media player based on the GStreamer framework|http://goodies.xfce.org/projects/applications/parole/|{{AUR|parole}}}}<br />
*{{App|[[Wikipedia:SMPlayer|SMPlayer]]|A middleweight QT frontend for mplayer with additional patches|http://smplayer.sourceforge.net/|{{Pkg|smplayer}}}}<br />
*{{App|[[Wikipedia:VLC media player|VLC media player]]|A middleweight video player with support for a wide variety of audio/video formats|http://www.videolan.org/vlc/|{{Pkg|vlc}}}}<br />
*{{App|[[Whaaw! Media Player]]|A lightweight Gstreamer-based audio/video player that can serve as a good alternative to Totem for those who do not like all those GNOME dependencies.|http://home.gna.org/whaawmp/|[[package]]}}<br />
*{{App|Xnoise|A GTK+ media player for both audio and video with "a slick GUI, great speed and lots of features.". Uses gstreamer.|http://www.xnoise-media-player.com/|{{AUR|xnoise}}}}<br />
<br />
=== Video Editors ===<br />
* http://www.pitivi.org/ {{AUR|pitivi}}<br />
* http://lives.sourceforge.net/ {{AUR|lives}}<br />
* http://www.openmovieeditor.org/ {{Pkg|openmovieeditor}}<br />
* [http://www.openshotvideo.com/ openshotvideo]<br />
* http://www.avidemux.org/ {{Pkg|avidemux}}<br />
* http://kdenlive.org/ {{Pkg|kdenlive}}<br />
* [http://www.kinodv.org/ kinodv]<br />
* http://cinelerra.org/ {{Pkg|cinelerra-cv}}<br />
<br />
== Note Taking Organizers ==<br />
===Console===<br />
*{{App|todo.txt|Manages your Todo list from the command line|http://ginatrapani.github.com/todo.txt-cli/|{{AUR|todotxt}}}}<br />
*{{App|Taskwarrior|Another cli todo list application with support for lua customization and more|http://taskwarrior.org|Available in the community repository as "task".}}<br />
<br />
===Graphical===<br />
* [[Cherrytree]] - A hierarchical note taking application [http://www.giuspen.com/cherrytree/ Home page]<br />
* {{AUR|glista}} with notes support [http://prematureoptimization.org/glista/downloads.php Home page]<br />
* [[Gnote]] - Gnote is an experimental port of Tomboy to C++ [http://live.gnome.org/Gnote Home page]<br />
* [[hnb]] - A program to organize many kinds of data in one place [http://hnb.sourceforge.net/ Home page] [http://aur.archlinux.org/packages.php?ID=16630 Package]<br />
* {{AUR|KeepNote}} A cross-platform GTK note-taking app with rich text formatting [http://keepnote.org Home page]<br />
* [[NoteCase]] - A portable hierarchical note manager, coded in C++ using the GTK+ toolkit [http://notecase.sourceforge.net Home page]<br />
* {{App|[[Wikipedia:Org-mode|org-mode]]|An [[Emacs]] Mode for Notes, Project Planning, and Authoring|http://orgmode.org|{{AUR|emacs-org-mode}}}}<br />
* [[Task]] - A command-line TODO list manager [http://www.beckingham.net/task.html Home page]<br />
* [[tomboy]] - Desktop note-taking application for Linux and Unix [http://www.gnome.org/projects/tomboy/ Home page]<br />
* [[zim]] - A WYSIWYG text editor that aims at bringing the concept of a wiki to the desktop [http://zim-wiki.org/ Home page]<br />
<br />
==Office suites==<br />
* [[Koffice]]->[[Calligra]] - KOffice is a free, integrated office suite for KDE, the K Desktop Environment. http://www.calligra-suite.org/<br />
* [[LibreOffice]] - A fork of OpenOffice.org, which integrates various patches<br />
* [[OpenOffice.org]] - An office suite http://www.OpenOffice.org/<br />
<br />
==Word processors==<br />
{{Wikipedia|Comparison of word processors}}<br />
*{{App|[[Abiword]]|A full-featured word processor|http://www.abisource.com/|{{Pkg|abiword}}}}<br />
**{{App|Abiword Light|A lighter version of Abiword|http://www.abisource.com/|{{AUR|abiword-light}}}}<br />
*{{App|[[Wikipedia:Markdown|Markdown]]|A text-to-HTML conversion tool that allows you to write using a simple plain text format|http://daringfireball.net/projects/markdown|{{AUR|markdown}}}}<br />
*[[OpenOffice.org Writer]] - A full-featured word processor included in the OpenOffice.org suite<br />
*{{App|pandoc|A swiss-army knife for converting one markup format into another (supports Markdown)|http://johnmacfarlane.net/pandoc|{{AUR|pandoc}}}}<br />
*[http://www.archlinux.org/packages/community/i686/ted/ Ted] - An easy GTK-based rich text processor (with footnote support) http://www.nllgg.nl/Ted/<br />
*{{App|[[Wikipedia:Txt2tags|txt2tags]]|A dead-simple, KISS-compliant lightweight, human-readable markup language to produce rich format content out of plain text files|http://txt2tags.sourceforge.net|{{AUR|txt2tags}}}}<br />
<br />
== Spreadsheets ==<br />
*[[gnumeric]] - A GNOME Spreadsheet Program http://www.gnome.org/projects/gnumeric<br />
*[[LibreOffice|Libreoffice Calc]]<br />
*[[OpenOffice.org|OpenOffice.org Calc]] - A full-featured spreadsheet included in OpenOffice.org suite<br />
<br />
== Security ==<br />
* [[iptables]] - A powerful [[firewall]] built into the linux kernel that is part of the [http://en.wikipedia.org/wiki/Netfilter netfilter] project<br />
* [[arpwatch]] - arpwatch and arpsnmp network monitoring tools ftp://ftp.ee.lbl.gov/<br />
* [[DenyHosts]] - a script to help thwart ssh server attacks http://denyhosts.sourceforge.net/<br />
* [[fail2ban]] - bans IP that makes too many password failures http://www.fail2ban.org/<br />
* [[Sshguard]] - Same as DenyHosts and fail2ban, only lighter, simpler and written in plain C http://www.sshguard.net/<br />
* [[etherape]] - A graphical network monitor for various OSI layers and protocols http://etherape.sourceforge.net/<br />
* [[iptraf]] - An IP network monitor http://iptraf.seul.org/<br />
* [[logwatch]] - Logwatch is a customizable log analysis system http://www.logwatch.org/<br />
* [[nessus]] - Vulnerability scanner http://www.nessus.org<br />
* [[nmap]] - A command line network exploration tool and security/port scanner http://nmap.org<br />
* [[ntop]] - A network traffic probe based on libcap http://ntop.org<br />
* [[portbunny]] - Extremly fast CLI portscanner http://www.recurity-labs.com/portbunny/index.shtml<br />
* [[snort]] - A lightweight network intrusion detection system http://www.snort.org<br />
* [[swatch]] - The active log file monitoring tool http://swatch.sourceforge.net/<br />
* [[tcpdump]] - A tool for network monitoring and data acquisition http://www.tcpdump.org<br />
* [[vnstat]] - console-based network traffic monitor that keeps a log of network traffic http://humdi.net/vnstat/<br />
* [[wireshark]] - A free network protocol analyzer for Unix/Linux and Windows http://www.wireshark.org/<br />
<br />
== Time Management ==<br />
===Console===<br />
* {{App|Calcurse|A text-based curses calendar and scheduling system|http://calcurse.org/|{{Pkg|calcurse}}}}<br />
* {{App|Remind|A highly sophisticated text-based calendaring and notification system|http://www.roaringpenguin.com/products/remind|{{Pkg|remind}}}}<br />
* [[When]] - A simple command line personal calendar program [http://www.lightandmatter.com/when/when.html Home page]<br />
<br />
===Graphical===<br />
* {{App|etm|Event and Task Manager. A "Getting Things Done" approach handling events, tasks, activities, reminders and projects|http://www.duke.edu/~dgraham/ETM/|{{AUR|etm}}}}<br />
* [[Orage]] - A GTK+ calendar and task manager often seen integrated with Xfce [http://www.xfce.org/projects/orage/ Home page]<br />
* [[Osmo]] - A GTK+ personal organizer, which includes calendar, tasks manager and address book modules. [http://clayo.org/osmo/ Home page]<br />
* [http://aur.archlinux.org/packages.php?ID=21675 Rachota] - A portable time tracker for personal projects [http://rachota.sourceforge.net/en/ Home page]<br />
* {{App|Pal|A very lightweight calendar with both interactive and non-interactive interfaces|http://palcal.sourceforge.net/|{{AUR|pal}}}}<br />
* [[Sunbird]] - The standalone Mozilla calendar application [http://www.mozilla.org/projects/calendar/sunbird/ Home page]<br />
* [[taskcoach]] - A simple open source todo manager to manage personal tasks and todo lists [http://taskcoach.sourceforge.net/ Home page] [http://aur.archlinux.org/packages.php?ID=6005 Package]<br />
* {{App|Wyrd|A curses front-end to Remind|http://pessimization.com/software/wyrd/|{{Pkg|wyrd}}}}<br />
* {{App|wxRewind|A Python text and graphical frontend to Remind|http://www.duke.edu/~dgraham/wxRemind/|{{AUR|wxremind}}}}<br />
<br />
==Translation and Localisation==<br />
* [[Lokalize]] - the standard [[KDE]] tool for software translation. Available in Extra. [http://userbase.kde.org/Lokalize Home page]<br />
* [[virtaal]] - an editor for translation of both software and other text, based on Translate Toolkit. [http://aur.archlinux.org/packages.php?ID=21709 Available in AUR]. [http://translate.sourceforge.net/wiki/virtaal/index Home page]<br />
** Supported formats: Gettext (.po and .mo), XLIFF (.xlf), TMX, TBX, WordFast TM (.txt), Qt Linguist (.ts), Qt Phrase Book (.qph), OmegaT glossary (.tab and .utf8), ...<br />
** Shows suggestions from [[Apertium]], Google Translate, Microsoft Translator, [[Moses]], http://open-tran.eu, Translation Memories or TM servers<br />
* [[poedit]] - a simple Gettext/po-file translation tool. Available in Community. [http://www.poedit.net/ Home page]<br />
* [[OmegaT]] - "the translation memory tool", a general translators tool which contains a lot of translation memory features<br />
** Supported formats: html, MS Office 2007 XML, OpenDocument format, XLIFF/Okapi, MediaWiki, plain text, TMX, ...<br />
** Shows suggestions from Google Translate<br />
* [[pology]] - a set of Python tools for dealing with Gettext/po-files. See the [http://techbase.kde.org/Localization/Tools/Pology#About home page] for simple installation instructions.<br />
** May be used to translate po-files with [[Apertium]], see http://wiki.apertium.org/wiki/Translating_gettext for instructions.<br />
* [[Apertium]] - a free and open source rule-based machine translation platform. All released language data is [http://aur.archlinux.org/packages.php?K=apertium available in AUR]. [http://apertium.org/ Home page]<br />
** Supported formats: html, MS Office 2007 XML, OpenDocument format, TMX, some MediaWiki support, ... (use [[Pology]] or [[Virtaal]] for po-files)<br />
** See [http://wiki.apertium.org/wiki/Main_Page the wiki] for supported languages<br />
* [[Moses]] - a statistical machine translation tool (language data not included). [http://www.statmt.org/moses/ Home page]<br />
<br />
== Utilities ==<br />
===Arch Package Management===<br />
<!--shouldn't duplicate info from [[AUR Helpers]]--><br />
* {{App|Aurnotify|A tool set to notify the status of your favorite packages from AUR.|To use the aurnotify desklet visit: http://adesklets.sourceforge.net/desklets.html|{{AUR|aurnotify}}}}<br />
* {{App|pacman-color|Command-line frontend for libalpm aka pacman with color patch.|http://www.archlinux.org/pacman/|{{AUR|pacman-color}}}}<br />
* {{App|Pacman-contrib|Utilities for use with the pacman package manager.|http://www.archlinux.org/pacman/|{{Pkg|pacman-contrib}}}}<br />
* {{App|Pkgtools|A collection of scripts for Arch Linux packages.|Which includes '''pkgfile'''; find what package owns a file. [[http://bbs.archlinux.org/viewtopic.php?pid=384196 Forum topic]]|{{Pkg|pkgtools}}}}<br />
<!--{{Warning|''Powerpill'' development has been officially discontinued: its latest version does not work with ''pacman>&#61;3.5''. See [https://bbs.archlinux.org/viewtopic.php?id&#61;115660].}}<br />
* [[Powerpill]] A wrapper for pacman that speeds up package retrieval by using aria2c for concurrent/segmented downloads. http://xyne.archlinux.ca/old_projects/powerpill--><br />
* {{App|[[TuPac]]|A cached pacman implementation that boosts some pacman operations: faster searches, AND searches, aur support, colored output, system sanity check, frontend friendly and more...|http://sourceforge.net/projects/tupac|{{AUR|tupac}}}}<br />
* {{App|[[Yaourt]]|A Pacman frontend with more features and AUR support.|http://www.archlinux.fr/yaourt-en/|{{AUR|yaourt}}}}<br />
<br />
Also see [[AUR Helpers]].<br />
<br />
=== Disk Usage Display Programs===<br />
* {{App|[[ncdu]]|A simple ncurses disk usage analyzer.|http://dev.yorhel.nl/ncdu|{{Pkg|ncdu}}}}<br />
* {{App|[[gt5]]|A diff-capable 'du-browser'.|http://gt5.sourceforge.net|{{AUR|gt5}}}}<br />
* {{App|[[Baobab]]|Baobab is a C/gtk+ application to analyse disk usage in any Gnome environment.|http://www.marzocca.net/linux/baobab|{{AUR|Baobab}}}}<br />
* {{App|[[Filelight]]|Filelight creates an interactive map of concentric, segmented rings that help visualise disk usage on your computer.|http://www.methylblue.com/filelight|{{Pkg|Filelight}}}}<br />
* {{App|[[gdmap]]|Draw map of rectangles where size of rectangle relate to size of file or dir.|http://gdmap.sourceforge.net/|{{Pkg|gdmap}}}}<br />
<br />
=== CD/DVD Burning Tools===<br />
{{Wikipedia|Comparison of disc authoring software}}<br />
* [[bashburn]] - A lightweight terminal based menu frontend for CD/DVD burning tools.<br />
* [[brasero]] - An application to burn CDs/DVDs for the Gnome Desktop.<br />
* {{App|cdw|Ncurses frontend to cdrecord, mkisofs, growisofs, dvd+rw-mediainfo, dvd+rw-format, xorriso.|http://cdw.sourceforge.net/|{{AUR|cdw}}}}<br />
* [[gnomebaker]] - A GTK based CD/DVD burning application.<br />
* [[graveman]] - A GTK based CD/DVD burning application.<br />
* [[k3b]] - A feature-rich and easy to handle CD burning application for KDE.<br />
* [[nerolinux]] - A commercial CD/DVD burning tool (requires a valid key).<br />
* {{App|recorder|Simple frontend to cdrkit/cdrtools, cdrdao, mkisofs and growisofs with limited options and preferences|http://code.google.com/p/recorder/|{{Pkg|recorder}}}}<br />
* [[xcdroast]] - A lightweight CD/DVD burning tool.<br />
* {{App|Xfburn|Simple frontend to the libburnia libraries with support for CD/DVD(-RW), ISO images and BurnFree|http://www.xfce.org/projects/xfburn/|{{Pkg|xfburn}}}}<br />
<br />
===Clipboard Managers===<br />
* [[Anamnesis]] - stores all clipboard history (!) and offers an interface to do a full-text search. Both command line and GUI modes available [http://anamnesis.sourceforge.net/ Home page] | [http://aur.archlinux.org/packages.php?ID=41542 AUR package]<br />
* [[ClipIt]] - a fork of Parcellite with additional features and bugfixes [http://sourceforge.net/projects/gtkclipit/ Home page]<br />
* [[Glipper]] - clipboardmanager for GNOME with more features and plugin support [http://glipper.sourceforge.net/ Home page]<br />
* [[klipper]] - full featured clipboardmanager for KDE (kdebase-workspace package) [http://userbase.kde.org/Klipper]<br />
* [[Parcellite]] - a lightweight yet feature-rich clipboard manager [http://parcellite.sourceforge.net/ Home page]<br />
<br />
=== Compression Tools ===<br />
{{Wikipedia|Comparison of file archivers}}<br />
====Console====<br />
* {{App|[[atool]]|A script for managing file archives of various types|http://www.nongnu.org/atool/|{{Pkg|atool}}}}<br />
* {{App|[[p7zip]]|A command line port of 7-Zip for POSIX systems, including Linux.|http://p7zip.sourceforge.net/|{{Pkg|p7zip}}}}<br />
<br />
====Graphical====<br />
* {{App|[[Ark]]|Archiving Tool for KDE4.|http://kde.org/applications/utilities/ark/|{{Pkg|kdeutils-ark}}}}<br />
* {{App|[[File Roller]]|The default archive manager for GNOME.|http://fileroller.sourceforge.net/|{{Pkg|file-roller}}}}<br />
* {{App|[[Peazip]]|Open source file and archive manager|http://www.peazip.org/peazip-linux.html|{{AUR|peazip}}}}<br />
* {{App|[[Squeeze]]|A featherweight front-end for command line archiving tools.|http://http://squeeze.xfce.org/|{{AUR|squeeze}}}}<br />
* {{App|[[Xarchive]]|A GTK+ 2 front-end for various command line archiving tools.|http://xarchive.sourceforge.net/|{{AUR|xarchive}}}}<br />
* {{App|[[Xarchiver]]|A lightweight desktop independent archive manager built with GTK+ 2.|http://xarchiver.sourceforge.net/|{{Pkg|xarchiver}}}}<br />
* {{App|[[p7zip]]|A command line port of 7-Zip for POSIX systems, including Linux. Includes 7zFM as GUI. |http://p7zip.sourceforge.net/|{{Pkg|p7zip}}}}<br />
<br />
===eMoney===<br />
* {{App|[[Bitcoin]]|A tool to manage bitcoins, a p2p currency.|Official website : http://bitcoin.org/|{{AUR|bitcoin}}}}<br />
<br />
=== File Managers ===<br />
{{Wikipedia|Comparison of file managers}}<br />
====Console====<br />
*{{App|[[Wikipedia:Midnight commander|Midnight Commander]]|A console-based, dual-paned, file manager|http://www.midnight-commander.org|{{Pkg|mc}}}}<br />
*{{App|[[Ranger]]|A console based file manager with vi bindings, customizability, and lots of features|http://nongnu.org/ranger|{{Pkg|ranger}}}}<br />
<br />
====Graphical====<br />
* {{App|[[Dolphin]]|Default file manager for KDE 4.|http://dolphin.kde.org/|{{Pkg|kdebase-dolphin}}}}<br />
* {{App|[[emelFM2]]|A file manager that implements the popular two-panel design|http://emelfm2.net/|{{Pkg|emelfm2}}}}<br />
* {{App|[[Konqueror]]|File manager for KDE.|http://www.konqueror.org/|{{Pkg|kdebase-konqueror}}}}<br />
* {{App|[[Krusader]]|Advanced twin panel (commander style) file manager for KDE|http://www.krusader.org/|{{Pkg|krusader}}}}<br />
* {{App|[[Nautilus]]|Extensible, heavyweight file manager used by default in GNOME with support for custom scripts|http://projects.gnome.org/nautilus/|{{Pkg|nautilus}}}}<br />
* {{App|[[PCManFM]]|A lightweight file manager which features tabbed browsing and can optionally manage the desktop background|http://pcmanfm.sourceforge.net/|{{AUR|pcmanfm}}}}<br />
* {{App|[[qtfm]]|A small, lightweight filemanager for Linux desktops based on pure Qt.|http://www.qtfm.org/|{{Pkg|qtfm}}}}<br />
* {{App|[[ROX-Filer]]|A small and fast file manager which can optionally manage the desktop background and panels|http://rox.sourceforge.net|{{Pkg|rox}}}}<br />
* {{App|[[Sunflower]]|Small and highly customizable twin-panel file manager for Linux with support for plugins.|http://code.google.com/p/sunflower-fm/|{{AUR|sunflower}}}}<br />
* {{App|[[Thunar]]|Can be run as a daemon with excellent start up and directory load times. Features support for customizable actions|http://thunar.xfce.org/index.html|{{Pkg|thunar}}}}<br />
* {{App|[[tuxcmd]]|Windowed file manager with 2 panels side by side similar to popular Total Commander or Midnight Commander file managers|http://tuxcmd.sourceforge.net/description.php|{{Pkg|tuxcmd}}}}<br />
* {{App|[[Vifm]]|A ncurses based two-pane file manager with vi like keybindings|http://vifm.sourceforge.net/|{{Pkg|vifm}}}}<br />
* {{App|[[Xfe]]|A MS-Explorer or Commander like file manager for X|http://roland65.free.fr/xfe/index.php/|{{Pkg|xfe}}}}<br />
<br />
=== Merge tools ===<br />
* [[diffuse]]: http://diffuse.sourceforge.net/<br />
* ediff: part of [[Emacs|emacs]]<br />
* [[kdiff]]: http://kdiff3.sourceforge.net/<br />
* [[kompare]]: http://kde.org/applications/development/kompare<br />
* [[meld]]: http://meld.sourceforge.net<br />
* [[Vim#Merging_Files_.28Vimdiff.29|vimdiff]]<br />
<br />
=== Taskbars ===<br />
* {{App|[[Avant Window Navigator]]|A lightweight dock which sits at the bottom of the screen.|http://wiki.awn-project.org/|{{Pkg|avant-window-navigator}}}}<br />
* {{App|[[Bmpanel]]|A lightweight, NETWM compliant panel for the X11 system|http://nsf.110mb.com/bmpanel/|{{Pkg|bmpanel}}}}<br />
* {{App|[[Cairo-Dock]]|A highly customizable dock/laucher.|http://www.glx-dock.org/|{{AUR|cairo-dock}}}}<br />
* {{App|[[Docker]]|A docking application which acts as a system tray.|http://icculus.org/openbox/2/docker/|{{Pkg|docker}}}}<br />
* {{App|[[fbpanel]]|Lightweight, NETWM compliant desktop panel.|http://fbpanel.sourceforge.net/|{{AUR|fbpanel}}}}<br />
* {{App|[[LXPanel]]|Lightweight X11 desktop panel and part of the LXDE DE.|http://lxde.org/|{{AUR|lxpanel}}}}<br />
* {{App|pancake|A highly configurable, modular panel for X|http://www.failedprojects.de/pancake/|{{AUR|pancake}}}}<br />
* {{App|[[PyPanel]]|Lightweight panel/taskbar written in Python and C.|http://pypanel.sourceforge.net/|{{AUR|pypanel}}}}<br />
* {{App|qtpanel|A project to create useful and beautiful panel in Qt|https://bbs.archlinux.org/viewtopic.php?id&#61;117528|{{AUR|qtpanel-git}}}}<br />
* {{App|[[Stalonetray]]|A stand-alone system tray.|http://stalonetray.sourceforge.net/|{{Pkg|stalonetray}}}}<br />
* {{App|[[Tint2]]|Simple panel/taskbar developed specifically for Openbox.|http://code.google.com/p/tint2/|{{Pkg|tint2}}}}<br />
* {{App|[[Trayer]]|Swallows GTK 1.2/2.x application docklets, and KDE docklets.|https://gna.org/projects/fvwm-crystal/|{{Pkg|trayer}}}}<br />
* {{App|[[Xfce4panel]]|Default [[Xfce]] panel|http://www.xfce.org/projects/xfce4-panel/|{{Pkg|xfce4-panel}}}}<br />
<br />
==Window managers and desktop environments==<br />
*[[Desktop Environment#List of desktop environments|List of desktop environments]]<br />
*[[Window Manager#List of window managers|List of window managers]]<br />
<br />
===Login managers===<br />
<!--Use the App template.--><br />
*{{App|[[CDM]]|An ultra-minimalistic, yet full-featured login manager written in bash|http://cdm.ghost1227.com/|{{AUR|cdm}}}}<br />
*{{App|[[SLiM]]|A lightweight and elegant graphical login solution|http://slim.berlios.de/|{{Pkg|slim}}}}<br />
*{{App|[[Qingy]]|An ultralight and very configurable graphical login independent on X Windows|http://qingy.sourceforge.net/|{{Pkg|qingy}}}}<br />
<br />
== System Monitoring ==<br />
*[[adesklet-systemmonitor]] - Modular stackable system monitors for adesklets http://adesklets.sourceforge.net/desklets.html<br />
*{{App|[[Conky]]|A lightweight, scriptable system monitor|http://conky.sourceforge.net/|{{Pkg|conky}}}}<br />
*[[gkrellm]] - Simple, flexible system monitor package for GTK2; many plug-ins are available on AUR. http://members.dslextreme.com/users/billw/gkrellm/gkrellm.html<br />
*{{App|[[Wikipedia:Htop|Htop]]|A simple, ncurses interactive process viewer|http://htop.sourceforge.net/|{{Pkg|htop}}}}<br />
*{{App|LXTask|A lightweight task manager for [[LXDE]]|http://wiki.lxde.org/en/LXTask|{{Pkg|lxtask}}}}<br />
<br />
== Terminal emulators ==<br />
{{Wikipedia|List of terminal emulators}}<br />
* [[Wikipedia:aterm|aterm]] - An xterm replacement with transparency support http://aterm.sourceforge.net/<br />
* Eterm ([[Enlightenment]], derived from rxvt)<br />
*[http://www.calno.com/evilvte/ evilvte] (The name apparently is a reference to [[Evilwm|evilwm]], although the two projects do not appear to be related.) (VTE)<br />
* [[gnome-terminal]] - [[GNOME]] default (standalone) terminal with support for Unicode and pseudo-transparency (VTE)<br />
* [[guake]] - A a drop-down terminal for Gnome Desktop Environment. https://aur.archlinux.org/packages.php?ID=15547<br />
* [[Wikipedia:Konsole|konsole]] - [[KDE]]'s default terminal<br />
* [[lxterminal]] - VTE-based terminal emulator and c part of the LXDE DE. http://lxde.org/<br />
* {{App|[[LilyTerm]]|A light and easy to use libvte based X Terminal Emulator|http://lilyterm.luna.com.tw/|{{Pkg|lilyterm}}}}<br />
* [[mrxvt]] - Tabbed X terminal emulator based on rxvt code http://materm.sourceforge.net/index.html<br />
*[http://aur.archlinux.org/packages.php?ID=36730 mt] written as nice light-er-weight replacement for sakura (the binary is one third the size), keeping most of the functionality, except settings are defined during compilation, and removes some stupid features. (VTE)<br />
* {{App|ROXTerm|A tabbed, VTE-based terminal emulator with a small footprint|http://rox.sourceforge.net|{{Pkg|roxterm}}}}<br />
* [[Wikipedia:Rxvt|rxvt]] {{AUR|rxvt}}<br />
*{{App|[[urxvt]]|A highly extendable unicode enabled rxvt-clone terminal emulator featuring tabbing, url launching, quake-style dropdown, pseudo-transparency, and is extensible with perl|http://software.schmorp.de/pkg/rxvt-unicode|{{Pkg|rxvt-unicode}}}}<br />
*{{App|Sakura|A terminal emulator based on GTK+ and VTE|http://www.pleyades.net/david/sakura.php|{{Pkg|sakura}}}}<br />
*{{App|[[Stjerm]]|is a GTK+-based drop-down terminal emulator. Stjerm sets itself apart from similar programs by providing a minimalistic interface combined with a small file size, lightweight memory usage and easy integration with composite window managers such as Compiz. |http://code.google.com/p/stjerm-terminal-emulator/downloads/list|}}<br />
* [[terminal]] - Xfce default terminal with support for a colorized prompt and a tabbed interface http://www.xfce.org/projects/terminal/ (VTE)<br />
* [[terminator]] - A terminal emulator supporting multiple resizable terminal panes<br />
* [[Termit]] http://wiki.github.com/nonstop/termit/<br />
*{{App|[[Wikipedia:Tilda (software)|Tilda]]|A Linux terminal taking after the likeness of many classic terminals from first person shooter games, Quake, Doom and Half-Life (to name a few), where the terminal has no border and is hidden from the desktop until a key is pressed|http://sourceforge.net/projects/tilda/files/|{{Pkg|tilda}}}}<br />
*{{App|[[Xterm]]|A terminal emulator for the X Window System|http://invisible-island.net/xterm/|{{Pkg|xterm}}}}<br />
* [[yakuake]] - A drop-down terminal emulator based on KDE Konsole technology http://extragear.kde.org/apps/yakuake/<br />
<br />
==Text editors==<br />
<!--Keep in sync with [[Lightweight Applications]] and use the App template.--><br />
{{Wikipedia|Comparison of text editors}}<br />
===Console===<br />
*{{App|[[Emacs|GNU Emacs]]|The somewhat intimidating but famously extensible text editor with hundreds of tricks and add-ons|http://www.gnu.org/software/emacs/|{{Pkg|emacs}}}}<br />
<!-- joe --><br />
*{{App|[[nano]]|A console text editor based on pico with on-screen key binding help|http://www.nano-editor.org/|{{Pkg|nano}}}}<br />
*{{App|[[Vim]]|Vi IMproved|http://www.vim.org/|{{Pkg|vim}}}}<br />
<br />
===Graphical===<br />
*{{App|[[Wikipedia:Acme (text editor)|Acme]]|A minimalist and flexible programming environment by Rob Pike|http://acme.cat-v.org|{{Pkg|plan9port}}}}<br />
*{{App|[[Beaver]]|An Early AdVanced EditoR|http://www.nongnu.org/beaver/|{{Pkg|beaver}}}}<br />
*{{App|[[Wikipedia:Bluefish (text editor)|Bluefish]]|GTK editor/IDE with an MDI interface, syntax highlighting and support for Python plugins|http://bluefish.openoffice.nl/|{{Pkg|bluefish}}}}<br />
*{{App|Cssed|GTK2 based Cascading Style Sheets (CSS) editor|http://cssed.sourceforge.net/|[[package]]}}<br />
*{{App|Edile|A PyGTK code/scripting editor implemented in one file|http://edile.googlecode.com|{{AUR|edile}}}}<br />
*{{App|[[Wikipedia:Geany|Geany]]|A text editor using the GTK+ 2 toolkit with basic features of an integrated development environment|http://www.geany.org|{{Pkg|geany}}}}<br />
*{{App|[[Wikipedia:Gedit|Gedit]]|Part of the GNOME desktop, but has minimal dependencies: a GTK2 editor with syntax highlighting, automatic indentation, matching brackets, etc., and a number of add-ons to increase functionality|http://projects.gnome.org/gedit/|{{Pkg|gedit}}}}<br />
*{{App|[[gVim]]|Vi IMproved|http://www.vim.org/|{{Pkg|gvim}}}}<br />
*{{App|[[Kate]]|The KDE Advanced Text Editor. A full-featured programmer's editor, with MDI and a filesystem browser|[[project]]|[[package]]}}<br />
*{{App|[[KWrite]]|(part of the KDE desktop) A lightweight text editor with syntax highlighting.|[[project]]|{{Pkg|kwrite}}}}<br />
*{{App|[[Leafpad]]|A notepad clone for GTK+ 2.x that emphasizes simplicity|http://tarot.freeshell.org/leafpad/|{{Pkg|leafpad}}}}<br />
*{{App|medit|medit is a programming and around-programming text editor|http://mooedit.sourceforge.net/|{{Pkg|medit}}}}<br />
*{{App|[[Wikipedia:PyRoom|PyRoom]]|A great distractionless PyGTK text editor, a clone of the infamous WriteRoom|http://pyroom.org/|{{AUR|pyroom}}}}<br />
*{{App|[[Wikipedia:Sam (text editor)|Sam]]|A graphical text editor by Rob Pike (still used by Ken Thompson and others)|http://sam.cat-v.org|{{Pkg|plan9port}} or {{Pkg|9base}}}}<br />
*{{App|[[Scite]]|A generally useful editor with facilities for building and running programs|http://www.scintilla.org/SciTE.html|{{Pkg|scite}}}}<br />
*{{App|[[Tea]]|a QT based feature rich text editor|[[project]]|{{Pkg|tea}}}}<br />
<br />
== OCR tools ==<br />
There are several steps to the whole OCR process, the actual OCR engine is only part of this:<br />
# scanning<br />
# document layout analysis<br />
# optical character recognition<br />
# post-processing (formatting, PDF creation)<br />
<br />
=== OCR Engines ===<br />
* [[CuneiForm]] is a command line OCR system originally developed and open sourced by Cognitive technologies. Supported languages: eng, ger, fra, rus, swe, spa, ita, ruseng, ukr, srp, hrv, pol, dan, por, dut, cze, rum, hun, bul, slo, lav, lit, est, tur. Available from [[pacman]]/community. https://launchpad.net/cuneiform-linux<br />
* [[GOCR]]/JOCR (http://jocr.sourceforge.net/) is an OCR engine which also supports barcode recognition. Available from [[pacman]]/extra as "gocr". http://www.gnu.org/software/ocrad/<br />
* [[Ocrad]] is an OCR (Optical Character Recognition) program based on a feature extraction method. Available from [[pacman]]/extra. http://www.gnu.org/software/ocrad/<br />
* [[Tesseract]] is "probably one of the most accurate open source OCR engines available". Available from [[pacman]]/community. http://code.google.com/p/tesseract-ocr/<br />
<br />
=== Layout analysers and user interfaces ===<br />
* [[gscan2pdf]] scans, runs Tesseract and creates a PDF all in one go<br />
* [[Kooka]] is a scanner GUI for KDE which supports the OCR engines [[GOCR]], [[Ocrad]] or [[KADMOS]]. Used to be part of kdegraphics4, but dropped out due to lack of development. http://kooka.kde.org/{{Linkrot|2011|09|03}}<br />
* [[OCRFeeder]] is a Python GUI for Gnome which performs document analysis and rendition, and can use either [[CuneiForm]], [[GOCR]], [[Ocrad]] or [[Tesseract]] as OCR engines. It can import from PDF or image files, and export to HTML or OpenDocument. Available from [[AUR]]. http://live.gnome.org/OCRFeeder<br />
* [[OCRopus]] is an OCR ''platform'', modules exist for document layout analysis, OCR engines (it can use Tesseract or its own engine), natural language modelling, etc. Available from [[AUR]]. http://code.google.com/p/ocropus/<br />
* [[YAGF]] is a graphical interface for the [[CuneiForm]] text recognition program on the Linux platform. Available from community repository. http://symmetrica.net/cuneiform-linux/yagf-en.html<br />
<br />
==Application Launchers==<br />
<!--Use the App template.--><br />
*{{App|Fehlstart|A small application launcher written in c99|https://bbs.archlinux.org/viewtopic.php?id=122009/|{{AUR|fehlstart-git}}}}<br />
*{{App|Adeskbar|An easy, simple, unobtrusive application launcher for Openbox|https://launchpad.net/adeskbar|{{AUR|adeskbar}}}}<br />
<br />
==Games==<br />
*[[Games]]<br />
*[[Netbook Games]]<br />
<br />
==See also==<br />
*[[Scientific Applications]]<br />
*[https://bbs.archlinux.org/viewtopic.php?id=88515 Arch Linux Forums / LnF Awards 2010] - The best Light & Fast apps of 2010.<br />
*[https://bbs.archlinux.org/viewtopic.php?id=111878 Arch Linux Forums / LnF Awards 2011] - The best Light & Fast apps of 2011.<br />
*http://linuxappfinder.com/<br />
*http://www.linuxlinks.com/<br />
*http://en.wikipedia.org/wiki/List_of_open_source_software_packages<br />
*http://linuxappfinder.com/alternatives - Windows and OS X Software Alternatives<br />
*http://alternativeto.net/ - find alternatives to popular programs<br />
*http://www.linuxalt.com/ - Linux equivalents of Windows software<br />
*http://lin-app.com/ - on-line information service of various commercial applications and games for Linux</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=164561Professional audio2011-10-08T01:58:30Z<p>Smoge: /* ArchStudio Repository */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he or she installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*<br />
<br />
-OR-<br />
<br />
$ fuser -fv /dev/snd/pcm* /dev/dsp* <br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install {{Package AUR|libflashsupport-jack}} from the [[AUR]].<br />
<br />
You can also use more flexible method to allow Alsa programs (including Flash) play sound while jack is running:<br />
<br />
First you must install the jack plugin for Alsa:<br />
# pacman -S alsa-plugins<br />
<br />
And enable it by editing (or creating) /etc/asound.conf (system wide settings) to have these lines:<br />
<pre><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 />
}</pre><br />
<br />
You do not need to restart your computer or anything. Just edit the alsa config files, start up jack.<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''linux'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* {{Package AUR|linux-rt}}<br />
* {{Package AUR|linux-rt-ice}}<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tips and Tricks ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
* You may like to read more on ALSA: http://www.volkerschatz.com/noise/alsa.html<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== ArchAudio: Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
=== Packages ===<br />
====Repositories====<br />
<br />
We have “restructured” our repositories and have new names and serve new purposes. Where previously there were:<br />
<br />
* '''stable''' - tested builds (close to empty)<br />
* '''testing''' - untested builds<br />
* '''experimental''' - devel builds (almost always empty)<br />
<br />
We now have:<br />
<br />
* '''production''' - verified PKGBUILDs AND tested packages (hope to fill this up)<br />
* '''preview''' - unverified PKGBUILDs AND/OR untested packages<br />
* '''nightly''' - verified devel PKGBUILDs (automated nightly/daily builds soon)<br />
* '''experimental''' - unverified devel PKGBUILDs (automated nightly/daily builds soon)<br />
<br />
Please check out the ‘packages’ page, http://archaudio.org/packages/ , for further details and '''update your <code>/etc/pacman.conf</code>''':<br />
<br />
<pre><br />
# verified PKGBUILDs AND tested packages<br />
[archaudio-production]<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
<br />
# unverified PKGBUILDs AND/OR untested packages<br />
[archaudio-preview]<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
<br />
# verified devel PKGBUILDs<br />
[archaudio-nightly]<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
<br />
# unverified devel PKGBUILDs<br />
[archaudio-experimental]<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
</pre><br />
<br />
=====SynthBox LiveCD=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio Repository=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository populated with ArchAudio optimized binaries, including the linux-rt package:<br />
<pre><br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://www.bbarros.com/archstudio<br />
Server = http://www.bbarros.com/x86_64<br />
</pre><br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.</div>Smogehttps://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=135715Unofficial user repositories2011-04-03T01:04:44Z<p>Smoge: /* x86_64 only */</p>
<hr />
<div>[[Category: Package management (English)]]<br />
==Why unofficial user repositories==<br />
Since the AUR only allows users to upload PKGBUILD and other package build related files, but does not provide a means for distributing a binary package, a user may want to create a binary repository of their packages elsewhere.<br />
<br />
==The future of Unofficial repos==<br />
I'd like to see more work of this type. Sometimes there are certain projects that don't mesh well with other things, such as the community repo. The 'kdemod' project is a good example. If you want to contribute with your own builds, you can check page [[Custom local repository]].<br />
<br />
In the future, well-thought-out user repositories may be ideal for lots of supplementary things. Forming a "web of trust" is important in cases like this, so we may begin keeping a list of "recommended" repositories somewhere, in order to make it seem more official and trustworthy.<br />
<br />
[[User:Phrakture|Phrakture]] 12:50, 18 May 2007 (EDT)<br />
<br />
== The community repository, maintained by the TUs==<br />
The community repository is included in pacman's default configuration.<br />
<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
==List of PUR (unofficial user repositories)==<br />
===Any===<br />
"Any" repos are architecture-independent, i.e. they can be used on both i686 and x86_64 systems.<br />
<pre><br />
[herecura-stable-any]<br />
# Just some stuff; a few java apps, wallpapers, small scripts, xbmc-skin<br />
Server = http://herecura.be/repo/herecura-stable/any<br />
<br />
[herecura-testing-any]<br />
# Some any testing stuff, xbmc-svn skin<br />
Server = http://herecura.be/repo/herecura-testing/any<br />
<br />
[xyne-any]<br />
# The home of Xyne's contributions.<br />
# More info including a package list can be found at http://xyne.archlinux.ca/repos<br />
Server = http://xyne.archlinux.ca/repos/xyne-any/<br />
<br />
</pre><br />
<br />
===Both i686 and x86_64===<br />
<!--Not exactly same as 'any' repositories, this section should probably be separate.--><br />
Repositories with both i686 and x86_64 versions. The $arch variable will be set automatically by pacman.<br />
<pre><br />
[archlinuxfr]<br />
# The french Arch Linux communities packages.<br />
Server = http://repo.archlinux.fr/$arch<br />
<br />
[archaudio-stable]<br />
# and/or *-testing, *-experimental<br />
# Pro-audio repo:<br />
# - http://archaudio.org<br />
# Replace "stable" with repo type (testing/experimental).<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
[archstuff]<br />
# AUR's most voted and many bin32-* and lib32-* packages.<br />
Server = http://archstuff.vs169092.vserver.de/$arch<br />
<br />
[arch-games]<br />
# The Arch Linux Gaming repository project.<br />
# Active mirrors listed in https://github.com/Arch-Games/arch-games/wiki/Mirrors<br />
Server = http://repo.exigen.org/arch/games/$arch<br />
Server = ftp://mirror.selfnet.de/arch-games/$arch<br />
# Currently inactive mirrors<br />
#Server = http://arch.twilightlair.net/games/$arch<br />
#Server = http://pseudoform.org/arch-games/games/$arch<br />
<br />
[burg]<br />
# Burg bootloader repo<br />
# More info : http://archydeb.wordpress.com/<br />
Server = http://dl.dropbox.com/u/11529444/$arch<br />
<br />
[cake]<br />
# Crapkit, dbus, hal, etc. stripped packages compatible with Arch Linux (from http://hereticlinux.org/).<br />
Server = http://hereticlinux.org/repo/cake/$arch<br />
<br />
[catalyst]<br />
# ATI Catalyst proprietary drivers.<br />
Server = http://catalyst.apocalypsus.net/repo/catalyst/$arch<br />
<br />
[kernel26-ck]<br />
# ARCH kernel with Brain Fuck Scheduler and all the goodies in the ck1 patch set<br />
Server = http://home.comcast.net/~repo-ck/$arch<br />
<br />
[pfkernel]<br />
# Kernel packages: generic i686 and x86_64, optimized P3, P4, K7, Atom, Pentium-M, K8, Core2<br />
# nvidia-pf, squid3, arora-git, nvidia-utils-beta<br />
Server = http://dl.dropbox.com/u/11734958/$arch<br />
<br />
[radeon]<br />
# ATI Radeon X.Org drivers, bleeding edge 'git' builds.<br />
Server = http://spiralinear.org/perry3d/$arch<br />
<br />
[sergej-repo]<br />
# ion3 and some other stuff.<br />
# http://code.google.com/p/archlinux-stuff/source/browse/trunk<br />
Server = http://repo.p5n.pp.ru/sergej-repo/$arch/<br />
<br />
[suckless]<br />
# suckless.org packages<br />
Server = http://dl.suckless.org/arch/$arch<br />
<br />
[tomoyo]<br />
# TOMOYO Linux kernels, modules and userspace tools<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
<br />
[unarch]<br />
# Offers support mainly against devel packages.<br />
# Contains stable packages that aren't in official repo.<br />
Server = http://us4all.info/unarch/arch/$arch<br />
<br />
[kittyserve]<br />
# Contains kittykatt's packages and packages from friends of kittykatt, as well as most mint-related packages<br />
Server = http://repo.kattz.tk/$arch<br />
</pre><br />
<br />
===i686 only===<br />
<pre><br />
[adslgr32]<br />
# The Hellenic (Greek) Arch Linux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/i686/<br />
<br />
[kde4-eyecandy-32]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/i686/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.org/doku.php/blog/linux/repository<br />
Server = http://repo.andrwe.org/i686<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/i686<br />
<br />
[arch-graphics]<br />
# Repository aimed to provide applications mainly for 3D graphics.<br />
# For more info, look at http://arch-graphics.kx.cz/<br />
Server = http://arch-graphics.kx.cz/repo/i686<br />
<br />
[cgr-i686]<br />
# Packages for some ChicoGeek's PKGBUILDs.<br />
Server = http://cgr.i686.googlepages.com/<br />
<br />
[chaox-stable]<br />
# Pentesting packages and custom kernel patched for WIFI injection.<br />
Server = http://repo.chaox.net/stable<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
# Updated to June 2008.<br />
Server = http://compiz.dreamz-box.de/i686<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/i686<br />
<br />
[dragonlord]<br />
# Mixed packages, I don't want to move into [community],<br />
# but are worth having them or the build time is long.<br />
Server = http://repo.dragonlord.cz/arch/i686<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/i686<br />
<br />
[esclinux]<br />
# Mostly games, interactive fiction and abc notation stuffs already on AUR.<br />
Server = http://download.tuxfamily.org/esclinuxcd/ressources/repo/i686/<br />
<br />
[fukawi]<br />
# Some Nagios Stuff; molly-guard; celtx and various networking tools.<br />
Server = http://repo.fukawi2.nl/i686/<br />
Server = ftp://repo.fukawi2.nl/i686/<br />
<br />
[jose1711repo]<br />
# Most of the packages I maintain in AUR (games, tools)<br />
Server = http://arch.l33t.in/i686/<br />
<br />
[kpiche]<br />
# Stable OpenSync packages.<br />
Server = http://kpiche.archlinux.ca/repo<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/).<br />
Server = http://pst.brankovukelic.com/i686<br />
<br />
[rfad]<br />
# Repository made by haxit | Contact at: requiem [at] archlinux.us for package suggestions!<br />
Server = http://web.ncf.ca/ey723/archlinux/repo/<br />
<br />
[xdemon-repo]<br />
# madwimax, kismet-svn and aircrack-svn, etc...<br />
Server=http://repo.x-demon.org/archlinux/os/i686<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://nightly.uhuc.de/i686<br />
<br />
[pozitpoh]<br />
# Fresh psi-plus, kvirc4, urtconnector, xneur, etc.<br />
Server = http://pozitpoh.is-a-geek.org/repo/i686<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/i686<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/i686<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/i686<br />
<br />
[mingw32]<br />
# Libs & tools for crosscompiling for Win32, mainly taken from AUR.<br />
# Contact: Alexander 'hatred' Drozdov <adrozdoff [at] gmail (dot) com> (Russian-speaked guys can write on Russian :-)<br />
Server = http://hatred.homelinux.net/archlinux/mingw32/os/i686<br />
<br />
[jrepo]<br />
# Random pkgs for my friends low-end and old laptop.<br />
# These pkgs are optimzed for pentium-m (i686 + sse2).<br />
# All pks that support pulseaudio have been natively complied to include it.<br />
# http://dl.dropbox.com/u/3422289/README list of pkgs and info<br />
Server = http://dl.dropbox.com/u/3422289<br />
<br />
[kernel-panic]<br />
# A various set of useful packages, including (but not limited to) opera, falconpl and kpackagekit<br />
Server = http://kernel-panic.dnsdojo.net/arch/i686<br />
<br />
[ayatana]<br />
# Packages from Ubuntu (humanity-icon-theme, ttf-ubuntu, ubuntu-light-themes, ubuntuone-client, indicator-applet, notify-osd…),<br />
# packages from elementary project (dexter, elementary-icon-theme, gloobus-preview, gnome-theme-elementary, postler…),<br />
# packages from Linux Mint (gnome-theme-mint, mintbackup, mintdesktop, mint-icon-theme, mintmenu…) and<br />
# apps with ayatana support (audio-recorder, banshee-community-extensions, cloudsn, gwibber, pino, sbackup, smuxi…),<br />
# extra GNOME apps (conduit, eog-plugins, glabels, gnome-color-manager, gnome-globalmenu, gnome-subtitles, ontv, pdfmod, rygel, postr, tasque…),<br />
# mapping apps (bt747, emerillon, foxtrotgps, gpx-viewer, merkaartor, navit, prune…),<br />
# some other apps (backintime, connman, faenza-icon-theme, gdesklets, keepnote, kompozer, nautilus-terminal, openbve, pinta, textflow, uget…).<br />
# More info: http://arch.ballogyorgy.com/<br />
Server = http://repo.ayatana.info/<br />
</pre><br />
<br />
===x86_64 only===<br />
<pre><br />
[kde4-eyecandy-64]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/x86_64/<br />
<br />
[adslgr64]<br />
# The Hellenic (Greek) archlinux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/x86_64/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.dyndns.org/doku.php/blog/repository<br />
Server = http://repo.andrwe.org/x86_64<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/x86_64<br />
<br />
[archlinuxve]<br />
# Home of the splashy packages.<br />
Server = http://repo.archlinux.com.ve/x86_64<br />
<br />
[archstudio]<br />
# ArchAudio Packages <br />
# Optimized for Intel Core {i3,i5,i7} CPU <br />
# Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
Server = http://compiz.dreamz-box.de/x86_64<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/x86_64<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/x86_64<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/)<br />
Server = http://pst.brankovukelic.com/x86_64<br />
<br />
[dstr-repo]<br />
# qutim, psi, kdevelop with plugins dev builds and other stuff.<br />
Server = http://dimon.homeftp.org/repo/x86_64<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://files.shadowice.org/nightly/x86_64<br />
<br />
[zen]<br />
# Various and zengeist' AUR packages.<br />
Server = http://zloduch.cz/archlinux/x86_64<br />
<br />
[digitalpioneer]<br />
# Recent GIT/SVN/whatever builds of selected AUR packages.<br />
# List of packages is at http://dl.getdropbox.com/u/453116/repo/pkglist and is subject to change.<br />
# x86_64 only.<br />
Server = http://dl.getdropbox.com/u/453116/repo<br />
<br />
[seiichiro]<br />
# VDR and some plugins, mms, foo2zjs-drivers<br />
Server = http://repo.seiichiro0185.org/x86_64<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/x86_64<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/x86_64<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/x86_64<br />
<br />
[pyropeter]<br />
# My AUR packages: http://aur.archlinux.org/packages.php?SeB=m&K=pyropeter<br />
Server = http://keks.selfip.org/arch/pyropeter<br />
</pre><br />
<br />
==Add your own repository to this list==<br />
If you have your own repository, please add this to this list, so that all other users knows where to find your packages.</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135488Professional audio2011-03-31T23:24:36Z<p>Smoge: /* ArchStudio Repository */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== ArchAudio: Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to <code>/etc/pacman.conf</code>:<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/$arch<br />
<br />
=====SynthBox LiveCD=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio Repository=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository at http://dl.dropbox.com/u/5977716/archstudio.html, populated with ArchAudio optimized binaries, it also includes VCS packages from [experimental]:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135487Professional audio2011-03-31T23:23:22Z<p>Smoge: /* Arch Linux Pro Audio Project */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== ArchAudio: Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to <code>/etc/pacman.conf</code>:<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/$arch<br />
<br />
=====SynthBox LiveCD=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio Repository=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository[http://dl.dropbox.com/u/5977716/archstudio.html] populated with ArchAudio optimized binaries, it also includes VCS packages from [experimental]:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135384Professional audio2011-03-30T16:06:47Z<p>Smoge: /* ArchStudio Repository */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to <code>/etc/pacman.conf</code>:<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/$arch<br />
<br />
=====SynthBox LiveCD=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio Repository=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository[http://dl.dropbox.com/u/5977716/archstudio.html] populated with ArchAudio optimized binaries, it also includes VCS packages from [experimental]:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135358Professional audio2011-03-30T13:40:59Z<p>Smoge: /* PKGBUILDs */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to <code>/etc/pacman.conf</code>:<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/$arch<br />
<br />
=====SynthBox LiveCD=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio Repository=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository[http://dl.dropbox.com/u/5977716/archstudio.html] populated with ArchAudio optimized binaries but also including VCS packages:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135357Professional audio2011-03-30T13:40:18Z<p>Smoge: /* ArchStudio Repository */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to <code>/etc/pacman.conf</code>:<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/$arch<br />
<br />
=====SynthBox LiveCD=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio Repository=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository[http://dl.dropbox.com/u/5977716/archstudio.html] populated with ArchAudio optimized binaries but also including VCS packages:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
<code><br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
</code><br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
<code><br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources<br />
</code></div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135356Professional audio2011-03-30T13:39:50Z<p>Smoge: /* ArchStudio Repository */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to <code>/etc/pacman.conf</code>:<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/$arch<br />
<br />
=====SynthBox LiveCD=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio Repository=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository[http://dl.dropbox.com/u/5977716/archstudio.html] populated with ArchAudio optimized binaries. It is mostly based on ArchAudio sources, also including VCS packages:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
<code><br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
</code><br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
<code><br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources<br />
</code></div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135355Professional audio2011-03-30T13:36:10Z<p>Smoge: /* ArchStudio */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to <code>/etc/pacman.conf</code>:<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/$arch<br />
<br />
=====SynthBox LiveCD=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio Repository=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository[http://dl.dropbox.com/u/5977716/archstudio.html] populated with ArchAudio optimized binaries:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
<code><br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
</code><br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
<code><br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources<br />
</code></div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135354Professional audio2011-03-30T13:35:42Z<p>Smoge: /* SynthBox */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to <code>/etc/pacman.conf</code>:<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/$arch<br />
<br />
=====SynthBox LiveCD=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository[http://dl.dropbox.com/u/5977716/archstudio.html] populated with ArchAudio optimized binaries:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
<code><br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
</code><br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
<code><br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources<br />
</code></div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135353Professional audio2011-03-30T13:35:08Z<p>Smoge: /* Repositories */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to <code>/etc/pacman.conf</code>:<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/$arch<br />
<br />
=====SynthBox=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository[http://dl.dropbox.com/u/5977716/archstudio.html] populated with ArchAudio optimized binaries:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
<code><br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
</code><br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
<code><br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources<br />
</code></div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135352Professional audio2011-03-30T13:34:07Z<p>Smoge: /* SynhBox */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to /etc/pacman.conf (replace i686 with x86_64 for 64-bit):<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/i686<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/i686<br />
<br />
=====SynthBox=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository[http://dl.dropbox.com/u/5977716/archstudio.html] populated with ArchAudio optimized binaries:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
<code><br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
</code><br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
<code><br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources<br />
</code></div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135351Professional audio2011-03-30T13:33:55Z<p>Smoge: /* Repositories */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to /etc/pacman.conf (replace i686 with x86_64 for 64-bit):<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/i686<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/i686<br />
<br />
=====SynhBox=====<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
=====ArchStudio=====<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository[http://dl.dropbox.com/u/5977716/archstudio.html] populated with ArchAudio optimized binaries:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
<code><br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
</code><br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
<code><br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources<br />
</code></div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135306Professional audio2011-03-30T01:54:41Z<p>Smoge: /* Arch Linux Pro Audio Project */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
* Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
* ''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
=== Packages ===<br />
<br />
<br />
====Repositories====<br />
<br />
We have a total of two binary “repos” on our server. For now only our testing repository is somewhat active, but we recommend adding both of them to /etc/pacman.conf (replace i686 with x86_64 for 64-bit):<br />
<br />
# tried and tested packages<br />
[archaudio-stable]<br />
Server = http://repos.archaudio.org/stable/i686<br />
<br />
# these are..for testing?<br />
[archaudio-testing]<br />
Server = http://repos.archaudio.org/testing/i686<br />
<br />
There is also an unrelated Arch Linux pro-audio LiveCD (work-in-progress) project by Sean ‘seanbutnotheard’ Corbett which you can check out at http://obsoleteaudio.org/software/synthbox.<br />
<br />
If by chance you are a user of a ArchLinux 64bit system with a Intel Core i3/i5/i7 processor, you can take advantage of this repository[http://dl.dropbox.com/u/5977716/archstudio.html] populated with ArchAudio optimized binaries:<br />
<br />
[archstudio]<br />
#ArchAudio Packages <br />
#Optimized for Intel Core i3/i5/i7<br />
#Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
==== PKGBUILDs ====<br />
<br />
You need the subversion program to download our buildscripts from the development tree. You can then do an anonymous checkout by running:<br />
<br />
<code><br />
svn co https://svn.archaudio.org/trunk/buildscripts archaudio-sources<br />
</code><br />
<br />
These are working copies of ongoing development, so the scripts may not reflect the contents of existing binary packages.<br />
<br />
A git mirror is available too, maintained by Bernardo ‘smoge’ Barros [https://github.com/smoge/ArchAudio]:<br />
<br />
<code><br />
git clone git://github.com/smoge/ArchAudio.git archaudio-sources<br />
</code></div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=135305Professional audio2011-03-30T01:37:31Z<p>Smoge: /* Packages */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
(or just install realtimeconfigquickscan from [http://aur.archlinux.org/packages.php?ID=46435 AUR])<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
----</div>Smogehttps://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=135076Unofficial user repositories2011-03-28T01:08:37Z<p>Smoge: /* x86_64 only */</p>
<hr />
<div>[[Category: Package management (English)]]<br />
==Why unofficial user repositories==<br />
Since the AUR only allows users to upload PKGBUILD and other package build related files, but does not provide a means for distributing a binary package, a user may want to create a binary repository of their packages elsewhere.<br />
<br />
==The future of Unofficial repos==<br />
I'd like to see more work of this type. Sometimes there are certain projects that don't mesh well with other things, such as the community repo. The 'kdemod' project is a good example. If you want to contribute with your own builds, you can check page [[Custom local repository]].<br />
<br />
In the future, well-thought-out user repositories may be ideal for lots of supplementary things. Forming a "web of trust" is important in cases like this, so we may begin keeping a list of "recommended" repositories somewhere, in order to make it seem more official and trustworthy.<br />
<br />
[[User:Phrakture|Phrakture]] 12:50, 18 May 2007 (EDT)<br />
<br />
== The community repository, maintained by the TUs==<br />
The community repository is included in pacman's default configuration.<br />
<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
==List of PUR (unofficial user repositories)==<br />
===Any===<br />
"Any" repos are architecture-independent, i.e. they can be used on both i686 and x86_64 systems.<br />
<pre><br />
[herecura-stable-any]<br />
# Just some stuff; a few java apps, wallpapers, small scripts, xbmc-skin<br />
Server = http://herecura.be/repo/herecura-stable/any<br />
<br />
[herecura-testing-any]<br />
# Some any testing stuff, xbmc-svn skin<br />
Server = http://herecura.be/repo/herecura-testing/any<br />
<br />
[xyne-any]<br />
# The home of Xyne's contributions.<br />
# More info including a package list can be found at http://xyne.archlinux.ca/repos<br />
Server = http://xyne.archlinux.ca/repos/xyne-any/<br />
<br />
</pre><br />
<br />
===Both i686 and x86_64===<br />
<!--Not exactly same as 'any' repositories, this section should probably be separate.--><br />
Repositories with both i686 and x86_64 versions. The $arch variable will be set automatically by pacman.<br />
<pre><br />
[archlinuxfr]<br />
# The french Arch Linux communities packages.<br />
Server = http://repo.archlinux.fr/$arch<br />
<br />
[archaudio-stable]<br />
# and/or *-testing, *-experimental<br />
# Pro-audio repo:<br />
# - http://archaudio.org<br />
# Replace "stable" with repo type (testing/experimental).<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
[archstuff]<br />
# AUR's most voted and many bin32-* and lib32-* packages.<br />
Server = http://archstuff.vs169092.vserver.de/$arch<br />
<br />
[arch-games]<br />
# The Arch Linux Gaming repository project.<br />
# Active mirrors listed in https://github.com/Arch-Games/arch-games/wiki/Mirrors<br />
Server = http://repo.exigen.org/arch/games/$arch<br />
Server = ftp://mirror.selfnet.de/arch-games/$arch<br />
# Currently inactive mirrors<br />
#Server = http://arch.twilightlair.net/games/$arch<br />
#Server = http://pseudoform.org/arch-games/games/$arch<br />
<br />
[burg]<br />
# Burg bootloader repo<br />
# More info : http://archydeb.wordpress.com/<br />
Server = http://dl.dropbox.com/u/11529444/$arch<br />
<br />
[cake]<br />
# Crapkit, dbus, hal, etc. stripped packages compatible with Arch Linux (from http://hereticlinux.org/).<br />
Server = http://hereticlinux.org/repo/cake/$arch<br />
<br />
[catalyst]<br />
# ATI Catalyst proprietary drivers.<br />
Server = http://catalyst.apocalypsus.net/repo/catalyst/$arch<br />
<br />
[pfkernel]<br />
# Kernel packages: generic i686 and x86_64, optimized P3, P4, K7, Atom, Pentium-M, K8, Core2<br />
# nvidia-pf, squid3, arora-git, nvidia-utils-beta<br />
Server = http://dl.dropbox.com/u/11734958/$arch<br />
<br />
[radeon]<br />
# ATI Radeon X.Org drivers, bleeding edge 'git' builds.<br />
Server = http://spiralinear.org/perry3d/$arch<br />
<br />
[sergej-repo]<br />
# ion3 and some other stuff.<br />
# http://code.google.com/p/archlinux-stuff/source/browse/trunk<br />
Server = http://repo.p5n.pp.ru/sergej-repo/$arch/<br />
<br />
[suckless]<br />
# suckless.org packages<br />
Server = http://dl.suckless.org/arch/$arch<br />
<br />
[tomoyo]<br />
# TOMOYO Linux kernels, modules and userspace tools<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
<br />
[unarch]<br />
# Offers support mainly against devel packages.<br />
# Contains stable packages that aren't in official repo.<br />
Server = http://us4all.info/unarch/arch/$arch<br />
<br />
[kittyserve]<br />
# Contains kittykatt's packages and packages from friends of kittykatt, as well as most mint-related packages<br />
Server = http://repo.kattz.tk/$arch<br />
</pre><br />
<br />
===i686 only===<br />
<pre><br />
[adslgr32]<br />
# The Hellenic (Greek) Arch Linux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/i686/<br />
<br />
[kde4-eyecandy-32]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/i686/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.org/doku.php/blog/linux/repository<br />
Server = http://repo.andrwe.org/i686<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/i686<br />
<br />
[arch-graphics]<br />
# Repository aimed to provide applications mainly for 3D graphics.<br />
# For more info, look at http://arch-graphics.kx.cz/<br />
Server = http://arch-graphics.kx.cz/repo/i686<br />
<br />
[cgr-i686]<br />
# Packages for some ChicoGeek's PKGBUILDs.<br />
Server = http://cgr.i686.googlepages.com/<br />
<br />
[chaox-stable]<br />
# Pentesting packages and custom kernel patched for WIFI injection.<br />
Server = http://repo.chaox.net/stable<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
# Updated to June 2008.<br />
Server = http://compiz.dreamz-box.de/i686<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/i686<br />
<br />
[dragonlord]<br />
# Mixed packages, I don't want to move into [community],<br />
# but are worth having them or the build time is long.<br />
Server = http://repo.dragonlord.cz/arch/i686<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/i686<br />
<br />
[esclinux]<br />
# Mostly games, interactive fiction and abc notation stuffs already on AUR.<br />
Server = http://download.tuxfamily.org/esclinuxcd/ressources/repo/i686/<br />
<br />
[fukawi]<br />
# Some Nagios Stuff; molly-guard; celtx and various networking tools.<br />
Server = http://repo.fukawi2.nl/i686/<br />
Server = ftp://repo.fukawi2.nl/i686/<br />
<br />
[jose1711repo]<br />
# Most of the packages I maintain in AUR (games, tools)<br />
Server = http://arch.l33t.in/i686/<br />
<br />
[kpiche]<br />
# Stable OpenSync packages.<br />
Server = http://kpiche.archlinux.ca/repo<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/).<br />
Server = http://pst.brankovukelic.com/i686<br />
<br />
[rfad]<br />
# Repository made by haxit | Contact at: requiem [at] archlinux.us for package suggestions!<br />
Server = http://web.ncf.ca/ey723/archlinux/repo/<br />
<br />
[xdemon-repo]<br />
# madwimax, kismet-svn and aircrack-svn, etc...<br />
Server=http://repo.x-demon.org/archlinux/os/i686<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://nightly.uhuc.de/i686<br />
<br />
[pozitpoh]<br />
# Fresh psi-plus, kvirc4, urtconnector, xneur, etc.<br />
Server = http://pozitpoh.is-a-geek.org/repo/i686<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/i686<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/i686<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/i686<br />
<br />
[mingw32]<br />
# Libs & tools for crosscompiling for Win32, mainly taken from AUR.<br />
# Contact: Alexander 'hatred' Drozdov <adrozdoff [at] gmail (dot) com> (Russian-speaked guys can write on Russian :-)<br />
Server = http://hatred.homelinux.net/archlinux/mingw32/os/i686<br />
<br />
[jrepo]<br />
# Random pkgs for my friends low-end and old laptop.<br />
# These pkgs are optimzed for pentium-m (i686 + sse2).<br />
# All pks that support pulseaudio have been natively complied to include it.<br />
# http://dl.dropbox.com/u/3422289/README list of pkgs and info<br />
Server = http://dl.dropbox.com/u/3422289<br />
<br />
[kernel-panic]<br />
# A various set of useful packages, including (but not limited to) opera, falconpl and kpackagekit<br />
Server = http://kernel-panic.dnsdojo.net/arch/i686<br />
<br />
[ayatana]<br />
# Packages from Ubuntu (humanity-icon-theme, ttf-ubuntu, ubuntu-light-themes, ubuntuone-client, indicator-applet, notify-osd…),<br />
# packages from elementary project (dexter, elementary-icon-theme, gloobus-preview, gnome-theme-elementary, postler…),<br />
# packages from Linux Mint (gnome-theme-mint, mintbackup, mintdesktop, mint-icon-theme, mintmenu…) and<br />
# apps with ayatana support (audio-recorder, banshee-community-extensions, cloudsn, gwibber, pino, sbackup, smuxi…),<br />
# extra GNOME apps (conduit, eog-plugins, glabels, gnome-color-manager, gnome-globalmenu, gnome-subtitles, ontv, pdfmod, rygel, postr, tasque…),<br />
# mapping apps (bt747, emerillon, foxtrotgps, gpx-viewer, merkaartor, navit, prune…),<br />
# some other apps (backintime, connman, faenza-icon-theme, gdesklets, keepnote, kompozer, nautilus-terminal, openbve, pinta, textflow, uget…).<br />
# More info: http://arch.ballogyorgy.com/<br />
Server = http://repo.ayatana.info/<br />
</pre><br />
<br />
===x86_64 only===<br />
<pre><br />
[kde4-eyecandy-64]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/x86_64/<br />
<br />
[adslgr64]<br />
# The Hellenic (Greek) archlinux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/x86_64/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.dyndns.org/doku.php/blog/repository<br />
Server = http://repo.andrwe.org/x86_64<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/x86_64<br />
<br />
[archlinuxve]<br />
# Home of the splashy packages.<br />
Server = http://repo.archlinux.com.ve/x86_64<br />
<br />
[archstudio]<br />
# ArchAudio Packages <br />
# Optimized for the first generation Intel Core i7 CPU <br />
# Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
Server = http://compiz.dreamz-box.de/x86_64<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/x86_64<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/x86_64<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/)<br />
Server = http://pst.brankovukelic.com/x86_64<br />
<br />
[dstr-repo]<br />
# qutim, psi, kdevelop with plugins dev builds and other stuff.<br />
Server = http://dimon.homeftp.org/repo/x86_64<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://files.shadowice.org/nightly/x86_64<br />
<br />
[zen]<br />
# Various and zengeist' AUR packages.<br />
Server = http://zloduch.cz/archlinux/x86_64<br />
<br />
[digitalpioneer]<br />
# Recent GIT/SVN/whatever builds of selected AUR packages.<br />
# List of packages is at http://dl.getdropbox.com/u/453116/repo/pkglist and is subject to change.<br />
# x86_64 only.<br />
Server = http://dl.getdropbox.com/u/453116/repo<br />
<br />
[seiichiro]<br />
# VDR and some plugins, mms, foo2zjs-drivers<br />
Server = http://repo.seiichiro0185.org/x86_64<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/x86_64<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/x86_64<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/x86_64<br />
<br />
[pyropeter]<br />
# My AUR packages: http://aur.archlinux.org/packages.php?SeB=m&K=pyropeter<br />
Server = http://keks.selfip.org/arch/pyropeter<br />
</pre><br />
<br />
==Add your own repository to this list==<br />
If you have your own repository, please add this to this list, so that all other users knows where to find your packages.</div>Smogehttps://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=135075Unofficial user repositories2011-03-28T01:03:59Z<p>Smoge: /* x86_64 only */</p>
<hr />
<div>[[Category: Package management (English)]]<br />
==Why unofficial user repositories==<br />
Since the AUR only allows users to upload PKGBUILD and other package build related files, but does not provide a means for distributing a binary package, a user may want to create a binary repository of their packages elsewhere.<br />
<br />
==The future of Unofficial repos==<br />
I'd like to see more work of this type. Sometimes there are certain projects that don't mesh well with other things, such as the community repo. The 'kdemod' project is a good example. If you want to contribute with your own builds, you can check page [[Custom local repository]].<br />
<br />
In the future, well-thought-out user repositories may be ideal for lots of supplementary things. Forming a "web of trust" is important in cases like this, so we may begin keeping a list of "recommended" repositories somewhere, in order to make it seem more official and trustworthy.<br />
<br />
[[User:Phrakture|Phrakture]] 12:50, 18 May 2007 (EDT)<br />
<br />
== The community repository, maintained by the TUs==<br />
The community repository is included in pacman's default configuration.<br />
<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
==List of PUR (unofficial user repositories)==<br />
===Any===<br />
"Any" repos are architecture-independent, i.e. they can be used on both i686 and x86_64 systems.<br />
<pre><br />
[herecura-stable-any]<br />
# Just some stuff; a few java apps, wallpapers, small scripts, xbmc-skin<br />
Server = http://herecura.be/repo/herecura-stable/any<br />
<br />
[herecura-testing-any]<br />
# Some any testing stuff, xbmc-svn skin<br />
Server = http://herecura.be/repo/herecura-testing/any<br />
<br />
[xyne-any]<br />
# The home of Xyne's contributions.<br />
# More info including a package list can be found at http://xyne.archlinux.ca/repos<br />
Server = http://xyne.archlinux.ca/repos/xyne-any/<br />
<br />
</pre><br />
<br />
===Both i686 and x86_64===<br />
<!--Not exactly same as 'any' repositories, this section should probably be separate.--><br />
Repositories with both i686 and x86_64 versions. The $arch variable will be set automatically by pacman.<br />
<pre><br />
[archlinuxfr]<br />
# The french Arch Linux communities packages.<br />
Server = http://repo.archlinux.fr/$arch<br />
<br />
[archaudio-stable]<br />
# and/or *-testing, *-experimental<br />
# Pro-audio repo:<br />
# - http://archaudio.org<br />
# Replace "stable" with repo type (testing/experimental).<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
[archstuff]<br />
# AUR's most voted and many bin32-* and lib32-* packages.<br />
Server = http://archstuff.vs169092.vserver.de/$arch<br />
<br />
[arch-games]<br />
# The Arch Linux Gaming repository project.<br />
# Active mirrors listed in https://github.com/Arch-Games/arch-games/wiki/Mirrors<br />
Server = http://repo.exigen.org/arch/games/$arch<br />
Server = ftp://mirror.selfnet.de/arch-games/$arch<br />
# Currently inactive mirrors<br />
#Server = http://arch.twilightlair.net/games/$arch<br />
#Server = http://pseudoform.org/arch-games/games/$arch<br />
<br />
[burg]<br />
# Burg bootloader repo<br />
# More info : http://archydeb.wordpress.com/<br />
Server = http://dl.dropbox.com/u/11529444/$arch<br />
<br />
[cake]<br />
# Crapkit, dbus, hal, etc. stripped packages compatible with Arch Linux (from http://hereticlinux.org/).<br />
Server = http://hereticlinux.org/repo/cake/$arch<br />
<br />
[catalyst]<br />
# ATI Catalyst proprietary drivers.<br />
Server = http://catalyst.apocalypsus.net/repo/catalyst/$arch<br />
<br />
[pfkernel]<br />
# Kernel packages: generic i686 and x86_64, optimized P3, P4, K7, Atom, Pentium-M, K8, Core2<br />
# nvidia-pf, squid3, arora-git, nvidia-utils-beta<br />
Server = http://dl.dropbox.com/u/11734958/$arch<br />
<br />
[radeon]<br />
# ATI Radeon X.Org drivers, bleeding edge 'git' builds.<br />
Server = http://spiralinear.org/perry3d/$arch<br />
<br />
[sergej-repo]<br />
# ion3 and some other stuff.<br />
# http://code.google.com/p/archlinux-stuff/source/browse/trunk<br />
Server = http://repo.p5n.pp.ru/sergej-repo/$arch/<br />
<br />
[suckless]<br />
# suckless.org packages<br />
Server = http://dl.suckless.org/arch/$arch<br />
<br />
[tomoyo]<br />
# TOMOYO Linux kernels, modules and userspace tools<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
<br />
[unarch]<br />
# Offers support mainly against devel packages.<br />
# Contains stable packages that aren't in official repo.<br />
Server = http://us4all.info/unarch/arch/$arch<br />
<br />
[kittyserve]<br />
# Contains kittykatt's packages and packages from friends of kittykatt, as well as most mint-related packages<br />
Server = http://repo.kattz.tk/$arch<br />
</pre><br />
<br />
===i686 only===<br />
<pre><br />
[adslgr32]<br />
# The Hellenic (Greek) Arch Linux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/i686/<br />
<br />
[kde4-eyecandy-32]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/i686/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.org/doku.php/blog/linux/repository<br />
Server = http://repo.andrwe.org/i686<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/i686<br />
<br />
[arch-graphics]<br />
# Repository aimed to provide applications mainly for 3D graphics.<br />
# For more info, look at http://arch-graphics.kx.cz/<br />
Server = http://arch-graphics.kx.cz/repo/i686<br />
<br />
[cgr-i686]<br />
# Packages for some ChicoGeek's PKGBUILDs.<br />
Server = http://cgr.i686.googlepages.com/<br />
<br />
[chaox-stable]<br />
# Pentesting packages and custom kernel patched for WIFI injection.<br />
Server = http://repo.chaox.net/stable<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
# Updated to June 2008.<br />
Server = http://compiz.dreamz-box.de/i686<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/i686<br />
<br />
[dragonlord]<br />
# Mixed packages, I don't want to move into [community],<br />
# but are worth having them or the build time is long.<br />
Server = http://repo.dragonlord.cz/arch/i686<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/i686<br />
<br />
[esclinux]<br />
# Mostly games, interactive fiction and abc notation stuffs already on AUR.<br />
Server = http://download.tuxfamily.org/esclinuxcd/ressources/repo/i686/<br />
<br />
[fukawi]<br />
# Some Nagios Stuff; molly-guard; celtx and various networking tools.<br />
Server = http://repo.fukawi2.nl/i686/<br />
Server = ftp://repo.fukawi2.nl/i686/<br />
<br />
[jose1711repo]<br />
# Most of the packages I maintain in AUR (games, tools)<br />
Server = http://arch.l33t.in/i686/<br />
<br />
[kpiche]<br />
# Stable OpenSync packages.<br />
Server = http://kpiche.archlinux.ca/repo<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/).<br />
Server = http://pst.brankovukelic.com/i686<br />
<br />
[rfad]<br />
# Repository made by haxit | Contact at: requiem [at] archlinux.us for package suggestions!<br />
Server = http://web.ncf.ca/ey723/archlinux/repo/<br />
<br />
[xdemon-repo]<br />
# madwimax, kismet-svn and aircrack-svn, etc...<br />
Server=http://repo.x-demon.org/archlinux/os/i686<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://nightly.uhuc.de/i686<br />
<br />
[pozitpoh]<br />
# Fresh psi-plus, kvirc4, urtconnector, xneur, etc.<br />
Server = http://pozitpoh.is-a-geek.org/repo/i686<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/i686<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/i686<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/i686<br />
<br />
[mingw32]<br />
# Libs & tools for crosscompiling for Win32, mainly taken from AUR.<br />
# Contact: Alexander 'hatred' Drozdov <adrozdoff [at] gmail (dot) com> (Russian-speaked guys can write on Russian :-)<br />
Server = http://hatred.homelinux.net/archlinux/mingw32/os/i686<br />
<br />
[jrepo]<br />
# Random pkgs for my friends low-end and old laptop.<br />
# These pkgs are optimzed for pentium-m (i686 + sse2).<br />
# All pks that support pulseaudio have been natively complied to include it.<br />
# http://dl.dropbox.com/u/3422289/README list of pkgs and info<br />
Server = http://dl.dropbox.com/u/3422289<br />
<br />
[kernel-panic]<br />
# A various set of useful packages, including (but not limited to) opera, falconpl and kpackagekit<br />
Server = http://kernel-panic.dnsdojo.net/arch/i686<br />
<br />
[ayatana]<br />
# Packages from Ubuntu (humanity-icon-theme, ttf-ubuntu, ubuntu-light-themes, ubuntuone-client, indicator-applet, notify-osd…),<br />
# packages from elementary project (dexter, elementary-icon-theme, gloobus-preview, gnome-theme-elementary, postler…),<br />
# packages from Linux Mint (gnome-theme-mint, mintbackup, mintdesktop, mint-icon-theme, mintmenu…) and<br />
# apps with ayatana support (audio-recorder, banshee-community-extensions, cloudsn, gwibber, pino, sbackup, smuxi…),<br />
# extra GNOME apps (conduit, eog-plugins, glabels, gnome-color-manager, gnome-globalmenu, gnome-subtitles, ontv, pdfmod, rygel, postr, tasque…),<br />
# mapping apps (bt747, emerillon, foxtrotgps, gpx-viewer, merkaartor, navit, prune…),<br />
# some other apps (backintime, connman, faenza-icon-theme, gdesklets, keepnote, kompozer, nautilus-terminal, openbve, pinta, textflow, uget…).<br />
# More info: http://arch.ballogyorgy.com/<br />
Server = http://repo.ayatana.info/<br />
</pre><br />
<br />
===x86_64 only===<br />
<pre><br />
[kde4-eyecandy-64]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/x86_64/<br />
<br />
[adslgr64]<br />
# The Hellenic (Greek) archlinux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/x86_64/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.dyndns.org/doku.php/blog/repository<br />
Server = http://repo.andrwe.org/x86_64<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/x86_64<br />
<br />
[archlinuxve]<br />
# Home of the splashy packages.<br />
Server = http://repo.archlinux.com.ve/x86_64<br />
<br />
[archstudio]<br />
# ArchAudio Packages <br />
# Optimized for the first generation Intel Core i7 CPU with 64-bit extensions<br />
# MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 and SSE4.2 instruction set support. <br />
# Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
Server = http://compiz.dreamz-box.de/x86_64<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/x86_64<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/x86_64<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/)<br />
Server = http://pst.brankovukelic.com/x86_64<br />
<br />
[dstr-repo]<br />
# qutim, psi, kdevelop with plugins dev builds and other stuff.<br />
Server = http://dimon.homeftp.org/repo/x86_64<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://files.shadowice.org/nightly/x86_64<br />
<br />
[zen]<br />
# Various and zengeist' AUR packages.<br />
Server = http://zloduch.cz/archlinux/x86_64<br />
<br />
[digitalpioneer]<br />
# Recent GIT/SVN/whatever builds of selected AUR packages.<br />
# List of packages is at http://dl.getdropbox.com/u/453116/repo/pkglist and is subject to change.<br />
# x86_64 only.<br />
Server = http://dl.getdropbox.com/u/453116/repo<br />
<br />
[seiichiro]<br />
# VDR and some plugins, mms, foo2zjs-drivers<br />
Server = http://repo.seiichiro0185.org/x86_64<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/x86_64<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/x86_64<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/x86_64<br />
<br />
[pyropeter]<br />
# My AUR packages: http://aur.archlinux.org/packages.php?SeB=m&K=pyropeter<br />
Server = http://keks.selfip.org/arch/pyropeter<br />
</pre><br />
<br />
==Add your own repository to this list==<br />
If you have your own repository, please add this to this list, so that all other users knows where to find your packages.</div>Smogehttps://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=135074Unofficial user repositories2011-03-28T01:01:09Z<p>Smoge: /* x86_64 only */</p>
<hr />
<div>[[Category: Package management (English)]]<br />
==Why unofficial user repositories==<br />
Since the AUR only allows users to upload PKGBUILD and other package build related files, but does not provide a means for distributing a binary package, a user may want to create a binary repository of their packages elsewhere.<br />
<br />
==The future of Unofficial repos==<br />
I'd like to see more work of this type. Sometimes there are certain projects that don't mesh well with other things, such as the community repo. The 'kdemod' project is a good example. If you want to contribute with your own builds, you can check page [[Custom local repository]].<br />
<br />
In the future, well-thought-out user repositories may be ideal for lots of supplementary things. Forming a "web of trust" is important in cases like this, so we may begin keeping a list of "recommended" repositories somewhere, in order to make it seem more official and trustworthy.<br />
<br />
[[User:Phrakture|Phrakture]] 12:50, 18 May 2007 (EDT)<br />
<br />
== The community repository, maintained by the TUs==<br />
The community repository is included in pacman's default configuration.<br />
<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
==List of PUR (unofficial user repositories)==<br />
===Any===<br />
"Any" repos are architecture-independent, i.e. they can be used on both i686 and x86_64 systems.<br />
<pre><br />
[herecura-stable-any]<br />
# Just some stuff; a few java apps, wallpapers, small scripts, xbmc-skin<br />
Server = http://herecura.be/repo/herecura-stable/any<br />
<br />
[herecura-testing-any]<br />
# Some any testing stuff, xbmc-svn skin<br />
Server = http://herecura.be/repo/herecura-testing/any<br />
<br />
[xyne-any]<br />
# The home of Xyne's contributions.<br />
# More info including a package list can be found at http://xyne.archlinux.ca/repos<br />
Server = http://xyne.archlinux.ca/repos/xyne-any/<br />
<br />
</pre><br />
<br />
===Both i686 and x86_64===<br />
<!--Not exactly same as 'any' repositories, this section should probably be separate.--><br />
Repositories with both i686 and x86_64 versions. The $arch variable will be set automatically by pacman.<br />
<pre><br />
[archlinuxfr]<br />
# The french Arch Linux communities packages.<br />
Server = http://repo.archlinux.fr/$arch<br />
<br />
[archaudio-stable]<br />
# and/or *-testing, *-experimental<br />
# Pro-audio repo:<br />
# - http://archaudio.org<br />
# Replace "stable" with repo type (testing/experimental).<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
[archstuff]<br />
# AUR's most voted and many bin32-* and lib32-* packages.<br />
Server = http://archstuff.vs169092.vserver.de/$arch<br />
<br />
[arch-games]<br />
# The Arch Linux Gaming repository project.<br />
# Active mirrors listed in https://github.com/Arch-Games/arch-games/wiki/Mirrors<br />
Server = http://repo.exigen.org/arch/games/$arch<br />
Server = ftp://mirror.selfnet.de/arch-games/$arch<br />
# Currently inactive mirrors<br />
#Server = http://arch.twilightlair.net/games/$arch<br />
#Server = http://pseudoform.org/arch-games/games/$arch<br />
<br />
[burg]<br />
# Burg bootloader repo<br />
# More info : http://archydeb.wordpress.com/<br />
Server = http://dl.dropbox.com/u/11529444/$arch<br />
<br />
[cake]<br />
# Crapkit, dbus, hal, etc. stripped packages compatible with Arch Linux (from http://hereticlinux.org/).<br />
Server = http://hereticlinux.org/repo/cake/$arch<br />
<br />
[catalyst]<br />
# ATI Catalyst proprietary drivers.<br />
Server = http://catalyst.apocalypsus.net/repo/catalyst/$arch<br />
<br />
[pfkernel]<br />
# Kernel packages: generic i686 and x86_64, optimized P3, P4, K7, Atom, Pentium-M, K8, Core2<br />
# nvidia-pf, squid3, arora-git, nvidia-utils-beta<br />
Server = http://dl.dropbox.com/u/11734958/$arch<br />
<br />
[radeon]<br />
# ATI Radeon X.Org drivers, bleeding edge 'git' builds.<br />
Server = http://spiralinear.org/perry3d/$arch<br />
<br />
[sergej-repo]<br />
# ion3 and some other stuff.<br />
# http://code.google.com/p/archlinux-stuff/source/browse/trunk<br />
Server = http://repo.p5n.pp.ru/sergej-repo/$arch/<br />
<br />
[suckless]<br />
# suckless.org packages<br />
Server = http://dl.suckless.org/arch/$arch<br />
<br />
[tomoyo]<br />
# TOMOYO Linux kernels, modules and userspace tools<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
<br />
[unarch]<br />
# Offers support mainly against devel packages.<br />
# Contains stable packages that aren't in official repo.<br />
Server = http://us4all.info/unarch/arch/$arch<br />
<br />
[kittyserve]<br />
# Contains kittykatt's packages and packages from friends of kittykatt, as well as most mint-related packages<br />
Server = http://repo.kattz.tk/$arch<br />
</pre><br />
<br />
===i686 only===<br />
<pre><br />
[adslgr32]<br />
# The Hellenic (Greek) Arch Linux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/i686/<br />
<br />
[kde4-eyecandy-32]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/i686/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.org/doku.php/blog/linux/repository<br />
Server = http://repo.andrwe.org/i686<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/i686<br />
<br />
[arch-graphics]<br />
# Repository aimed to provide applications mainly for 3D graphics.<br />
# For more info, look at http://arch-graphics.kx.cz/<br />
Server = http://arch-graphics.kx.cz/repo/i686<br />
<br />
[cgr-i686]<br />
# Packages for some ChicoGeek's PKGBUILDs.<br />
Server = http://cgr.i686.googlepages.com/<br />
<br />
[chaox-stable]<br />
# Pentesting packages and custom kernel patched for WIFI injection.<br />
Server = http://repo.chaox.net/stable<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
# Updated to June 2008.<br />
Server = http://compiz.dreamz-box.de/i686<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/i686<br />
<br />
[dragonlord]<br />
# Mixed packages, I don't want to move into [community],<br />
# but are worth having them or the build time is long.<br />
Server = http://repo.dragonlord.cz/arch/i686<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/i686<br />
<br />
[esclinux]<br />
# Mostly games, interactive fiction and abc notation stuffs already on AUR.<br />
Server = http://download.tuxfamily.org/esclinuxcd/ressources/repo/i686/<br />
<br />
[fukawi]<br />
# Some Nagios Stuff; molly-guard; celtx and various networking tools.<br />
Server = http://repo.fukawi2.nl/i686/<br />
Server = ftp://repo.fukawi2.nl/i686/<br />
<br />
[jose1711repo]<br />
# Most of the packages I maintain in AUR (games, tools)<br />
Server = http://arch.l33t.in/i686/<br />
<br />
[kpiche]<br />
# Stable OpenSync packages.<br />
Server = http://kpiche.archlinux.ca/repo<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/).<br />
Server = http://pst.brankovukelic.com/i686<br />
<br />
[rfad]<br />
# Repository made by haxit | Contact at: requiem [at] archlinux.us for package suggestions!<br />
Server = http://web.ncf.ca/ey723/archlinux/repo/<br />
<br />
[xdemon-repo]<br />
# madwimax, kismet-svn and aircrack-svn, etc...<br />
Server=http://repo.x-demon.org/archlinux/os/i686<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://nightly.uhuc.de/i686<br />
<br />
[pozitpoh]<br />
# Fresh psi-plus, kvirc4, urtconnector, xneur, etc.<br />
Server = http://pozitpoh.is-a-geek.org/repo/i686<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/i686<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/i686<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/i686<br />
<br />
[mingw32]<br />
# Libs & tools for crosscompiling for Win32, mainly taken from AUR.<br />
# Contact: Alexander 'hatred' Drozdov <adrozdoff [at] gmail (dot) com> (Russian-speaked guys can write on Russian :-)<br />
Server = http://hatred.homelinux.net/archlinux/mingw32/os/i686<br />
<br />
[jrepo]<br />
# Random pkgs for my friends low-end and old laptop.<br />
# These pkgs are optimzed for pentium-m (i686 + sse2).<br />
# All pks that support pulseaudio have been natively complied to include it.<br />
# http://dl.dropbox.com/u/3422289/README list of pkgs and info<br />
Server = http://dl.dropbox.com/u/3422289<br />
<br />
[kernel-panic]<br />
# A various set of useful packages, including (but not limited to) opera, falconpl and kpackagekit<br />
Server = http://kernel-panic.dnsdojo.net/arch/i686<br />
<br />
[ayatana]<br />
# Packages from Ubuntu (humanity-icon-theme, ttf-ubuntu, ubuntu-light-themes, ubuntuone-client, indicator-applet, notify-osd…),<br />
# packages from elementary project (dexter, elementary-icon-theme, gloobus-preview, gnome-theme-elementary, postler…),<br />
# packages from Linux Mint (gnome-theme-mint, mintbackup, mintdesktop, mint-icon-theme, mintmenu…) and<br />
# apps with ayatana support (audio-recorder, banshee-community-extensions, cloudsn, gwibber, pino, sbackup, smuxi…),<br />
# extra GNOME apps (conduit, eog-plugins, glabels, gnome-color-manager, gnome-globalmenu, gnome-subtitles, ontv, pdfmod, rygel, postr, tasque…),<br />
# mapping apps (bt747, emerillon, foxtrotgps, gpx-viewer, merkaartor, navit, prune…),<br />
# some other apps (backintime, connman, faenza-icon-theme, gdesklets, keepnote, kompozer, nautilus-terminal, openbve, pinta, textflow, uget…).<br />
# More info: http://arch.ballogyorgy.com/<br />
Server = http://repo.ayatana.info/<br />
</pre><br />
<br />
===x86_64 only===<br />
<pre><br />
[kde4-eyecandy-64]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/x86_64/<br />
<br />
[adslgr64]<br />
# The Hellenic (Greek) archlinux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/x86_64/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.dyndns.org/doku.php/blog/repository<br />
Server = http://repo.andrwe.org/x86_64<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/x86_64<br />
<br />
[archlinuxve]<br />
# Home of the splashy packages.<br />
Server = http://repo.archlinux.com.ve/x86_64<br />
<br />
[archstudio]<br />
# ArchAudio Packages <br />
# Optimized for Intel Core i7 CPU with 64-bit extensions<br />
# Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
Server = http://compiz.dreamz-box.de/x86_64<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/x86_64<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/x86_64<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/)<br />
Server = http://pst.brankovukelic.com/x86_64<br />
<br />
[dstr-repo]<br />
# qutim, psi, kdevelop with plugins dev builds and other stuff.<br />
Server = http://dimon.homeftp.org/repo/x86_64<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://files.shadowice.org/nightly/x86_64<br />
<br />
[zen]<br />
# Various and zengeist' AUR packages.<br />
Server = http://zloduch.cz/archlinux/x86_64<br />
<br />
[digitalpioneer]<br />
# Recent GIT/SVN/whatever builds of selected AUR packages.<br />
# List of packages is at http://dl.getdropbox.com/u/453116/repo/pkglist and is subject to change.<br />
# x86_64 only.<br />
Server = http://dl.getdropbox.com/u/453116/repo<br />
<br />
[seiichiro]<br />
# VDR and some plugins, mms, foo2zjs-drivers<br />
Server = http://repo.seiichiro0185.org/x86_64<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/x86_64<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/x86_64<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/x86_64<br />
<br />
[pyropeter]<br />
# My AUR packages: http://aur.archlinux.org/packages.php?SeB=m&K=pyropeter<br />
Server = http://keks.selfip.org/arch/pyropeter<br />
</pre><br />
<br />
==Add your own repository to this list==<br />
If you have your own repository, please add this to this list, so that all other users knows where to find your packages.</div>Smogehttps://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=135064Unofficial user repositories2011-03-27T18:45:31Z<p>Smoge: /* x86_64 only */</p>
<hr />
<div>[[Category: Package management (English)]]<br />
==Why unofficial user repositories==<br />
Since the AUR only allows users to upload PKGBUILD and other package build related files, but does not provide a means for distributing a binary package, a user may want to create a binary repository of their packages elsewhere.<br />
<br />
==The future of Unofficial repos==<br />
I'd like to see more work of this type. Sometimes there are certain projects that don't mesh well with other things, such as the community repo. The 'kdemod' project is a good example. If you want to contribute with your own builds, you can check page [[Custom local repository]].<br />
<br />
In the future, well-thought-out user repositories may be ideal for lots of supplementary things. Forming a "web of trust" is important in cases like this, so we may begin keeping a list of "recommended" repositories somewhere, in order to make it seem more official and trustworthy.<br />
<br />
[[User:Phrakture|Phrakture]] 12:50, 18 May 2007 (EDT)<br />
<br />
== The community repository, maintained by the TUs==<br />
The community repository is included in pacman's default configuration.<br />
<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
==List of PUR (unofficial user repositories)==<br />
===Any===<br />
"Any" repos are architecture-independent, i.e. they can be used on both i686 and x86_64 systems.<br />
<pre><br />
[herecura-stable-any]<br />
# Just some stuff; a few java apps, wallpapers, small scripts, xbmc-skin<br />
Server = http://herecura.be/repo/herecura-stable/any<br />
<br />
[herecura-testing-any]<br />
# Some any testing stuff, xbmc-svn skin<br />
Server = http://herecura.be/repo/herecura-testing/any<br />
<br />
[xyne-any]<br />
# The home of Xyne's contributions.<br />
# More info including a package list can be found at http://xyne.archlinux.ca/repos<br />
Server = http://xyne.archlinux.ca/repos/xyne-any/<br />
<br />
</pre><br />
<br />
===Both i686 and x86_64===<br />
<!--Not exactly same as 'any' repositories, this section should probably be separate.--><br />
Repositories with both i686 and x86_64 versions. The $arch variable will be set automatically by pacman.<br />
<pre><br />
[archlinuxfr]<br />
# The french Arch Linux communities packages.<br />
Server = http://repo.archlinux.fr/$arch<br />
<br />
[archaudio-stable]<br />
# and/or *-testing, *-experimental<br />
# Pro-audio repo:<br />
# - http://archaudio.org<br />
# Replace "stable" with repo type (testing/experimental).<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
[archstuff]<br />
# AUR's most voted and many bin32-* and lib32-* packages.<br />
Server = http://archstuff.vs169092.vserver.de/$arch<br />
<br />
[arch-games]<br />
# The Arch Linux Gaming repository project.<br />
# Active mirrors listed in https://github.com/Arch-Games/arch-games/wiki/Mirrors<br />
Server = http://repo.exigen.org/arch/games/$arch<br />
Server = ftp://mirror.selfnet.de/arch-games/$arch<br />
# Currently inactive mirrors<br />
#Server = http://arch.twilightlair.net/games/$arch<br />
#Server = http://pseudoform.org/arch-games/games/$arch<br />
<br />
[burg]<br />
# Burg bootloader repo<br />
# More info : http://archydeb.wordpress.com/<br />
Server = http://dl.dropbox.com/u/11529444/$arch<br />
<br />
[cake]<br />
# Crapkit, dbus, hal, etc. stripped packages compatible with Arch Linux (from http://hereticlinux.org/).<br />
Server = http://hereticlinux.org/repo/cake/$arch<br />
<br />
[catalyst]<br />
# ATI Catalyst proprietary drivers.<br />
Server = http://catalyst.apocalypsus.net/repo/catalyst/$arch<br />
<br />
[pfkernel]<br />
# Kernel packages: generic i686 and x86_64, optimized P3, P4, K7, Atom, Pentium-M, K8, Core2<br />
# nvidia-pf, squid3, arora-git, nvidia-utils-beta<br />
Server = http://dl.dropbox.com/u/11734958/$arch<br />
<br />
[radeon]<br />
# ATI Radeon X.Org drivers, bleeding edge 'git' builds.<br />
Server = http://spiralinear.org/perry3d/$arch<br />
<br />
[sergej-repo]<br />
# ion3 and some other stuff.<br />
# http://code.google.com/p/archlinux-stuff/source/browse/trunk<br />
Server = http://repo.p5n.pp.ru/sergej-repo/$arch/<br />
<br />
[suckless]<br />
# suckless.org packages<br />
Server = http://dl.suckless.org/arch/$arch<br />
<br />
[tomoyo]<br />
# TOMOYO Linux kernels, modules and userspace tools<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
<br />
[unarch]<br />
# Offers support mainly against devel packages.<br />
# Contains stable packages that aren't in official repo.<br />
Server = http://us4all.info/unarch/arch/$arch<br />
<br />
[kittyserve]<br />
# Contains kittykatt's packages and packages from friends of kittykatt, as well as most mint-related packages<br />
Server = http://repo.kattz.tk/$arch<br />
</pre><br />
<br />
===i686 only===<br />
<pre><br />
[adslgr32]<br />
# The Hellenic (Greek) Arch Linux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/i686/<br />
<br />
[kde4-eyecandy-32]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/i686/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.org/doku.php/blog/linux/repository<br />
Server = http://repo.andrwe.org/i686<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/i686<br />
<br />
[arch-graphics]<br />
# Repository aimed to provide applications mainly for 3D graphics.<br />
# For more info, look at http://arch-graphics.kx.cz/<br />
Server = http://arch-graphics.kx.cz/repo/i686<br />
<br />
[cgr-i686]<br />
# Packages for some ChicoGeek's PKGBUILDs.<br />
Server = http://cgr.i686.googlepages.com/<br />
<br />
[chaox-stable]<br />
# Pentesting packages and custom kernel patched for WIFI injection.<br />
Server = http://repo.chaox.net/stable<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
# Updated to June 2008.<br />
Server = http://compiz.dreamz-box.de/i686<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/i686<br />
<br />
[dragonlord]<br />
# Mixed packages, I don't want to move into [community],<br />
# but are worth having them or the build time is long.<br />
Server = http://repo.dragonlord.cz/arch/i686<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/i686<br />
<br />
[esclinux]<br />
# Mostly games, interactive fiction and abc notation stuffs already on AUR.<br />
Server = http://download.tuxfamily.org/esclinuxcd/ressources/repo/i686/<br />
<br />
[fukawi]<br />
# Some Nagios Stuff; molly-guard; celtx and various networking tools.<br />
Server = http://repo.fukawi2.nl/i686/<br />
Server = ftp://repo.fukawi2.nl/i686/<br />
<br />
[jose1711repo]<br />
# Most of the packages I maintain in AUR (games, tools)<br />
Server = http://arch.l33t.in/i686/<br />
<br />
[kpiche]<br />
# Stable OpenSync packages.<br />
Server = http://kpiche.archlinux.ca/repo<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/).<br />
Server = http://pst.brankovukelic.com/i686<br />
<br />
[rfad]<br />
# Repository made by haxit | Contact at: requiem [at] archlinux.us for package suggestions!<br />
Server = http://web.ncf.ca/ey723/archlinux/repo/<br />
<br />
[xdemon-repo]<br />
# madwimax, kismet-svn and aircrack-svn, etc...<br />
Server=http://repo.x-demon.org/archlinux/os/i686<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://nightly.uhuc.de/i686<br />
<br />
[pozitpoh]<br />
# Fresh psi-plus, kvirc4, urtconnector, xneur, etc.<br />
Server = http://pozitpoh.is-a-geek.org/repo/i686<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/i686<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/i686<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/i686<br />
<br />
[mingw32]<br />
# Libs & tools for crosscompiling for Win32, mainly taken from AUR.<br />
# Contact: Alexander 'hatred' Drozdov <adrozdoff [at] gmail (dot) com> (Russian-speaked guys can write on Russian :-)<br />
Server = http://hatred.homelinux.net/archlinux/mingw32/os/i686<br />
<br />
[jrepo]<br />
# Random pkgs for my friends low-end and old laptop.<br />
# These pkgs are optimzed for pentium-m (i686 + sse2).<br />
# All pks that support pulseaudio have been natively complied to include it.<br />
# http://dl.dropbox.com/u/3422289/README list of pkgs and info<br />
Server = http://dl.dropbox.com/u/3422289<br />
<br />
[kernel-panic]<br />
# A various set of useful packages, including (but not limited to) opera, falconpl and kpackagekit<br />
Server = http://kernel-panic.dnsdojo.net/arch/i686<br />
<br />
[ayatana]<br />
# Packages from Ubuntu (humanity-icon-theme, ttf-ubuntu, ubuntu-light-themes, ubuntuone-client, indicator-applet, notify-osd…),<br />
# packages from elementary project (dexter, elementary-icon-theme, gloobus-preview, gnome-theme-elementary, postler…),<br />
# packages from Linux Mint (gnome-theme-mint, mintbackup, mintdesktop, mint-icon-theme, mintmenu…) and<br />
# apps with ayatana support (audio-recorder, banshee-community-extensions, cloudsn, gwibber, pino, sbackup, smuxi…),<br />
# extra GNOME apps (conduit, eog-plugins, glabels, gnome-color-manager, gnome-globalmenu, gnome-subtitles, ontv, pdfmod, rygel, postr, tasque…),<br />
# mapping apps (bt747, emerillon, foxtrotgps, gpx-viewer, merkaartor, navit, prune…),<br />
# some other apps (backintime, connman, faenza-icon-theme, gdesklets, keepnote, kompozer, nautilus-terminal, openbve, pinta, textflow, uget…).<br />
# More info: http://arch.ballogyorgy.com/<br />
Server = http://repo.ayatana.info/<br />
</pre><br />
<br />
===x86_64 only===<br />
<pre><br />
[kde4-eyecandy-64]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/x86_64/<br />
<br />
[adslgr64]<br />
# The Hellenic (Greek) archlinux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/x86_64/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.dyndns.org/doku.php/blog/repository<br />
Server = http://repo.andrwe.org/x86_64<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/x86_64<br />
<br />
[archlinuxve]<br />
# Home of the splashy packages.<br />
Server = http://repo.archlinux.com.ve/x86_64<br />
<br />
[archstudio]<br />
# ArchAudio Packages <br />
# Optimized for Intel Core2Duo, Core i3, i5, i7 and Xeon 55xx<br />
# Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
Server = http://compiz.dreamz-box.de/x86_64<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/x86_64<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/x86_64<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/)<br />
Server = http://pst.brankovukelic.com/x86_64<br />
<br />
[dstr-repo]<br />
# qutim, psi, kdevelop with plugins dev builds and other stuff.<br />
Server = http://dimon.homeftp.org/repo/x86_64<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://files.shadowice.org/nightly/x86_64<br />
<br />
[zen]<br />
# Various and zengeist' AUR packages.<br />
Server = http://zloduch.cz/archlinux/x86_64<br />
<br />
[digitalpioneer]<br />
# Recent GIT/SVN/whatever builds of selected AUR packages.<br />
# List of packages is at http://dl.getdropbox.com/u/453116/repo/pkglist and is subject to change.<br />
# x86_64 only.<br />
Server = http://dl.getdropbox.com/u/453116/repo<br />
<br />
[seiichiro]<br />
# VDR and some plugins, mms, foo2zjs-drivers<br />
Server = http://repo.seiichiro0185.org/x86_64<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/x86_64<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/x86_64<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/x86_64<br />
<br />
[pyropeter]<br />
# My AUR packages: http://aur.archlinux.org/packages.php?SeB=m&K=pyropeter<br />
Server = http://keks.selfip.org/arch/pyropeter<br />
</pre><br />
<br />
==Add your own repository to this list==<br />
If you have your own repository, please add this to this list, so that all other users knows where to find your packages.</div>Smogehttps://wiki.archlinux.org/index.php?title=User:Unikum/Ulatencyd&diff=130913User:Unikum/Ulatencyd2011-02-14T15:58:12Z<p>Smoge: /* Installation */</p>
<hr />
<div>Ulatency is a daemon that controls how the Linux kernel will spend it's<br />
resources on the running processes. It uses dynamic cgroups to give the kernel<br />
hints and limitations on processes.<br />
<br />
It strongly supports the lua scripting language for writing rules and the<br />
scheduler code.<br />
<br />
==Installation==<br />
<br />
It is provided both in ArchAudio/testing repository and AUR:<br />
<br />
pacman -S ulatencyd<br />
<br />
add ulatencyd in DAEMONS section in /etc/rc.conf<br />
<br />
==Configuration==<br />
Default config file is /etc/ulatencyd/ulatencyd.conf. Rules is /etc/ulatencyd/rules/<br />
<br />
==See ALso==<br />
<br />
[https://github.com/poelzi/ulatencyd/ - Home page]</div>Smogehttps://wiki.archlinux.org/index.php?title=User:Unikum/Ulatencyd&diff=130912User:Unikum/Ulatencyd2011-02-14T15:40:12Z<p>Smoge: /* Installation */</p>
<hr />
<div>Ulatency is a daemon that controls how the Linux kernel will spend it's<br />
resources on the running processes. It uses dynamic cgroups to give the kernel<br />
hints and limitations on processes.<br />
<br />
It strongly supports the lua scripting language for writing rules and the<br />
scheduler code.<br />
<br />
==Installation==<br />
<br />
It is provided both in ArchAudio/testing repository and AUR:<br />
<br />
yaourt -S ulatencyd<br />
<br />
add ulatencyd in DAEMONS section in /etc/rc.conf<br />
<br />
==Configuration==<br />
Default config file is /etc/ulatencyd/ulatencyd.conf. Rules is /etc/ulatencyd/rules/<br />
<br />
==See ALso==<br />
<br />
[https://github.com/poelzi/ulatencyd/ - Home page]</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=130490Professional audio2011-02-11T15:51:42Z<p>Smoge: /* Packages */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
----<br />
<br />
<br />
=== Packages ===<br />
<br />
Our Packages as of Fri Fev 11 15:46:02 UTC 2011<br />
<br />
==== Stable Packages ====<br />
<br />
* archaudio-devtools<br />
* ardour<br />
* ardourvst<br />
* cwiid<br />
* jack<br />
* kernel26rt<br />
* kernel26rtpae<br />
* nvidia-rt<br />
* nvidia-rtpae<br />
<br />
==== Testing Packages ====<br />
<br />
* a2jmidid<br />
* abjad<br />
* addinclude<br />
* adlmidi<br />
* aeolus<br />
* afsp<br />
* aj-snapshot<br />
* algoscore<br />
* aliki<br />
* alsaequal<br />
* alsa-firmware<br />
* alsa-lib<br />
* alsa-plugins<br />
* alsa-tools<br />
* alsa-tools-emu10k1<br />
* alsa-tools-emu10k1-gui<br />
* alsa-tools-ice1712<br />
* ambdec<br />
* ams<br />
* amsynth<br />
* arduino<br />
* arduino-0021<br />
* argtable<br />
* arss<br />
* athenacl<br />
* aubio<br />
* audio-combine<br />
* audioconvert<br />
* audio-convert-mod<br />
* audiotools<br />
* azr3-jack<br />
* baudline<br />
* beast<br />
* bigband<br />
* bitmeter<br />
* bml<br />
* bristol<br />
* brutefir<br />
* bse-alsa<br />
* bsl<br />
* buzztard<br />
* calf<br />
* cd<br />
* cecilia2<br />
* cecilia4<br />
* ceres<br />
* ceres3<br />
* cheesetracker<br />
* chino<br />
* clalsadrv<br />
* clalsadrv-apps<br />
* clthreads<br />
* clxclient<br />
* cm-grace-bin<br />
* connie<br />
* csound<br />
* csound-cecilia<br />
* csound-doc<br />
* demolition<br />
* din<br />
* dino<br />
* dirogg<br />
* dssi-fluidsynth<br />
* dssi-hexter<br />
* dssi-ll-scope<br />
* dssi-nekobee<br />
* dssi-vst<br />
* eko<br />
* esjit<br />
* fastbreeder<br />
* faust<br />
* fftw2-threads<br />
* fftw-threads<br />
* fms<br />
* fomus<br />
* foo-yc20<br />
* freebirth<br />
* freeverb3<br />
* freewheeling<br />
* freqtweak<br />
* frescobaldi<br />
* frescobaldi-devel<br />
* galan<br />
* ghostess<br />
* glame<br />
* gluid<br />
* gmidimonitor<br />
* gst123<br />
* gst-buzztard<br />
* gtklick<br />
* guido<br />
* guitarix<br />
* gwc<br />
* gx_head<br />
* iannix<br />
* ir-true-m7<br />
* jaaa<br />
* jack2<br />
* jackbeat<br />
* jack_capture<br />
* jackctl<br />
* jack-delay<br />
* jackeq<br />
* jacker<br />
* jack-keyboard<br />
* jackmeter<br />
* jackminimix<br />
* jack-mixer<br />
* jack_oscrolloscope<br />
* jack-rack<br />
* jacksampler<br />
* jack_snapshot<br />
* jamin<br />
* japa<br />
* jcgui<br />
* jconvolver<br />
* jkmeter<br />
* jmeters<br />
* jnoise<br />
* jost<br />
* jost-bin<br />
* jpmidi<br />
* juce<br />
* kernel26rt<br />
* kernel26rtpae<br />
* klick<br />
* kmidimon<br />
* kwave<br />
* ladish<br />
* laditools<br />
* ladspa-amb-plugins<br />
* ladspa-autotalent-plugins<br />
* ladspa-blepvco-plugins<br />
* ladspa-blop-plugins<br />
* ladspa-bs2b<br />
* ladspa-caps-plugins<br />
* ladspa-cmt-plugins<br />
* ladspa-fil-plugins<br />
* ladspa-invada-studio-plugins<br />
* ladspa-mcp-plugins<br />
* ladspa-njl-plugins<br />
* ladspa-nlfilter<br />
* ladspa-rev-plugins<br />
* ladspa-swh-plugins<br />
* ladspa-tap-plugins<br />
* ladspa-vcf<br />
* ladspa-vco-plugins<br />
* ladspa-wah-plugins<br />
* lash<br />
* lemma<br />
* lib32-libusb<br />
* lib32-libusb-compat<br />
* libbs2b<br />
* libffado<br />
* libfishsound<br />
* libglade-old<br />
* libinstpatch<br />
* libircclient<br />
* liblscp<br />
* libmpeg3<br />
* librxtx-arduino<br />
* libsigc++1.2<br />
* libsmf<br />
* libtimidity<br />
* libunicap<br />
* libxml<br />
* lilypond-devel<br />
* linuxdsp-jackgtk<br />
* linuxvst-miscellaneous<br />
* luaposix<br />
* lv2-aubio<br />
* lv2-autotalent<br />
* lv2-c++-tools<br />
* lv2-deathcrush<br />
* lv2dynparam1<br />
* lv2-eq10q-plugins<br />
* lv2file<br />
* lv2-fil-plugins<br />
* lv2-invada-studio-plugins<br />
* lv2-ir<br />
* lv2-ll-plugins<br />
* lv2-so-404<br />
* lv2-so-666<br />
* lv2-so-kl5<br />
* lv2-swh-plugins<br />
* lv2-teliasopia<br />
* lv2-vocoder-plugins<br />
* lv2-vocproc<br />
* mammut<br />
* mcontrol<br />
* meterbridge<br />
* midicomp<br />
* mididings<br />
* midimon<br />
* midiosc<br />
* midirandomizer<br />
* midisend<br />
* milkytracker<br />
* mingus<br />
* minicomputer<br />
* mixxx1.9-bzr<br />
* mma<br />
* motiontrackosc<br />
* muse2-vst<br />
* music21<br />
* naspro-bridges-bad<br />
* naspro-core<br />
* nekobee<br />
* non-daw<br />
* nsound<br />
* nvidia-all<br />
* nvidia-daw<br />
* nvidia-rt<br />
* oggconvert<br />
* oscpack<br />
* paulstretch<br />
* pd<br />
* pd-arraysize<br />
* pd-boids<br />
* pd-bsaylor<br />
* pd-creb<br />
* pd-cyclone<br />
* pd-ekext<br />
* pd-ext13<br />
* pd-extended<br />
* pd-freeverb<br />
* pd-gem<br />
* pd-ggee<br />
* pd-gridflow<br />
* pd-hid<br />
* pd-jmmmp<br />
* pd-ladspa<br />
* pd-list-abs<br />
* pd-mapping<br />
* pd-motex<br />
* pd-pdogg<br />
* pd-pdp<br />
* pd-plugin<br />
* pd-pmpd<br />
* pd-purepd<br />
* pd-sigpack<br />
* pd-smlib<br />
* pd-vbap<br />
* pd-windowing<br />
* pd-zexy<br />
* perl-audio-flac-header<br />
* phasex<br />
* phasex-dev<br />
* phat<br />
* plotmm<br />
* pmidi<br />
* portaudio<br />
* praat<br />
* processing<br />
* pyaudio<br />
* pyduino-svn<br />
* pyfluidsynth<br />
* pygtk-1.2<br />
* pyjack<br />
* pylash<br />
* pymplayer<br />
* pyphat<br />
* python2-liblo<br />
* python2-portmidi<br />
* python2-pyo<br />
* python-audioprocessing<br />
* python-pyalsaaudio<br />
* qamix<br />
* qarecord<br />
* qloud<br />
* qmidiarp<br />
* qmidicontrol<br />
* qmidictl<br />
* qmidicurves<br />
* qmidiroute<br />
* qsampler<br />
* qtractor-vst<br />
* qutecsound<br />
* rakarrack<br />
* resample<br />
* rezound<br />
* rhost<br />
* rtirq<br />
* rt_pvc<br />
* rumor<br />
* samplecat<br />
* schismtracker<br />
* seq24<br />
* seq24-bzr<br />
* sfarkxtc<br />
* smasher<br />
* snack<br />
* sndfile-tools<br />
* snd-gtk-jack<br />
* sndlib<br />
* sndobj<br />
* sndpeek<br />
* sndpeek-jack<br />
* softwerk<br />
* sonic-visualiser<br />
* sooperlooper<br />
* soundfontcombi<br />
* soundfont-fluidr3<br />
* soundfont-personalcopy<br />
* soundfont-sgm180<br />
* soundfont-unison<br />
* soundtank<br />
* spatosc<br />
* spectmorph<br />
* spek<br />
* spiralsynthmodular<br />
* stretchplayer<br />
* supercollider<br />
* supercollider-with-extras<br />
* swami<br />
* swingosc<br />
* synthforge<br />
* synthofnoise<br />
* tapeutape<br />
* tapiir<br />
* tap-reverbed<br />
* timemachine<br />
* timidity-eawpatches<br />
* timidity-shominst<br />
* traverso<br />
* ttf-acoustica<br />
* ttf-concreta<br />
* ttf-controla<br />
* ttf-electronica<br />
* tuneit<br />
* tuxguitar-stable<br />
* twolame<br />
* ulatencyd<br />
* vamp-plugin-sdk<br />
* vamp-qm<br />
* vkeybd<br />
* vlevel<br />
* vmpk<br />
* waon<br />
* wavesurfer<br />
* whysynth<br />
* wildmidi<br />
* wineasio<br />
* xanalyser<br />
* xjadeo<br />
* xpmidi<br />
* xsynth-dssi<br />
* xwax-jack<br />
* yass<br />
* yoshimi<br />
* zita-at1<br />
* zita-convolver<br />
* zita-resample<br />
* zita-resampler<br />
* zita-rev1<br />
* zyn<br />
* zynaddsubfx<br />
* zynjacku<br />
<br />
==== Experimental Packages ====<br />
<br />
* a2jmidid-git<br />
* abjad-svn<br />
* alsa-lib-git<br />
* ams-cvs<br />
* ardour2-svn<br />
* arduide-git<br />
* athenacl-svn<br />
* audacity-cvs<br />
* calf-git<br />
* csound-cvs<br />
* cwiid-git<br />
* denemo-git<br />
* din-svn<br />
* eugene-svn<br />
* faust-git<br />
* flowcanvas-svn<br />
* fontforge-cvs<br />
* freebirth-svn<br />
* fst-git<br />
* galan-git<br />
* gigedit-cvs<br />
* guitarix-svn<br />
* hydrogen-svn<br />
* iannix-svn<br />
* inconcert-git<br />
* ingen-svn<br />
* inscore-bin<br />
* jack2-svn<br />
* jacker-hg<br />
* jacksampler-git<br />
* jack-svn<br />
* jlscp-cvs<br />
* jm2cv-git<br />
* jsampler-cvs<br />
* kernel26daw<br />
* kernel26icedrt<br />
* ladspa-njl-plugins-git<br />
* lash-git<br />
* libffado-svn<br />
* libgig-cvs<br />
* liblscp-cvs<br />
* lilypond-git<br />
* linuxsampler-cvs<br />
* lmms-git<br />
* lv2core-svn<br />
* lv2-fil-plugins-git<br />
* lv2-mda-svn<br />
* machina-svn<br />
* mingus-svn<br />
* musescore-svn<br />
* oscpack-svn<br />
* pd-extended-svn<br />
* pd-flext-svn<br />
* pd-gem-svn<br />
* pd-git<br />
* phasex-dev-git<br />
* phasex-git<br />
* portaudio-svn<br />
* pyfluidsynth-svn<br />
* python2-pyo-svn<br />
* qjackctl-svn<br />
* qmidiroute-cvs<br />
* qsampler-svn<br />
* qtractor-vst-svn<br />
* rakarrack-git<br />
* raul-svn<br />
* redlandmm-svn<br />
* scate-git<br />
* slv2-svn<br />
* sndobj-cvs<br />
* soundgrain<br />
* specimen-svn<br />
* speex-svn<br />
* supercollider-3.4-git<br />
* supercollider-with-extras-git<br />
* supercute-git<br />
* supercute-with-extras-git<br />
* traverso-git</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=130489Professional audio2011-02-11T15:48:29Z<p>Smoge: /* Arch Linux Pro Audio Project */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. <br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
----<br />
<br />
<br />
=== Packages ===<br />
<br />
Our Packages as of UTC Fri Fev 11 15:46:02 UTC 2011<br />
<br />
==== Stable Packages ====<br />
<br />
* archaudio-devtools<br />
* ardour<br />
* ardourvst<br />
* cwiid<br />
* jack<br />
* kernel26rt<br />
* kernel26rtpae<br />
* nvidia-rt<br />
* nvidia-rtpae<br />
<br />
==== Testing Packages ====<br />
<br />
* a2jmidid<br />
* abjad<br />
* addinclude<br />
* adlmidi<br />
* aeolus<br />
* afsp<br />
* aj-snapshot<br />
* algoscore<br />
* aliki<br />
* alsaequal<br />
* alsa-firmware<br />
* alsa-lib<br />
* alsa-plugins<br />
* alsa-tools<br />
* alsa-tools-emu10k1<br />
* alsa-tools-emu10k1-gui<br />
* alsa-tools-ice1712<br />
* ambdec<br />
* ams<br />
* amsynth<br />
* arduino<br />
* arduino-0021<br />
* argtable<br />
* arss<br />
* athenacl<br />
* aubio<br />
* audio-combine<br />
* audioconvert<br />
* audio-convert-mod<br />
* audiotools<br />
* azr3-jack<br />
* baudline<br />
* beast<br />
* bigband<br />
* bitmeter<br />
* bml<br />
* bristol<br />
* brutefir<br />
* bse-alsa<br />
* bsl<br />
* buzztard<br />
* calf<br />
* cd<br />
* cecilia2<br />
* cecilia4<br />
* ceres<br />
* ceres3<br />
* cheesetracker<br />
* chino<br />
* clalsadrv<br />
* clalsadrv-apps<br />
* clthreads<br />
* clxclient<br />
* cm-grace-bin<br />
* connie<br />
* csound<br />
* csound-cecilia<br />
* csound-doc<br />
* demolition<br />
* din<br />
* dino<br />
* dirogg<br />
* dssi-fluidsynth<br />
* dssi-hexter<br />
* dssi-ll-scope<br />
* dssi-nekobee<br />
* dssi-vst<br />
* eko<br />
* esjit<br />
* fastbreeder<br />
* faust<br />
* fftw2-threads<br />
* fftw-threads<br />
* fms<br />
* fomus<br />
* foo-yc20<br />
* freebirth<br />
* freeverb3<br />
* freewheeling<br />
* freqtweak<br />
* frescobaldi<br />
* frescobaldi-devel<br />
* galan<br />
* ghostess<br />
* glame<br />
* gluid<br />
* gmidimonitor<br />
* gst123<br />
* gst-buzztard<br />
* gtklick<br />
* guido<br />
* guitarix<br />
* gwc<br />
* gx_head<br />
* iannix<br />
* ir-true-m7<br />
* jaaa<br />
* jack2<br />
* jackbeat<br />
* jack_capture<br />
* jackctl<br />
* jack-delay<br />
* jackeq<br />
* jacker<br />
* jack-keyboard<br />
* jackmeter<br />
* jackminimix<br />
* jack-mixer<br />
* jack_oscrolloscope<br />
* jack-rack<br />
* jacksampler<br />
* jack_snapshot<br />
* jamin<br />
* japa<br />
* jcgui<br />
* jconvolver<br />
* jkmeter<br />
* jmeters<br />
* jnoise<br />
* jost<br />
* jost-bin<br />
* jpmidi<br />
* juce<br />
* kernel26rt<br />
* kernel26rtpae<br />
* klick<br />
* kmidimon<br />
* kwave<br />
* ladish<br />
* laditools<br />
* ladspa-amb-plugins<br />
* ladspa-autotalent-plugins<br />
* ladspa-blepvco-plugins<br />
* ladspa-blop-plugins<br />
* ladspa-bs2b<br />
* ladspa-caps-plugins<br />
* ladspa-cmt-plugins<br />
* ladspa-fil-plugins<br />
* ladspa-invada-studio-plugins<br />
* ladspa-mcp-plugins<br />
* ladspa-njl-plugins<br />
* ladspa-nlfilter<br />
* ladspa-rev-plugins<br />
* ladspa-swh-plugins<br />
* ladspa-tap-plugins<br />
* ladspa-vcf<br />
* ladspa-vco-plugins<br />
* ladspa-wah-plugins<br />
* lash<br />
* lemma<br />
* lib32-libusb<br />
* lib32-libusb-compat<br />
* libbs2b<br />
* libffado<br />
* libfishsound<br />
* libglade-old<br />
* libinstpatch<br />
* libircclient<br />
* liblscp<br />
* libmpeg3<br />
* librxtx-arduino<br />
* libsigc++1.2<br />
* libsmf<br />
* libtimidity<br />
* libunicap<br />
* libxml<br />
* lilypond-devel<br />
* linuxdsp-jackgtk<br />
* linuxvst-miscellaneous<br />
* luaposix<br />
* lv2-aubio<br />
* lv2-autotalent<br />
* lv2-c++-tools<br />
* lv2-deathcrush<br />
* lv2dynparam1<br />
* lv2-eq10q-plugins<br />
* lv2file<br />
* lv2-fil-plugins<br />
* lv2-invada-studio-plugins<br />
* lv2-ir<br />
* lv2-ll-plugins<br />
* lv2-so-404<br />
* lv2-so-666<br />
* lv2-so-kl5<br />
* lv2-swh-plugins<br />
* lv2-teliasopia<br />
* lv2-vocoder-plugins<br />
* lv2-vocproc<br />
* mammut<br />
* mcontrol<br />
* meterbridge<br />
* midicomp<br />
* mididings<br />
* midimon<br />
* midiosc<br />
* midirandomizer<br />
* midisend<br />
* milkytracker<br />
* mingus<br />
* minicomputer<br />
* mixxx1.9-bzr<br />
* mma<br />
* motiontrackosc<br />
* muse2-vst<br />
* music21<br />
* naspro-bridges-bad<br />
* naspro-core<br />
* nekobee<br />
* non-daw<br />
* nsound<br />
* nvidia-all<br />
* nvidia-daw<br />
* nvidia-rt<br />
* oggconvert<br />
* oscpack<br />
* paulstretch<br />
* pd<br />
* pd-arraysize<br />
* pd-boids<br />
* pd-bsaylor<br />
* pd-creb<br />
* pd-cyclone<br />
* pd-ekext<br />
* pd-ext13<br />
* pd-extended<br />
* pd-freeverb<br />
* pd-gem<br />
* pd-ggee<br />
* pd-gridflow<br />
* pd-hid<br />
* pd-jmmmp<br />
* pd-ladspa<br />
* pd-list-abs<br />
* pd-mapping<br />
* pd-motex<br />
* pd-pdogg<br />
* pd-pdp<br />
* pd-plugin<br />
* pd-pmpd<br />
* pd-purepd<br />
* pd-sigpack<br />
* pd-smlib<br />
* pd-vbap<br />
* pd-windowing<br />
* pd-zexy<br />
* perl-audio-flac-header<br />
* phasex<br />
* phasex-dev<br />
* phat<br />
* plotmm<br />
* pmidi<br />
* portaudio<br />
* praat<br />
* processing<br />
* pyaudio<br />
* pyduino-svn<br />
* pyfluidsynth<br />
* pygtk-1.2<br />
* pyjack<br />
* pylash<br />
* pymplayer<br />
* pyphat<br />
* python2-liblo<br />
* python2-portmidi<br />
* python2-pyo<br />
* python-audioprocessing<br />
* python-pyalsaaudio<br />
* qamix<br />
* qarecord<br />
* qloud<br />
* qmidiarp<br />
* qmidicontrol<br />
* qmidictl<br />
* qmidicurves<br />
* qmidiroute<br />
* qsampler<br />
* qtractor-vst<br />
* qutecsound<br />
* rakarrack<br />
* resample<br />
* rezound<br />
* rhost<br />
* rtirq<br />
* rt_pvc<br />
* rumor<br />
* samplecat<br />
* schismtracker<br />
* seq24<br />
* seq24-bzr<br />
* sfarkxtc<br />
* smasher<br />
* snack<br />
* sndfile-tools<br />
* snd-gtk-jack<br />
* sndlib<br />
* sndobj<br />
* sndpeek<br />
* sndpeek-jack<br />
* softwerk<br />
* sonic-visualiser<br />
* sooperlooper<br />
* soundfontcombi<br />
* soundfont-fluidr3<br />
* soundfont-personalcopy<br />
* soundfont-sgm180<br />
* soundfont-unison<br />
* soundtank<br />
* spatosc<br />
* spectmorph<br />
* spek<br />
* spiralsynthmodular<br />
* stretchplayer<br />
* supercollider<br />
* supercollider-with-extras<br />
* swami<br />
* swingosc<br />
* synthforge<br />
* synthofnoise<br />
* tapeutape<br />
* tapiir<br />
* tap-reverbed<br />
* timemachine<br />
* timidity-eawpatches<br />
* timidity-shominst<br />
* traverso<br />
* ttf-acoustica<br />
* ttf-concreta<br />
* ttf-controla<br />
* ttf-electronica<br />
* tuneit<br />
* tuxguitar-stable<br />
* twolame<br />
* ulatencyd<br />
* vamp-plugin-sdk<br />
* vamp-qm<br />
* vkeybd<br />
* vlevel<br />
* vmpk<br />
* waon<br />
* wavesurfer<br />
* whysynth<br />
* wildmidi<br />
* wineasio<br />
* xanalyser<br />
* xjadeo<br />
* xpmidi<br />
* xsynth-dssi<br />
* xwax-jack<br />
* yass<br />
* yoshimi<br />
* zita-at1<br />
* zita-convolver<br />
* zita-resample<br />
* zita-resampler<br />
* zita-rev1<br />
* zyn<br />
* zynaddsubfx<br />
* zynjacku<br />
<br />
==== Experimental Packages ====<br />
<br />
* a2jmidid-git<br />
* abjad-svn<br />
* alsa-lib-git<br />
* ams-cvs<br />
* ardour2-svn<br />
* arduide-git<br />
* athenacl-svn<br />
* audacity-cvs<br />
* calf-git<br />
* csound-cvs<br />
* cwiid-git<br />
* denemo-git<br />
* din-svn<br />
* eugene-svn<br />
* faust-git<br />
* flowcanvas-svn<br />
* fontforge-cvs<br />
* freebirth-svn<br />
* fst-git<br />
* galan-git<br />
* gigedit-cvs<br />
* guitarix-svn<br />
* hydrogen-svn<br />
* iannix-svn<br />
* inconcert-git<br />
* ingen-svn<br />
* inscore-bin<br />
* jack2-svn<br />
* jacker-hg<br />
* jacksampler-git<br />
* jack-svn<br />
* jlscp-cvs<br />
* jm2cv-git<br />
* jsampler-cvs<br />
* kernel26daw<br />
* kernel26icedrt<br />
* ladspa-njl-plugins-git<br />
* lash-git<br />
* libffado-svn<br />
* libgig-cvs<br />
* liblscp-cvs<br />
* lilypond-git<br />
* linuxsampler-cvs<br />
* lmms-git<br />
* lv2core-svn<br />
* lv2-fil-plugins-git<br />
* lv2-mda-svn<br />
* machina-svn<br />
* mingus-svn<br />
* musescore-svn<br />
* oscpack-svn<br />
* pd-extended-svn<br />
* pd-flext-svn<br />
* pd-gem-svn<br />
* pd-git<br />
* phasex-dev-git<br />
* phasex-git<br />
* portaudio-svn<br />
* pyfluidsynth-svn<br />
* python2-pyo-svn<br />
* qjackctl-svn<br />
* qmidiroute-cvs<br />
* qsampler-svn<br />
* qtractor-vst-svn<br />
* rakarrack-git<br />
* raul-svn<br />
* redlandmm-svn<br />
* scate-git<br />
* slv2-svn<br />
* sndobj-cvs<br />
* soundgrain<br />
* specimen-svn<br />
* speex-svn<br />
* supercollider-3.4-git<br />
* supercollider-with-extras-git<br />
* supercute-git<br />
* supercute-with-extras-git<br />
* traverso-git</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=130488Professional audio2011-02-11T15:46:55Z<p>Smoge: /* Packages */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. Go ahead and check it out!<br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
<br />
----<br />
<br />
<br />
=== Packages ===<br />
<br />
Our Packages as of UTC Fri Fev 11 15:46:02 UTC 2011<br />
<br />
==== Stable Packages ====<br />
<br />
* archaudio-devtools<br />
* ardour<br />
* ardourvst<br />
* cwiid<br />
* jack<br />
* kernel26rt<br />
* kernel26rtpae<br />
* nvidia-rt<br />
* nvidia-rtpae<br />
<br />
==== Testing Packages ====<br />
<br />
* a2jmidid<br />
* abjad<br />
* addinclude<br />
* adlmidi<br />
* aeolus<br />
* afsp<br />
* aj-snapshot<br />
* algoscore<br />
* aliki<br />
* alsaequal<br />
* alsa-firmware<br />
* alsa-lib<br />
* alsa-plugins<br />
* alsa-tools<br />
* alsa-tools-emu10k1<br />
* alsa-tools-emu10k1-gui<br />
* alsa-tools-ice1712<br />
* ambdec<br />
* ams<br />
* amsynth<br />
* arduino<br />
* arduino-0021<br />
* argtable<br />
* arss<br />
* athenacl<br />
* aubio<br />
* audio-combine<br />
* audioconvert<br />
* audio-convert-mod<br />
* audiotools<br />
* azr3-jack<br />
* baudline<br />
* beast<br />
* bigband<br />
* bitmeter<br />
* bml<br />
* bristol<br />
* brutefir<br />
* bse-alsa<br />
* bsl<br />
* buzztard<br />
* calf<br />
* cd<br />
* cecilia2<br />
* cecilia4<br />
* ceres<br />
* ceres3<br />
* cheesetracker<br />
* chino<br />
* clalsadrv<br />
* clalsadrv-apps<br />
* clthreads<br />
* clxclient<br />
* cm-grace-bin<br />
* connie<br />
* csound<br />
* csound-cecilia<br />
* csound-doc<br />
* demolition<br />
* din<br />
* dino<br />
* dirogg<br />
* dssi-fluidsynth<br />
* dssi-hexter<br />
* dssi-ll-scope<br />
* dssi-nekobee<br />
* dssi-vst<br />
* eko<br />
* esjit<br />
* fastbreeder<br />
* faust<br />
* fftw2-threads<br />
* fftw-threads<br />
* fms<br />
* fomus<br />
* foo-yc20<br />
* freebirth<br />
* freeverb3<br />
* freewheeling<br />
* freqtweak<br />
* frescobaldi<br />
* frescobaldi-devel<br />
* galan<br />
* ghostess<br />
* glame<br />
* gluid<br />
* gmidimonitor<br />
* gst123<br />
* gst-buzztard<br />
* gtklick<br />
* guido<br />
* guitarix<br />
* gwc<br />
* gx_head<br />
* iannix<br />
* ir-true-m7<br />
* jaaa<br />
* jack2<br />
* jackbeat<br />
* jack_capture<br />
* jackctl<br />
* jack-delay<br />
* jackeq<br />
* jacker<br />
* jack-keyboard<br />
* jackmeter<br />
* jackminimix<br />
* jack-mixer<br />
* jack_oscrolloscope<br />
* jack-rack<br />
* jacksampler<br />
* jack_snapshot<br />
* jamin<br />
* japa<br />
* jcgui<br />
* jconvolver<br />
* jkmeter<br />
* jmeters<br />
* jnoise<br />
* jost<br />
* jost-bin<br />
* jpmidi<br />
* juce<br />
* kernel26rt<br />
* kernel26rtpae<br />
* klick<br />
* kmidimon<br />
* kwave<br />
* ladish<br />
* laditools<br />
* ladspa-amb-plugins<br />
* ladspa-autotalent-plugins<br />
* ladspa-blepvco-plugins<br />
* ladspa-blop-plugins<br />
* ladspa-bs2b<br />
* ladspa-caps-plugins<br />
* ladspa-cmt-plugins<br />
* ladspa-fil-plugins<br />
* ladspa-invada-studio-plugins<br />
* ladspa-mcp-plugins<br />
* ladspa-njl-plugins<br />
* ladspa-nlfilter<br />
* ladspa-rev-plugins<br />
* ladspa-swh-plugins<br />
* ladspa-tap-plugins<br />
* ladspa-vcf<br />
* ladspa-vco-plugins<br />
* ladspa-wah-plugins<br />
* lash<br />
* lemma<br />
* lib32-libusb<br />
* lib32-libusb-compat<br />
* libbs2b<br />
* libffado<br />
* libfishsound<br />
* libglade-old<br />
* libinstpatch<br />
* libircclient<br />
* liblscp<br />
* libmpeg3<br />
* librxtx-arduino<br />
* libsigc++1.2<br />
* libsmf<br />
* libtimidity<br />
* libunicap<br />
* libxml<br />
* lilypond-devel<br />
* linuxdsp-jackgtk<br />
* linuxvst-miscellaneous<br />
* luaposix<br />
* lv2-aubio<br />
* lv2-autotalent<br />
* lv2-c++-tools<br />
* lv2-deathcrush<br />
* lv2dynparam1<br />
* lv2-eq10q-plugins<br />
* lv2file<br />
* lv2-fil-plugins<br />
* lv2-invada-studio-plugins<br />
* lv2-ir<br />
* lv2-ll-plugins<br />
* lv2-so-404<br />
* lv2-so-666<br />
* lv2-so-kl5<br />
* lv2-swh-plugins<br />
* lv2-teliasopia<br />
* lv2-vocoder-plugins<br />
* lv2-vocproc<br />
* mammut<br />
* mcontrol<br />
* meterbridge<br />
* midicomp<br />
* mididings<br />
* midimon<br />
* midiosc<br />
* midirandomizer<br />
* midisend<br />
* milkytracker<br />
* mingus<br />
* minicomputer<br />
* mixxx1.9-bzr<br />
* mma<br />
* motiontrackosc<br />
* muse2-vst<br />
* music21<br />
* naspro-bridges-bad<br />
* naspro-core<br />
* nekobee<br />
* non-daw<br />
* nsound<br />
* nvidia-all<br />
* nvidia-daw<br />
* nvidia-rt<br />
* oggconvert<br />
* oscpack<br />
* paulstretch<br />
* pd<br />
* pd-arraysize<br />
* pd-boids<br />
* pd-bsaylor<br />
* pd-creb<br />
* pd-cyclone<br />
* pd-ekext<br />
* pd-ext13<br />
* pd-extended<br />
* pd-freeverb<br />
* pd-gem<br />
* pd-ggee<br />
* pd-gridflow<br />
* pd-hid<br />
* pd-jmmmp<br />
* pd-ladspa<br />
* pd-list-abs<br />
* pd-mapping<br />
* pd-motex<br />
* pd-pdogg<br />
* pd-pdp<br />
* pd-plugin<br />
* pd-pmpd<br />
* pd-purepd<br />
* pd-sigpack<br />
* pd-smlib<br />
* pd-vbap<br />
* pd-windowing<br />
* pd-zexy<br />
* perl-audio-flac-header<br />
* phasex<br />
* phasex-dev<br />
* phat<br />
* plotmm<br />
* pmidi<br />
* portaudio<br />
* praat<br />
* processing<br />
* pyaudio<br />
* pyduino-svn<br />
* pyfluidsynth<br />
* pygtk-1.2<br />
* pyjack<br />
* pylash<br />
* pymplayer<br />
* pyphat<br />
* python2-liblo<br />
* python2-portmidi<br />
* python2-pyo<br />
* python-audioprocessing<br />
* python-pyalsaaudio<br />
* qamix<br />
* qarecord<br />
* qloud<br />
* qmidiarp<br />
* qmidicontrol<br />
* qmidictl<br />
* qmidicurves<br />
* qmidiroute<br />
* qsampler<br />
* qtractor-vst<br />
* qutecsound<br />
* rakarrack<br />
* resample<br />
* rezound<br />
* rhost<br />
* rtirq<br />
* rt_pvc<br />
* rumor<br />
* samplecat<br />
* schismtracker<br />
* seq24<br />
* seq24-bzr<br />
* sfarkxtc<br />
* smasher<br />
* snack<br />
* sndfile-tools<br />
* snd-gtk-jack<br />
* sndlib<br />
* sndobj<br />
* sndpeek<br />
* sndpeek-jack<br />
* softwerk<br />
* sonic-visualiser<br />
* sooperlooper<br />
* soundfontcombi<br />
* soundfont-fluidr3<br />
* soundfont-personalcopy<br />
* soundfont-sgm180<br />
* soundfont-unison<br />
* soundtank<br />
* spatosc<br />
* spectmorph<br />
* spek<br />
* spiralsynthmodular<br />
* stretchplayer<br />
* supercollider<br />
* supercollider-with-extras<br />
* swami<br />
* swingosc<br />
* synthforge<br />
* synthofnoise<br />
* tapeutape<br />
* tapiir<br />
* tap-reverbed<br />
* timemachine<br />
* timidity-eawpatches<br />
* timidity-shominst<br />
* traverso<br />
* ttf-acoustica<br />
* ttf-concreta<br />
* ttf-controla<br />
* ttf-electronica<br />
* tuneit<br />
* tuxguitar-stable<br />
* twolame<br />
* ulatencyd<br />
* vamp-plugin-sdk<br />
* vamp-qm<br />
* vkeybd<br />
* vlevel<br />
* vmpk<br />
* waon<br />
* wavesurfer<br />
* whysynth<br />
* wildmidi<br />
* wineasio<br />
* xanalyser<br />
* xjadeo<br />
* xpmidi<br />
* xsynth-dssi<br />
* xwax-jack<br />
* yass<br />
* yoshimi<br />
* zita-at1<br />
* zita-convolver<br />
* zita-resample<br />
* zita-resampler<br />
* zita-rev1<br />
* zyn<br />
* zynaddsubfx<br />
* zynjacku<br />
<br />
==== Experimental Packages ====<br />
<br />
* a2jmidid-git<br />
* abjad-svn<br />
* alsa-lib-git<br />
* ams-cvs<br />
* ardour2-svn<br />
* arduide-git<br />
* athenacl-svn<br />
* audacity-cvs<br />
* calf-git<br />
* csound-cvs<br />
* cwiid-git<br />
* denemo-git<br />
* din-svn<br />
* eugene-svn<br />
* faust-git<br />
* flowcanvas-svn<br />
* fontforge-cvs<br />
* freebirth-svn<br />
* fst-git<br />
* galan-git<br />
* gigedit-cvs<br />
* guitarix-svn<br />
* hydrogen-svn<br />
* iannix-svn<br />
* inconcert-git<br />
* ingen-svn<br />
* inscore-bin<br />
* jack2-svn<br />
* jacker-hg<br />
* jacksampler-git<br />
* jack-svn<br />
* jlscp-cvs<br />
* jm2cv-git<br />
* jsampler-cvs<br />
* kernel26daw<br />
* kernel26icedrt<br />
* ladspa-njl-plugins-git<br />
* lash-git<br />
* libffado-svn<br />
* libgig-cvs<br />
* liblscp-cvs<br />
* lilypond-git<br />
* linuxsampler-cvs<br />
* lmms-git<br />
* lv2core-svn<br />
* lv2-fil-plugins-git<br />
* lv2-mda-svn<br />
* machina-svn<br />
* mingus-svn<br />
* musescore-svn<br />
* oscpack-svn<br />
* pd-extended-svn<br />
* pd-flext-svn<br />
* pd-gem-svn<br />
* pd-git<br />
* phasex-dev-git<br />
* phasex-git<br />
* portaudio-svn<br />
* pyfluidsynth-svn<br />
* python2-pyo-svn<br />
* qjackctl-svn<br />
* qmidiroute-cvs<br />
* qsampler-svn<br />
* qtractor-vst-svn<br />
* rakarrack-git<br />
* raul-svn<br />
* redlandmm-svn<br />
* scate-git<br />
* slv2-svn<br />
* sndobj-cvs<br />
* soundgrain<br />
* specimen-svn<br />
* speex-svn<br />
* supercollider-3.4-git<br />
* supercollider-with-extras-git<br />
* supercute-git<br />
* supercute-with-extras-git<br />
* traverso-git</div>Smogehttps://wiki.archlinux.org/index.php?title=Professional_audio&diff=130487Professional audio2011-02-11T15:46:30Z<p>Smoge: /* = Packages */</p>
<hr />
<div>[[Category:Audio/Video (English)]]<br />
== Introduction ==<br />
<br />
Modern Linux systems are more than capable of supporting your<br />
(semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can<br />
be achieved with good hardware and proper configuration. You could even run an<br />
industrial laser alongside your ''DAW''.<br />
<br />
We believe Arch Linux provides competent users the right "framework" to sculpt<br />
their very own dedicated machines for recording, mixing, mastering,<br />
sound-design, DSP programming, and what have you. More often than not, when a<br />
"linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown<br />
what has led to such fallacious thinking, but needless to say, "compiling",<br />
"learning" and "performance" have as much to do with each other as "differences<br />
in rendering quality between Cubase and Pro Tools".<br />
<br />
=== Pro Audio on Arch Linux ===<br />
<br />
* '''Binary-based'''<br />
<br />
Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time/CPU cycles, you just work''(tm)''. This leads to "Third-party Repositores" below.<br />
<br />
* '''KISS'''<br />
<br />
The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.<br />
<br />
* '''Rolling-release'''<br />
<br />
Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.<br />
<br />
* '''Pragmatic'''<br />
<br />
Arch is agnostic with regards to licenses of software - it includes packages in the official repositories which "taint" the freedom of a distribution, but otherwise are popular and/or useful. This is also possible because Arch is not a complete "distribution", i.e releases are in fact only snapshots of the system with ''base packages only''. License information is clearly available with every package without the need for installation, so it is up to the user to decide what he installs.<br />
<br />
* '''ABS'''<br />
<br />
Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.<br />
<br />
* '''AUR'''<br />
<br />
Arch has an "unsupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.<br />
<br />
* '''Third-party Repositories'''<br />
<br />
Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository. We can afford to skip ''PEBKAC safeguards'', because we expect users to know what they are doing. This means deciding on whether using a particular binary repository is "safe". For third-party Arch Linux binaries of audio software, we have [[Pro Audio#Arch Linux Pro Audio Project|this]].<br />
<br />
* '''BSD-style init'''<br />
<br />
Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a ''DAW'', the last thing a power-user wants is a complex underlying administration framework.<br />
<br />
'''Q: So should I use Arch Linux (as my DAW)? I have been using Distro X so far..'''<br />
<br />
A: If such is your question, we are sorry to inform you that the answer is negative.<br />
<br />
''"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers''<br />
<br />
== Getting Started ==<br />
<br />
Some of the major pro audio applications are already available from the official and community Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.<br />
<br />
For a quick start:<br />
<br />
~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth lmms ladspa-plugins dssi-vst<br />
<br />
Other packages you may need and are available elsewhere:<br />
<br />
* JACK2<br />
* Traverso<br />
* [[Linuxsampler|LinuxSampler]]; JSampler; Qsampler<br />
* FST-GIT<br />
* JOST<br />
* WineASIO<br />
<br />
=== System Configuration ===<br />
<br />
* Have I set up sound properly? See [[ALSA]].<br />
<br />
~$ speaker-test<br />
<br />
* Am I in the audio group? See [[ALSA]].<br />
<br />
~$ groups | grep audio<br />
<br />
* Have I edited system limits?<br />
<br />
# /etc/security/limits.conf<br />
...<br />
@audio - rtprio 99 # sane number is 65; up to 99<br />
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)<br />
<br />
* Is PulseAudio, OSS or something else grabbing my device? (Phonon does not but you may want to install '''phonon-xine''')<br />
<br />
~$ lsof +c 0 /dev/snd/pcm*<br />
~$ lsof +c 0 /dev/dsp<br />
<br />
* Is PAM-security and realtime working OK?<br />
<br />
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)<br />
<br />
* Have I rebooted after having done all that?<br />
<br />
=== JACK ===<br />
<br />
The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a '''period of 3''' is always a must. Also, the sample rate must match the hardware sample rate. Most often, '''48000Hz''' is the common default across many of today's devices. A '''buffer of 256''' is a sane starter. Almost always, when recording or sequencing with external gear is concerned, '''realtime''' is a must. Also, you may like to set maximum priority (at least 10 lower than system limits; the highest is for the device itself).<br />
<br />
~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3<br />
<br />
''QJackCtl'' and ''Patchage'' are two GUI front-ends.<br />
<br />
And to check what sample and bit rates your device supports (for what samplerate it is set to, you have to look up the device manual or the knobs/switches/buttons on it):<br />
<br />
~$ cat /proc/asound/card0/codec#0<br />
<br />
Replace ''card0'' and ''codec#0'' depending on what you have. You will be looking for '''rates''' or ''VRA'' in '''Extended ID'''.<br />
<br />
''Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf''<br />
<br />
==== FireWire ====<br />
JACK is now built against FFADO (currently in [testing]):<br />
<br />
~# pacman -S jack libffado<br />
<br />
To test whether you have any chances of getting FireWire devices to work:<br />
<br />
* Ensure the proper kernel modules are loaded:<br />
<br />
~# modprobe firewire-core firewire-ohci<br />
<br />
* For the old stack (eg. custom kernels; Arch has only the new stack):<br />
<br />
~# modprobe ieee1394 raw1394<br />
<br />
* Am I in the video group?<br />
<br />
~$ groups | grep video<br />
<br />
Or whichever group has access to '''/dev/fw1''' ('''/dev/raw1394''' in old stack):<br />
<br />
~$ ls -l /dev/fw1 | awk '{print $4}'<br />
<br />
You can also ammend the permissions for your needs (for new stack see [https://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Character_device_files.2C_block_device_files upstream documentation]):<br />
<br />
~# chmod 666 /dev/fw1<br />
<br />
* Is my chipset sane enough to initiate a device?<br />
<br />
http://www.ffado.org/?q=node/622<br />
<br />
* Is my chipset sane enough to make a device work to its capacity?<br />
<br />
We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.<br />
<br />
<br />
==== Jack Flash ====<br />
<br />
If after getting jack setup you will find that Flash has no audio.<br />
<br />
In order to get flash to work with jack you will need to install libflashsupport-jack from the aur repositorys.<br />
<br />
http://aur.archlinux.org/packages.php?ID=26219<br />
<br />
==== Quickscan Jack script ====<br />
<br />
Most people will probably want to run jack in realtime mode, there are however a lot of nobs and buttons to press in order for that to happen.<br />
<br />
A great way to quickly diagnose your system and find out what it is missing in order to have jack work properly in real time mode is to run the Quickscan script. <br />
<br />
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl<br />
<br />
The output should tell you where your system is lacking and will point you to places to find more information.<br />
<br />
== Realtime Kernel ==<br />
<br />
Since a while ago, the stock Linux kernel has proven to be adequate for realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch) can operate with a worst case latency of [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F upto 10ms] (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running), although some device drivers can introduce latency much worse than that. So depending on your hardware and driver (and requirement), you might want a kernel with hard realtime capabilities.<br />
<br />
The [https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO RT_PREEPMT] patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. <br />
Most audio-specific distro Linux ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.<br />
<br />
If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in '''1995'''. <br />
<br />
In any way, you should also ensure that:<br />
* '''Timer Frequency''' is set to '''1000Hz''' (CONFIG_HZ_1000=y; if you do not do ''MIDI'' you can ignore this)<br />
* '''APM''' is '''DISABLED''' (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)<br />
<br />
If you truly want a slim system, we suggest you go your own way and deploy one with ''static /devs''. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.<br />
<br />
General issue(s) with (realtime) kernels:<br />
<br />
* Hyperthreading (if you suspect, disable in BIOS)<br />
<br />
There are ready-to-run/compile patched kernels available in the ABS and AUR.<br />
<br />
=== ABS ===<br />
<br />
You can run '''abs''' (install it first), and recompile ''kernel26'' with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".<br />
<br />
=== AUR ===<br />
<br />
From the AUR itself, you have two options:<br />
<br />
* kernel26rt<br />
* kernel26-rt-ice<br />
<br />
The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.<br />
<br />
== Environment Variables ==<br />
<br />
If you install things to non-standard directories, it is often necessary to set environment path variables so that applications know where to look (for plug-ins and other libraries). This usually affects only VST since users might have a Wine or external Windows location.<br />
<br />
We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond standard paths, so it is not necessary to export them. But if you do, be sure to include those standard paths as well since Arch does not do anything for ''dssi'' or ''ladspa'', and some applications like ''dssi-vst'' will not look anywhere else if it finds predefined paths.<br />
<br />
# ~/.bashrc<br />
...<br />
export VST_PATH=/usr/lib/vst:/usr/local/lib/vst:~/.vst:/someother/custom/dir<br />
export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa:/someother/custom/dir<br />
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2:/someother/custom/dir<br />
export DSSI_PATH=/usr/lib/dssi:/usr/local/lib/dssi:~/.dssi:/someother/custom/dir<br />
<br />
== Tricks and Tips ==<br />
<br />
* IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at [http://subversion.ffado.org/wiki/IrqPriorities FFADO IRQ Priorities How-To]. If you have a RT_PREEMPT patched kernel, you can use this helpful script [http://alsa.opensrc.org/Rtirq rtirq] to adjust priorities of IRQ handling threads.<br />
<br />
* Do not use the irqbalance daemon, or do so carefully [http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_Process_Binding.html].<br />
<br />
* Some daemons/processes can unexpectedly cause '''xruns'''. If you do not need it - kill it. No questions asked.<br />
<br />
~$ ls /var/run/daemons<br />
~$ top # or htop, ps aux, whatever you are comfortable with<br />
~$ killall -9 $processname<br />
~# /etc/rc.d/$daemonname stop<br />
<br />
* If you are facing a lot of ''xruns'' especially with '''nvidia''', disable your GPU throttling. This can be done via the card's control applet and for nvidia it is "prefer maximum performance" (thanks to a mail in LAU by Frank Kober).<br />
<br />
== Hardware ==<br />
=== M-Audio Delta 1010 ===<br />
<br />
This hardware requires that you install the alsa-tools package from the AUR,<br />
because it contains the envy24control program. Envy24control is a hardware level<br />
mixer/controller. You ''can'' use alsa-mixer but you will save yourself some<br />
hassle not to try it. Note that this section has no information on MIDI setup or<br />
usage. <br />
<br />
Open the mixer application:<br />
*$envy24control<br />
<br />
This application can be more then a bit confusing, and I am yet to find a<br />
reasonable tutorial for its use. That said, here is a working setup for<br />
multitracking with Ardour.<br />
<br />
#Set all monitor inputs and monitor PCM's to around 20.<br />
#Patchbay/router tab: Set all to PCM out.<br />
#Hardware Settings: Verify that the Master Clock setting matches what is set in<br />
Qjackctl. If these do not match you will have xruns out of control!<br />
<br />
=== PreSonus Firepod ===<br />
<br />
#Startup: Either from commandline or QjackCtl, the driver is called firewire.<br />
#Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10<br />
channels.<br />
#Linking: Cards can be linked together without any problems.<br />
#Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your<br />
likings.<br />
<br />
Volume levels are hardware and routing can be done through QjackCtl, even with<br />
more cards linked together, this is not a problem.<br />
The ffadomixer does not work with this card yet, hopefully in the future we can<br />
control more aspects of the card through a software interface like that.<br />
<br />
== Restricted Software ==<br />
=== Steinberg's SDKs ===<br />
<br />
It is very clear - we can distribute neither the VST nor the ASIO headers in '''binary package form'''. However, whenever you are building a program which would host Windows ''.dll'' VST plug-ins, check for the following hints (that do not require use of any SDK):<br />
<br />
* dssi-vst<br />
* fst<br />
* vestige<br />
<br />
With that said, if you are building a program which would host native ''.so'' VST plug-ins, then there is no escape. For such cases, Arch yet again allows us to maintain a uniform local software database. We can "install" the SDK ''system-wide'' - you simply have to download it yourself and place it in the packaging directory.<br />
<br />
[http://aur.archlinux.org/packages.php?O=0&K=steinberg-&do_Search=Go Get them from AUR]<br />
<br />
''Note: Steinberg does not forbid redistribution of resulting products, nor dictate what license they can be under. There are many GPL-licensed VST plug-ins. As such, distributing binary packages of software built with these restricted headers is '''not''' a problem, because the headers are simply '''buildtime dependencies'''.''<br />
<br />
== Arch Linux Pro Audio Project ==<br />
<br />
Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less the academic connotations of the former: [http://archaudio.org ArchAudio]. <br />
<br />
What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.<br />
<br />
It is a relatively new effort although the initiative has been around since<br />
2006/2007. <br />
<br />
History: http://bbs.archlinux.org/viewtopic.php?id=30547<br />
<br />
Update: In end of 2010 / early 2011 we received an major increase in human resources and motivation that resulted in more than 400 new packages currently being tested. Please check our [testing] repository. Go ahead and check it out!<br />
<br />
Currently, they have the following kernels:<br />
<br />
* '''kernel26rt'''<br />
<br />
The "standard" realtime kernel.<br />
<br />
* '''kernel26daw'''<br />
<br />
BFS-patched kernel for low-latency work.<br />
<br />
All kernels (will) have their respective PAE, testing and x86_64 versions.<br />
<br />
They also have variations of the ''jack-audio-connection-kit'' packages:<br />
<br />
* '''jack'''<br />
<br />
The standard JACK, plus features and support not provided by the one in [extra].<br />
<br />
* '''jack2'''<br />
<br />
The next-generation JACK.<br />
<br />
''SVN'' / ''GIT'' / ''HG'' (development) versions of most packages are available too in our [experimental] repository.<br />
<br />
'''IRC:''' #archaudio @ Freenode<br />
<br />
=== Packages ===<br />
<br />
Our Packages as of UTC Fri Fev 11 15:46:02 UTC 2011<br />
<br />
<br />
==== Stable Packages ====<br />
<br />
* archaudio-devtools<br />
* ardour<br />
* ardourvst<br />
* cwiid<br />
* jack<br />
* kernel26rt<br />
* kernel26rtpae<br />
* nvidia-rt<br />
* nvidia-rtpae<br />
<br />
==== Testing Packages ====<br />
<br />
* a2jmidid<br />
* abjad<br />
* addinclude<br />
* adlmidi<br />
* aeolus<br />
* afsp<br />
* aj-snapshot<br />
* algoscore<br />
* aliki<br />
* alsaequal<br />
* alsa-firmware<br />
* alsa-lib<br />
* alsa-plugins<br />
* alsa-tools<br />
* alsa-tools-emu10k1<br />
* alsa-tools-emu10k1-gui<br />
* alsa-tools-ice1712<br />
* ambdec<br />
* ams<br />
* amsynth<br />
* arduino<br />
* arduino-0021<br />
* argtable<br />
* arss<br />
* athenacl<br />
* aubio<br />
* audio-combine<br />
* audioconvert<br />
* audio-convert-mod<br />
* audiotools<br />
* azr3-jack<br />
* baudline<br />
* beast<br />
* bigband<br />
* bitmeter<br />
* bml<br />
* bristol<br />
* brutefir<br />
* bse-alsa<br />
* bsl<br />
* buzztard<br />
* calf<br />
* cd<br />
* cecilia2<br />
* cecilia4<br />
* ceres<br />
* ceres3<br />
* cheesetracker<br />
* chino<br />
* clalsadrv<br />
* clalsadrv-apps<br />
* clthreads<br />
* clxclient<br />
* cm-grace-bin<br />
* connie<br />
* csound<br />
* csound-cecilia<br />
* csound-doc<br />
* demolition<br />
* din<br />
* dino<br />
* dirogg<br />
* dssi-fluidsynth<br />
* dssi-hexter<br />
* dssi-ll-scope<br />
* dssi-nekobee<br />
* dssi-vst<br />
* eko<br />
* esjit<br />
* fastbreeder<br />
* faust<br />
* fftw2-threads<br />
* fftw-threads<br />
* fms<br />
* fomus<br />
* foo-yc20<br />
* freebirth<br />
* freeverb3<br />
* freewheeling<br />
* freqtweak<br />
* frescobaldi<br />
* frescobaldi-devel<br />
* galan<br />
* ghostess<br />
* glame<br />
* gluid<br />
* gmidimonitor<br />
* gst123<br />
* gst-buzztard<br />
* gtklick<br />
* guido<br />
* guitarix<br />
* gwc<br />
* gx_head<br />
* iannix<br />
* ir-true-m7<br />
* jaaa<br />
* jack2<br />
* jackbeat<br />
* jack_capture<br />
* jackctl<br />
* jack-delay<br />
* jackeq<br />
* jacker<br />
* jack-keyboard<br />
* jackmeter<br />
* jackminimix<br />
* jack-mixer<br />
* jack_oscrolloscope<br />
* jack-rack<br />
* jacksampler<br />
* jack_snapshot<br />
* jamin<br />
* japa<br />
* jcgui<br />
* jconvolver<br />
* jkmeter<br />
* jmeters<br />
* jnoise<br />
* jost<br />
* jost-bin<br />
* jpmidi<br />
* juce<br />
* kernel26rt<br />
* kernel26rtpae<br />
* klick<br />
* kmidimon<br />
* kwave<br />
* ladish<br />
* laditools<br />
* ladspa-amb-plugins<br />
* ladspa-autotalent-plugins<br />
* ladspa-blepvco-plugins<br />
* ladspa-blop-plugins<br />
* ladspa-bs2b<br />
* ladspa-caps-plugins<br />
* ladspa-cmt-plugins<br />
* ladspa-fil-plugins<br />
* ladspa-invada-studio-plugins<br />
* ladspa-mcp-plugins<br />
* ladspa-njl-plugins<br />
* ladspa-nlfilter<br />
* ladspa-rev-plugins<br />
* ladspa-swh-plugins<br />
* ladspa-tap-plugins<br />
* ladspa-vcf<br />
* ladspa-vco-plugins<br />
* ladspa-wah-plugins<br />
* lash<br />
* lemma<br />
* lib32-libusb<br />
* lib32-libusb-compat<br />
* libbs2b<br />
* libffado<br />
* libfishsound<br />
* libglade-old<br />
* libinstpatch<br />
* libircclient<br />
* liblscp<br />
* libmpeg3<br />
* librxtx-arduino<br />
* libsigc++1.2<br />
* libsmf<br />
* libtimidity<br />
* libunicap<br />
* libxml<br />
* lilypond-devel<br />
* linuxdsp-jackgtk<br />
* linuxvst-miscellaneous<br />
* luaposix<br />
* lv2-aubio<br />
* lv2-autotalent<br />
* lv2-c++-tools<br />
* lv2-deathcrush<br />
* lv2dynparam1<br />
* lv2-eq10q-plugins<br />
* lv2file<br />
* lv2-fil-plugins<br />
* lv2-invada-studio-plugins<br />
* lv2-ir<br />
* lv2-ll-plugins<br />
* lv2-so-404<br />
* lv2-so-666<br />
* lv2-so-kl5<br />
* lv2-swh-plugins<br />
* lv2-teliasopia<br />
* lv2-vocoder-plugins<br />
* lv2-vocproc<br />
* mammut<br />
* mcontrol<br />
* meterbridge<br />
* midicomp<br />
* mididings<br />
* midimon<br />
* midiosc<br />
* midirandomizer<br />
* midisend<br />
* milkytracker<br />
* mingus<br />
* minicomputer<br />
* mixxx1.9-bzr<br />
* mma<br />
* motiontrackosc<br />
* muse2-vst<br />
* music21<br />
* naspro-bridges-bad<br />
* naspro-core<br />
* nekobee<br />
* non-daw<br />
* nsound<br />
* nvidia-all<br />
* nvidia-daw<br />
* nvidia-rt<br />
* oggconvert<br />
* oscpack<br />
* paulstretch<br />
* pd<br />
* pd-arraysize<br />
* pd-boids<br />
* pd-bsaylor<br />
* pd-creb<br />
* pd-cyclone<br />
* pd-ekext<br />
* pd-ext13<br />
* pd-extended<br />
* pd-freeverb<br />
* pd-gem<br />
* pd-ggee<br />
* pd-gridflow<br />
* pd-hid<br />
* pd-jmmmp<br />
* pd-ladspa<br />
* pd-list-abs<br />
* pd-mapping<br />
* pd-motex<br />
* pd-pdogg<br />
* pd-pdp<br />
* pd-plugin<br />
* pd-pmpd<br />
* pd-purepd<br />
* pd-sigpack<br />
* pd-smlib<br />
* pd-vbap<br />
* pd-windowing<br />
* pd-zexy<br />
* perl-audio-flac-header<br />
* phasex<br />
* phasex-dev<br />
* phat<br />
* plotmm<br />
* pmidi<br />
* portaudio<br />
* praat<br />
* processing<br />
* pyaudio<br />
* pyduino-svn<br />
* pyfluidsynth<br />
* pygtk-1.2<br />
* pyjack<br />
* pylash<br />
* pymplayer<br />
* pyphat<br />
* python2-liblo<br />
* python2-portmidi<br />
* python2-pyo<br />
* python-audioprocessing<br />
* python-pyalsaaudio<br />
* qamix<br />
* qarecord<br />
* qloud<br />
* qmidiarp<br />
* qmidicontrol<br />
* qmidictl<br />
* qmidicurves<br />
* qmidiroute<br />
* qsampler<br />
* qtractor-vst<br />
* qutecsound<br />
* rakarrack<br />
* resample<br />
* rezound<br />
* rhost<br />
* rtirq<br />
* rt_pvc<br />
* rumor<br />
* samplecat<br />
* schismtracker<br />
* seq24<br />
* seq24-bzr<br />
* sfarkxtc<br />
* smasher<br />
* snack<br />
* sndfile-tools<br />
* snd-gtk-jack<br />
* sndlib<br />
* sndobj<br />
* sndpeek<br />
* sndpeek-jack<br />
* softwerk<br />
* sonic-visualiser<br />
* sooperlooper<br />
* soundfontcombi<br />
* soundfont-fluidr3<br />
* soundfont-personalcopy<br />
* soundfont-sgm180<br />
* soundfont-unison<br />
* soundtank<br />
* spatosc<br />
* spectmorph<br />
* spek<br />
* spiralsynthmodular<br />
* stretchplayer<br />
* supercollider<br />
* supercollider-with-extras<br />
* swami<br />
* swingosc<br />
* synthforge<br />
* synthofnoise<br />
* tapeutape<br />
* tapiir<br />
* tap-reverbed<br />
* timemachine<br />
* timidity-eawpatches<br />
* timidity-shominst<br />
* traverso<br />
* ttf-acoustica<br />
* ttf-concreta<br />
* ttf-controla<br />
* ttf-electronica<br />
* tuneit<br />
* tuxguitar-stable<br />
* twolame<br />
* ulatencyd<br />
* vamp-plugin-sdk<br />
* vamp-qm<br />
* vkeybd<br />
* vlevel<br />
* vmpk<br />
* waon<br />
* wavesurfer<br />
* whysynth<br />
* wildmidi<br />
* wineasio<br />
* xanalyser<br />
* xjadeo<br />
* xpmidi<br />
* xsynth-dssi<br />
* xwax-jack<br />
* yass<br />
* yoshimi<br />
* zita-at1<br />
* zita-convolver<br />
* zita-resample<br />
* zita-resampler<br />
* zita-rev1<br />
* zyn<br />
* zynaddsubfx<br />
* zynjacku<br />
<br />
==== Experimental Packages ====<br />
<br />
* a2jmidid-git<br />
* abjad-svn<br />
* alsa-lib-git<br />
* ams-cvs<br />
* ardour2-svn<br />
* arduide-git<br />
* athenacl-svn<br />
* audacity-cvs<br />
* calf-git<br />
* csound-cvs<br />
* cwiid-git<br />
* denemo-git<br />
* din-svn<br />
* eugene-svn<br />
* faust-git<br />
* flowcanvas-svn<br />
* fontforge-cvs<br />
* freebirth-svn<br />
* fst-git<br />
* galan-git<br />
* gigedit-cvs<br />
* guitarix-svn<br />
* hydrogen-svn<br />
* iannix-svn<br />
* inconcert-git<br />
* ingen-svn<br />
* inscore-bin<br />
* jack2-svn<br />
* jacker-hg<br />
* jacksampler-git<br />
* jack-svn<br />
* jlscp-cvs<br />
* jm2cv-git<br />
* jsampler-cvs<br />
* kernel26daw<br />
* kernel26icedrt<br />
* ladspa-njl-plugins-git<br />
* lash-git<br />
* libffado-svn<br />
* libgig-cvs<br />
* liblscp-cvs<br />
* lilypond-git<br />
* linuxsampler-cvs<br />
* lmms-git<br />
* lv2core-svn<br />
* lv2-fil-plugins-git<br />
* lv2-mda-svn<br />
* machina-svn<br />
* mingus-svn<br />
* musescore-svn<br />
* oscpack-svn<br />
* pd-extended-svn<br />
* pd-flext-svn<br />
* pd-gem-svn<br />
* pd-git<br />
* phasex-dev-git<br />
* phasex-git<br />
* portaudio-svn<br />
* pyfluidsynth-svn<br />
* python2-pyo-svn<br />
* qjackctl-svn<br />
* qmidiroute-cvs<br />
* qsampler-svn<br />
* qtractor-vst-svn<br />
* rakarrack-git<br />
* raul-svn<br />
* redlandmm-svn<br />
* scate-git<br />
* slv2-svn<br />
* sndobj-cvs<br />
* soundgrain<br />
* specimen-svn<br />
* speex-svn<br />
* supercollider-3.4-git<br />
* supercollider-with-extras-git<br />
* supercute-git<br />
* supercute-with-extras-git<br />
* traverso-git</div>Smoge