Skip to main content

Reaper, Linux, and the Behringer X-Air - Complete Studio Solution, Part 1

Introduction and Rationale

This is part one of a major effort to document my experiences with recreating my home studio, entirely using Linux.  Without getting into too many of the specifics, a few months ago I decided that I was unhappy with Windows' shenanigans - to the point that I was ready to make a serious attempt to leave it behind.  For most in this situation, the obvious choice is to switch to Mac OS.  With its proven track record, support, and options for multimedia production, it is naturally the first alternative to consider if your goal is to simply use something other than Windows.

For me the choice was not so simple. I despise Mac OS and, in general, the goals and philosophies put forth by Apple in an effort to ostensibly provide users with an "easy" working environment.  It does not help that I have also failed to find any aspect of the Mac OS UI intuitive, but I realize that this is a subjective matter.

With my IT background and user-control* favoring outlook, I decided on Linux.  I did this knowing that the road ahead would be paved with many bumps. The Linux audio world is a complex one, and while most (if not all) of the information to do what you want is available, it generally requires a lot of knowledge and a pioneering spirit to get there.  Hopefully this post will help you with the former, but the latter is something that you should expect to bring.

The spoiler that the impatient are probably hoping for is that, at the time of this writing, I have been able to achieve 99% of the functionality that I had with Windows.  The remaining 1% is functionality that I will either be able to achieve with a little more time investment, or functionality that I really didn't need that badly to begin with.

*I am a fan of the free software vision evangelized by Richard Stallman.  However, considering the availability of hardware and software, this project is by no means anything that would be considered "free" in his vision.  I have settled on a solution that consists of  the "best compromise" between what I found to be available, and the functionality I needed.  I would consider it to be significantly improved over the previous level of "freedom" I had when running Windows. 

Overview - Hardware and Software Components

Naturally there are some other major particulars involved with the setup I went forward with. Mainly:

    Behringer XR18
  • The relatively recently introduced Behringer X-Air, primarily due to its hardware flexibility and manufacturer-stated support for Linux (as well as Android, and basically ALL other major platforms).  In particular, I chose the XR18 based on the coinciding factors of cost, portability, number of channels, number of those equipped with XLR/TRS combo-jacks, and other features.  However, this project could presumably be used with any of the Behringer X-Air products with only minor modifications to the configurations, based on the specifics of the hardware.  As a USB audio device, I had concerns as to how this device would perform in terms of latency, but with sufficient tuning, I have found it to be a suitable even in situations involving DAW post-processed talent foldback. 


    Reaper - a powerful, low cost DAW that can run great on Linux
  • The Digital Audio Workstation software REAPER, which has been around for a decade, but is still something of a cult interest for whatever reason.  It is extremely powerful, flexible, and makes no assumptions about how you would like to approach multimedia production.  The cost is minimal ($60**) when compared to other DAWs of similar function (Logic, Protools).
**Granted, this is the "discounted" license, which most readers of this article will qualify for.


  • Reasonably powerful PC workstation
    • I won't spend a lot of time on this topic.  Reaper itself has very modest hardware requirements, which you can read about.  However, considering the layers required and the cost of PCs vs. performance and capacity, I do recommend that you overbuild your workstation to meet at least the following specifications:
      • Intel Core i5 quad core (64 bit) or equivalent processor
      • 8GB RAM
      • 1 Terabyte drive
    • In my case, the system I used has the following specifications:
      • Intel quad core Xeon W3565 @ 3.20GHz
      • 512 GB solid state boot drive
      • 4TB (2TB SSHD x2) w/ hardware RAID 1 data array
      • 16 GB RAM
Let's talk about some of the other key ingredients that will be necessary to create our complete studio solution.

Ubuntu 14.04 LTS, 64 bit

This is a very popular desktop-oriented Linux distribution that has "long term support", and was fairly current at the time I pursued this effort.  Certainly other distributions of Linux would be usable, but this is the one I will use as the basis for this project's examples.

JACK

In the world of Linux Audio, there are several layers of audio systems available in order to accomplish delivery of digital audio to and from your audio hardware.  However, if you want to do any serious audio production, JACK will be an important part of your complete breakfast.  There are two versions of JACK available, and in this project we will be using JACK 2.

WINE

So here we must present what will come as a fairly off-putting fact: REAPER doesn't ACTUALLY run natively on Linux,  If you want to run it on Linux, you must use the WINE Windows Compatibility layer. This is essentially a translator between Linux and Windows applications. It was off-putting enough for me that I resisted this experiment for years.  While I have found many simple Windows programs able to run well on WINE, to me there were many concerns, including performance, architecture support, reliability, and many other things.  But have no fear.  If you have all of your ducks in order, REAPER does run on Wine, and it runs very well.  

