Running A University Linux-based Audio Lab: Part 1 — Overview

This is part one of a three-part series of articles describing how and why you can use Linux in your college or university’s music/audio lab. In this article I will provide a broad overview of what I do in the CS music/audio lab at Yale and why I do it.

I have been running music tech labs of various forms at Yale for 13 years, first in the Music Department and since 2016 in the Computer Science Department. I have imaged and supported Mac hardware and macOS and, as of 2014, a Linux cluster as well. Of course, attached to these machines are audio-specific peripherals, controllers, MIDI keyboards, and around them the apparatus necessary to record, mix, and produce.^[1]See this link if you are interested in a high-level overview of the role the studio/lab plays in the computer/electronic music scene at Yale: … Continue reading Today I want to focus on the Linux piece because my current lab is Linux-only (well, almost…) and that entails many joys and sorrows that only the fellow Linux audio lab or studio maintainer could ever truly appreciate. (P.S. if you’re out there and you’re reading this please email me. I would love to kibitz over this stuff with you.)

There are many reasons to choose Linux^[2]Here and forever after I will substitute “Linux” for “GNU/Linux” not because I don’t understand the difference between the two but because one entails considerably more … Continue reading as the operating system for an educational audio lab, including (but not limited to and in no particular order):

• Linux is a highly configurable, highly tunable operating system.
  • Low-latency and realtime kernels exist for audio applications.
  • Software is available via repository and source. If it’s FLOSS, you can install it one way or another.
  • Multiple user management is straightforward.
• Lots of FLOSS Linux software is cross-platform, meaning it doesn’t just run on Linux.
• You do not need to manage licenses for your software. (Or at least *you* choose whether you want to use only FLOSS software or commercial software with license management.)
• You do not need to manage licenses for the OS.
• Duplicating and/or configuring systems is much simpler with FLOSS. In other words, the system is portable: you can *give* it to your students who are not required to make any financial investment.
• People^[3] Not just students, but researchers, workshop attendees, etc. who create work in a FLOSS audio environment never lose the ability to modify, update, or access it.
• Generic computer hardware costs are much lower compared to studios using Apple systems
• There are digital audio workstation distributions specifically designed for this application.

Of course, there are challenges as well:

• Linux is a highly configurable, highly tunable operating system. (And unless you know how to do that you can plan on a few months/years of learning.)
• Some FLOSS software is Linux-only making sharing with friends, collaborators, or even from a lab computer to a personal computer running a different OS difficult. To solve this, users must “buy in” completely, banish windows from their PC, or at least dual-boot. (None of this works terrifically well in virtualization.)
• You want Pro Tools? Sorry!
• Students are often unfamiliar with Linux OS (“It looks weird! Where’s the Start menu??”)
• System formats can be a problem (“I have to format my USB drive as WHAT?”)

In any educational lab there are going to be challenges, you just have to pick your poison. Sometimes, your decisions may be made for you by, say, lack of adequate funding or departmental OS or software mandates. In any case, it’s hard to argue against the freedom you get from using Linux provided you 1) have the skills already or 2) are willing to learn in order to support the environment.

Once you *do* decide to opt for freedom you are faced with a series of decisions. What follows is an overview of the decisions I faced (that you will face) and the decisions I arrived at. In this initial post, I’ll stay light on details. In future episodes I will go into more detail on specific subjects.

1. Choosing computer hardware.

Our desktop and laptop brand of choice is Dell. Our machines are typically in the top tier in terms of quality/features. These machines still price about 50% lower than comparable Apple hardware so we consider this a win. We strive to keep our environment homogeneous to make supporting it easier. We purchase extended warranties and figure that into the cost. We also have a Dell university rep to help put together purchases, give quotes, etc. If your hardware vendor doesn’t have a uni rep or offer discounts, etc, find one that does.

When possible, make purchases in bulk as it works for you to lower the overall cost. I typically also purchase two backup machines of the same configuration to act as live replacements for any machine that goes down. I can’t emphasize how important this is as even with good (and very fast) support from Dell, a machine could be out a week or more for catastrophic hardware failure such as a motherboard blowout (depending on what components it takes with it and how much follow-up testing and replacement needs to be done).

2. Choosing audio and MIDI devices.

We use Focusrite 2i2 devices as our desktop audio I/O device for lab machines. At the mixing console (we have one dedicated multi-speaker mixing/mastering desk) we have a Clarett 2pre and a MOTU 828es. I personally use RME at home, but the cost is prohibitive for the lab.

Regarding the “support” these devices have for Linux, you will lose some proprietary features like the software mixer layer, etc, but they are class compliant and fully functional. Fortunately, the MOTU setup/mixer is a web app served from the hardware itself, so that’s no problem.

For MIDI keyboards and controllers, everything can be expected to just work. We have a plethora of devices hooked up to different machines and all work “as expected” with a little configuring.

3. What OS and software will you run?

Here’s the veggie meat of this post. First, I’ll say I have used DAW specific distros before. Well, at least I tested them seriously, but I do not have any in production for a variety of reasons. Broadly my reasons are these: 1) they tend to be less configurable, and 2) if they do *not* have a package you want you likely have to build from source or risk breaking something by adding a repository. They also come with a look and feel that I often find distasteful. I could spend time tweaking them, but that just means more configuration on every machine. (More on that later.)

So, here’s what our machines look like.

Base Operating System Configuration

