Real Time Audio Production:Taking it a Step Further
Ok, so you have installed a real time kernel and you are beginning to understand how it works, but you feel that something is still compromising your low latency objectives. Maybe you are running JACK(JACK Audio Connection Kit) and you are experiencing an unusual amount of dropouts and inconsistencies. Or, maybe you just want push the boundaries and determine the lowest latency that is possible on your hardware. Well, keep in mind that your latency is affected by everything from the cache in your CPU to the device driver for your sound card. That said, the following guide is intended to help you achieve minimal latencies with an acceptable amount of predictability. This way, your computer will act as a tool for your audio production needs as opposed to a hindrance to your creativity.
Note: If you are having trouble getting JACK Audio Connection Kit to start at all, try running it in Soft Mode. Open JACK, look under Setup Parameters and put a check in the box to mark Soft Mode as being on.
Checking Your Configuration
This program was written by Arnout Engelen.
(Note to the wary):This program will only scan your computer for optimized real time settings. It will not change anything on your computer. It is also not necessary to have a real time kernel installed to run this script.
You can download it from this link and follow the instructions on the site or you can use my instructions that are provided below. Notice that my instructions will run the command line version as opposed to the GUI version and that the GUI version is still experimental.
1. To install this program, you will need to install mercurial. So, from a terminal, do
su -c 'yum install mercurial'
2. Download the program:
hg clone https://realtimeconfigquickscan.googlecode.com/hg/ realtimeconfigquickscan
3. Navigate to the ~/realtimeconfigquickscan directory
for the last part I choose to run the command line version as I have had better results with it.
4. So, type (or copy and paste) the following:
and hit enter.
Now, if the scan reports that something is not optimized, it will not only tell you what is wrong, but it will tell you how to fix it. Upon running the script again, you will be able to tell if you made the changes correctly or not. I encourage you to learn as much as you can about the things you choose to alter. The more you understand, the more comfortable you will be while playing and composing music with your computer.
Granted, all of the tests in this scan may not apply to you and your hardware, but this is where the real fun begins. And we all know that real fun can only happen in real time.
The very last thing you will likely see from the output of this scan is something like this
** Set $SOUND_CARD_IRQ to the IRQ of your soundcard to enable more checks. Find your sound card's IRQ by looking at '/proc/interrupts' and lspci.
Do not be perturbed! According to Arnout Engelen, the writer of this script, this last part of the scan has only proved beneficial in one case and is not worth worrying about. If you are interested in continuing in this direction, then continue reading.
There is a nice script by the name of rtirq that you can get from the Planet CCRMA repositories. At the moment, this script is installed in your start-up file when you install the rt patch from CCRMA. For more information on tweaking with this script, I suggest reading this explanation from beginning to end.
If you followed the rtirq tutorial then you have briefly used the chrt command to change the priorities of certain threads. It is used to change the rt priority. It can also be used to change the scheduling algorithm of a PID(process ID) This is simple yet powerful tool. By default the standard linux kernel will treat all processes somewhat equally. However, we are trying to create a system wide bias that is partial to our low latency audio objectives.
This nice application is so easy to use that I couldn't think of a reson not to include it. If you have a multi-core CPU then this is for you. Most of the time you don't get to interact with you cores individually. With Cpuset, those days are over! Now, you can run you audio programs on a seperate core(s). Now, don't get too excited because all the CPU cores will have to send thier signals out of the same bus. It is a neat application nonetheless. For those interested, click this
Does all this stuff really matter?
As I became more interested in the concepts of real time computing , I experimented with a few simple, yet interesting benchmark tests. You may want to do the same. However, be warned that the average benchmark test only tests the benchmark program itself, and our goal here is to make and/or record music using our computer. These tests are super interesting, and you can find plenty of information about them at the RTwiki . For the most part, these tests are short and sweet and are a great way to begin learning about real time preemption. I find the idea of splitting time up into nanoseconds very interesting and slightly incomprehensible. But, to avoid digressing into another topic completely, your best benchmarking tool for audio purposes may be the JACK Audio Connection Kit using your preferred settings and applications along side.
Real Time Computing Links
As you can imagine, there are many uses for real time computing. And let's face it, the computer doesn't care if it is processing music or not. So, it becomes an issue of understanding how the kernel, the hardware, and the applications interact together at the millisecond level. To save space and time, and to avoid repeating another wiki word for word, I will leave you with some links that further elaborate on the topic of a low latency performance objective. After all, I am just the messenger.