WineASIO

Since REAPER uses the Windows-based ASIO audio system, and Linux will use JACK, we need a bridge to allow these two to exchange audio.  WineASIO provides a seamless bridge that satisfies this need.

Other Supporting Linux Packages 

In support of the above, we will need to install several other components on our target Linux machine in order to configure and otherwise facilitate your most common needs.
  • ALSA - This is the lowest level for sound interfaces to connect to applications and other audio layers, at least it has been for many years. It is how Linux interfaces to your audio devices.  ALSA actually provides all of the basic functionality one needs to use an audio device, but there are other audio systems which can enhance this functionality, such as JACK and Pulseaudio. In this project, these systems will sit on top of ALSA, and for the purposes of following discussion, we will infer that connections to the hardware device itself are done through ALSA.
  • Pulseaudio - In the context of a strictly recording-studio oriented computer, this component is technically optional. However, in my circumstance, I use my computer for daily tasks such as web browsing and VOIP communications, and I did not wish to force all applications, such as browsers, simple audio players, headsets, webcams, etc. that require the use of audio to interface with JACK.  JACK, while very low latency and highly configurable, is not a friendly beast, and does not outwardly provide multiple applications the ability to coexist on a machine with a single main audio device, or multiple audio devices serving a single application.  This is a strength of Pulseaudio (although I certainly have a wishlist of how it could better serve these endeavors).
  • pulseaudio-module-jack - We will be using JACK to connect directly to our audio interface (the Behringer XR18).  Unfortunately, this is at odds with Pulseaudio, which, in the most common configuration (as in a stock Ubuntu distribution), also expects to connect directly to the hardware.  This cannot be.  The jack module allows Pulseaudio to instead connect to the audio interface via JACK (which connects to the audio interface via ALSA. As I warned you, the Linux audio world is complex).
  • pavucontrol - Pulseaudio is a powerful way to manage applications and audio devices, but to use its strengths, we need a way to control it.  Pavucontrol is a graphical user interface which allows us to decide how audio and devices should be connected.  Again, this is technically optional if you are not planning to use Pulseaudio for convenience applications.
  • qjackctl, and cadence - As previously mentioned, JACK is sort of an unfriendly beast, and we will need these tools to help wrangle it to serve our needs.
  • linux-lowlatency - When working with audio devices in a recording studio environment, you will inevitably need the lowest latency possible.  The default kernel in a desktop distribution is designed to balance performance for multitasking.  This package is an easy way to replace the default kernel with one that is well suited to live audio production.
  • Behringer X-Air-Edit - This is a program provided by Behringer to control the XR18 (or other X-Air interface).  It is available as a native Linux executable. It will be the equivalent of a patch panel within the X-Air hardware itself.
This concludes part one .  In the next installment, we will get into the details of each of these components, and how they will individually serve our needs.

Comments

Popular posts from this blog

An Alternative Take on AI Doom and Gloom

 I've purposely held my tongue until now on commenting about "AI" (or, more specifically as has come to be known, GAN or Generative Adversarial Networks).  It seems like it is very in-style to complain about how it has made a real mess of things, it is displacing jobs, the product it creates lacks soul, it's going to get smart and kill us all, etc. etc.  But I'm not here to do any of that. Rather I am going to remind everyone of how amazing a phenomenon it is to watch a disruptive technology becoming democratized From the time of its (seeming) introduction to the public at large, around November of 2022, to late 2023, the growth and adoption rate has been nothing short of explosive. It features the fastest adoption rate of any new technology ever, by a broad margin.  To give a reference, the adoption rate for AI image and text generation, real-world uses, in just 12 months is comparable to all of that of the another disruptive technology, the World Wide Web, takin

RANT TIME: Why do replies to a message I sent go to my spam folder?

Despite what one would think/hope, sending a message to a given address does not inherently give Google a high confidence that a reply from this address is expected (and, for example, that it should bypass spam checks). I have confirmed with Google's tech support that there is no way to automatically have this happen. The user can do the following: 1. Add the address to your contacts list in Gmail. 2. Check spam folder for replies, and mark it as "not spam" if something ends up there, which should influence the fate of future replies received. I can also approve an address at the domain level, i.e. if it is a big vendor or similar. I've had to do this with several of our Chinese vendors. I regularly ask engineering and purchasing to give me a list of the supplies we deal with, so I can approve them as a preventative measure. For what it's worth, all of the false positive instances of reply -> spam we have experienced have involved the sender's email server