The base OS is KDE Neon. If you are unfamiliar with KDE Neon it is a rolling release with the Plasma desktop all running on top of the LTE (long-term support) version of Ubuntu. Because it is built on Ubuntu you get all of their repositories and a ton of third party software repos that are built to run on it. Additionally, through Ubuntu you have access to a low latency kernel. We enable that as well.

Additional Software Repositories

I add the KXStudio repositories and install the kxstudio-meta-all package which provides a ton of audio plugins in various formats (probably too many…) as well as some audio applications and utilities that are indispensable including Carla and Cadence, two applications for audio routing and plugin hosting/management.

Software and Configurations

In addition to the software installed from the KXStudio repos, I install several additional audio-specific packages including PureData, Praat, Surge (synth) and some packages from source such as SuperCollider.

I also install a bunch of system-level stuff to allow the computers in the lab to work within Yale’s broader technosystem. That software includes installing and configuring sssd, ssmtp, Kerberos, etc, to allow university-wide authentication via the CS department LDAP.

Last, there is a local file server where users can download sound samples to the lab machines for use in projects. This simply needs to be configured in the OS to make it easily discoverable.

Testing

Once you decide on your software configuration and get everything installed on a new system you will want to test everything. Because the lab is a multi-user environment and because (surprisingly?) lots of software is *not* designed for true multi-user environments you will need to put your software through its paces. What does this mean? Here’s what I look for:

1. How does the system look and feel for new users? Are there sane OS and app defaults or is there a bunch of unnecessary setup that will confuse and anger people?

2. What is software like the first time it runs as a standard (student) account? Again, is there a bunch of confusing setup? Here, the cardinal sin is any configuration that requires admin privileges to complete and therefore keeps the student from being able to work. Beyond that, you want to keep students from being presented with options they don’t understand.

3. Does everything run as expected for a standard user? Open, use, and save projects in every application. Are the default save directories correct?

The testing phase is diagnostic and helps me with one of the last stages of installation, namely the copying of configuration files to the user template used by Ubuntu. That location is /etc/skel. There, I copy the config files to the location they need to be in the new user so they get them by default. This is messy, though. Lots of application specific config cannot go here because the paths are user-specific and so they break when the new user opens the application. This is where documentation comes in. (More on that below.)

Deployment

When everything looks good and you have installed, tested, imaged and tested for different users it’s time to deploy. We have a small lab, six desktop machines and four laptops. Because of the size of the lab and because we do not image every year I do manual deployments. That consists of two steps.

1. Install the base OS using the distribution’s standard installer.

2. Install the software overlay using a script and resources folder. The script pulls everything it can from repos and github, and installs from the local resources folder only when absolutely necessary.

The two steps above require minimal interaction, but do require interaction. If you have lots of machines and no time for hands-on installs on each you will want to look into some mass deployment system. This might be a netboot and install solution. Just be aware that you are treading ever closer to being a Linux server sysadmin at this point. If that (and all that comes with it) is not what you want for your life, you might just put in the hours to do things manually.

Documentation

Once you have a lab of configured (as much as possible) systems you have to provide documentation for those cases when sane (read: easy) default settings or functionality is not possible. The documentation must be accessible and easy-to-use. In my lab, this means that sitting on the (custom wallpapered) desktop is a PDF document with basic instructions for using the system, how to configure anything that doesn’t get configured by default, and contact information for me if the documentation fails them.

Often I will get an email with a question answered by that document showing that students will email first and then RTFM only later. Still, those emails can be answered with a simple “Oh, that’s in the help PDF on your desktop. Page 5. Let me know if you have any more questions!” ^[4]Leans back, kicks feet up on the desk, sips coffee, gets back to troubleshooting why ALSA, Pulseaudio and JACK simply never ever, no matter what, work nicely together.

Bonuses

One of the key benefits I mentioned at the top of this article is the “turnkey” nature of a Linux audio workstation environment. The very system you are creating, testing, and deploying can be literally given to your students, who can install it exactly the way you do. That means whole-disk or installing to a dual-boot partition. The latter is a little trickier, but is well documented. That means that all projects completed in the lab are portable and can be taken with the student to be edited, improved, revised, what-have-you, later on. Contrast that with an all Apple lab with ~$8k of proprietary software that must be duplicated out of the student’s pocket if they wish to work with their files again after they graduate or lose access to the lab.

Another bonus is the shattering of the black-box illusion of magic around computers and operating systems. Just by working in a Linux environment, students will be exposed to things on a lower level than they usually would on their own machines, shining the light of truth and justice on things such as network shares (where their sound samples come from), application config, user permissions, file system organization, etc. If this sounds like a curse more than a blessing, please remember that living in willful ignorance places you at the mercy of whatever corporation is making your hardware and software. If we have learned one thing from Facebo.., er, Meta, it’s that you can never trust corporations and you can never trust software you can’t see. (Or that a seasoned professional who is interested in privacy can’t look at and write a nice article about.)

Conclusion

I hope this brief overview of what our lab computing environment looks like and how it is structured is helpful. I know it was light on details. In future “episodes” I will explicate subjects more minutely, focusing on some issues that have popped up from year to year, others that were or remain difficult to solve, or simply things that require some in-depth study for the uninitiated.

Next Issue: An overview of the Linux audio system (as implemented in our lab). Click the Subscribe link at the top of the page to be alerted when new posts are created.