Linux is a great OS for MIDI. The problem is that you’ve got to understand a lot about Linux to get started. This guide is intended to help ease the transition. This document has been tested with Ubuntu 14.10.
This is a very command-line-intensive tutorial. The reason for this is that it reduces the amount of software that is running which has two advantages: performance and reliability. The GUI can introduce new bugs, so it’s more reliable to work with the command line tools. We will get to the GUI stuff near the end.
If you would prefer a faster, more GUI approach, start with the “audio” Group section, then jump to the qjackctl and Qsynth sections, then go back to the Virtual MIDI Keyboard section and read to the end. This should get you going quickly. It’s still a good idea to read the whole thing as there are many helpful troubleshooting tips sprinkled throughout.
Audio software needs to run at a higher priority and with memory locked so that it doesn’t swap out to the hard disk. To give a user that power, we create an “audio” group, give that group some special privileges, then add the user to that group.
Note: Ubuntu/Debian can set up a properly configured audio group for you when you install jackd2. If you’d like, you can do this before continuing:
sudo apt-get install jackd2
Be sure to say “yes” when it asks if you want to enable realtime process priority:
After jackd2 is installed, you can skip to “Add Users To “audio” Group” below.
Create An “audio” Group
First, let’s check to see if your system already has an audio group:
$ grep audio /etc/group
If you see an “audio” line like the one above, then you’ve already got an audio group and you can skip to Group Limits.
If grep didn’t find an audio group, add one with groupadd:
sudo groupadd audio
The limits for the audio group can usually be found in /etc/security/limits.d/audio.conf. Check to see if that file exists on your system. If not, create one. You might need to create the limits.d directory. Use mkdir for that:
sudo mkdir /etc/security/limits.d
Then create the audio.conf file in there. I usually use nano:
sudo nano /etc/security/limits.d/audio.conf
And add the following lines:
@audio - rtprio 95 @audio - memlock unlimited #@audio - nice -19
The rtprio line gives the audio group the ability to elevate real-time priority to 95 (99 is the highest). JACK needs to be able to do this to handle audio in real-time. The memlock line gives the ability to lock any amount of memory. fluidsynth needs to be able to do this to keep the soundfont in memory while it is using it. fluidsynth will issue error messages about not being able to “pin” memory if this isn’t working.
The commented out “nice” line would give the ability to raise nice priority to -19 (-20 is the highest). Since it is commented out (#), it does nothing. I’ve just provided it for reference.
For more info, see the man page for limits.conf(5).
Add Users To “audio” Group
Even if all of the above was already done for you by your distro, the chances are good that you’ll still need to add yourself to the “audio” group. You can check to see if you are already in the “audio” group with the groups command:
ted adm cdrom sudo dip plugdev lpadmin sambashare
In this case, we can see that I am not in the audio group yet, so I need to add myself with gpasswd:
sudo gpasswd -a ted audio
You’ll want to use your userid instead of “ted” when you do this.
This change will not take effect immediately. You must logout then log back in again. Use the “groups” command to see if you were successfully added to the audio group.
ted adm cdrom sudo audio dip plugdev lpadmin sambashare
ALSA, the Advanced Linux Sound Architecture, is the part of the Linux kernel that talks to your sound-related hardware, like sound cards and MIDI interfaces. It is made up of device drivers and other kernel modules that provide useful audio-related functions. Many distros already have all the ALSA-related parts of the kernel built-in, so all you have to do is plug in your hardware and use it.
ALSA Device Names
To uniquely identify each piece of audio hardware on a system, ALSA assigns them unique names. Usually, “hw:0” is the name of your soundcard. The various audio programs assume that they will be working with hw:0, but they all provide ways to change this.
You can run into trouble if your soundcard isn’t where you think it should be. So, we need to figure out what audio device names have been assigned to which devices. There are two ways to do this. First we can check /proc/asound/cards:
$ cat /proc/asound/cards 0 [Interface ]: USB-Audio - USB Uno MIDI Interface M-Audio USB Uno MIDI Interface at usb-0000:00:1d.0-1.2, full speed 1 [LPK25 ]: USB-Audio - LPK25 AKAI professional LLC LPK25 at usb-0000:00:1d.0-1.1, full speed 2 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xd4400000 irq 45
The numbers to the left indicate the card number. So in this case, number 2 is my soundcard. This means hw:2 is the ALSA device name I need to use. But this doesn’t tell the whole story. There may be multiple devices per card. aplay gets us that information:
$ aplay -l **** List of PLAYBACK Hardware Devices **** card 2: Intel [HDA Intel], device 0: ALC270 Analog [ALC270 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 2: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0
From this, we can see that I have two sound devices on my system. The first is card 2, device 0, or “hw:2,0”. That is a standard sound device that is connected to my speakers and headphone jack. The second is card 2, device 3, or “hw:2,3”. That is the sound device that drives my HDMI port.
Note that there is also a subdevice level. It appears that the general form is hw:card,device,subdevice. If you leave subdevice or device off, it assumes 0.
Hopefully “hw:0” is all you need to know after looking at your device lists. If not, then be sure to jot down the appropriate device name that you discovered, and use it where you see “hw:0” for the rest of this tutorial.
Testing ALSA Audio
Use aplay to test ALSA audio. aplay is a simple audio player that can play WAV files. You can use sox to generate a simple WAV file and then play it with aplay:
sox -b 16 -n test.wav rate 44100 channels 2 synth 1 sine 440 aplay -D hw:0 test.wav
The one tricky thing about aplay is that the WAV file format must match the exact format that the device expects. If you get a “Channels count non available” message from aplay, then the format doesn’t match.