Paul Davis: an Ardour for the Challenge

It is no exaggeration to claim that Paul Davis' software is employed by every serious Linux audio user and developer.

Paul Davis' JACK sound server is the cornerstone of the modern Linux audio system, and his Ardour DAW (digital audio workstation) is regarded as the flagship application in that system. He also has contributed significantly to many other sound and music software projects, including ALSA, the default sound system for the Linux kernel.

After graduating summa cum laude from Portsmouth Polytechnic (UK) with a degree in biomolecular science, he followed a career course as a software engineer, systems programmer and consultant for various technical firms and institutes (a summary is available on-line at, specializing in UNIX C/C++ environments. In 1994, he became the second employee of, where he developed essential software for the fledgling on-line bookstore. Since 1998, he has been operating Linux Audio Systems, a business venture “...focused on using Linux as a platform for audio and MIDI applications, with a particular focus on real-time performance and commercial studio tools”, as the man himself describes it. Currently, he resides in Berlin where he is the Edgard Varèse Gastprofessor lecturing at the Technische Universitat.

Paul Davis

In addition to his reputation as a master programmer, Paul is highly regarded in the Linux audio world as a model for team leadership and the practical management of large-scale distributed development projects. He has attracted a very talented crew of developers for his own projects, and his opinions and views are often sought by novice (and not-so-novice) programmers. The following interview reveals some of the reasons why.

Writing Audio Software

DP: Your education and professional history point toward a career as a programmer in business or scientific fields. When and why did you decide to write music and sound software for a living?

PD: After I left, I felt I wanted to leave programming for good. That was fairly easy at first, because I was busy being an at-home parent to my one-year-old daughter. However, after a couple years, I started to explore music making as a hobby, and I immediately realized that for recording, computers and hard disk recording were the way everything was going. For all kinds of reasons, I wasn't going to use Windows or a Mac, but I decided I could leverage my exposure to both Linux and my ten years of UNIX programming by doing things on Linux. It turned out that the tools available at that time (1997) on Linux were really not up to the task, and I foolishly decided that I would just write my own. This came at a time when I didn't need to make an income, and I basically focused on my own needs and desires, which initially mostly were focused on pattern-based composition and real-time synthesis. Eventually, the need for a reasonable recorder became more and more clear, and at the end of 1999, RME released the first Hammerfall card with 26 channels of input, 26 channels of output and an existing Linux device driver (for OSS, not ALSA). It seemed clear that I needed one of these, and that I should update the driver and then write an HDR application. The driver took a few weeks, and a month or two later, I had a working recorder. It was only a few months later that I and other early users/testers recognized that a recorder by itself was useless and that we needed an editor. Had I known then what I know now about what is involved, I think I would have given up.

To get back to the focus of the question, I didn't really try to make an income from my audio software until about three years ago when my financial situation was becoming precarious. Before that, it was almost entirely a labor of love and a lot of fun. Since then, it has become a bit more of a burden—I try to work reasonable amounts, as people actually are paying me now, and it's very hard to make a living in the US by giving away software! I often think that I (and my family) should move to a much cheaper country, where the income I do make from Ardour would go much further than it does here. Right now, alas, this is not an option for us. And, although I don't like to go on about it too much, income really is a major issue for me right now, with one child about to head off to film school and another likely starting a four-year college in a couple years. It's not clear that I can honestly say that I am making a living doing this, but somehow, I am still here when companies like BeOS, Creamware and so many others have come and gone. It amazes me!

Writing software for musicians and audio engineers has revitalized my love of programming. Helping people connect with their creative selves is a real joy, and facing down huge technical hurdles is very satisfying. The programming I did for 15 years before I started doing this stuff was really just a warm up, both in terms of the satisfaction that I've gotten from it and the pleasure I get from how my work affects others.

DP: What are some of the important differences between writing software for a large-scale Web-based business and writing music and sound software? What are the important similarities?

PD: I don't think there are any similarities other than the need to write good code. One of joys of the way I have worked for the last seven or eight years is that my work is dictated directly by users first and then by my own aesthetics as a programmer. If I decide some code I've written isn't good enough, I am free to rewrite it completely to meet my own standards. Working inside a standard commercial operation, that freedom is hard to find, and your priorities and deadlines are based on marketing realities (and marketing aspirations). One could argue that this delays development and releases, and to a certain extent that's true. But I'm more interested in not facing nasty legacy code problems in five years than I am in meeting someone's idea of when a release should have been finished. The Linux kernel has followed much the same pathway, and it has paid enormous dividends. The kernel code, for the most part, keeps getting cleaner and cleaner even as the kernel gets bigger and more complex. I can't say Ardour is quite as much of a success in this area, but there is a similar motivation.

One day, I would like to know more about the internals of how Ableton Live is developed. I have met the head of Ableton and was very struck by what he told me about how they use a lot of formal software development methods. I have very little experience with these techniques, and I sometimes wonder if Live is a great program because of them or in spite of them.

DP: Project management in the Free Software world has been compared to herding cats. You are well regarded by your colleagues, and it's obvious you know how to control a herd of very talented cats. So, what's your secret? What significant problems have you encountered in managing an international crew working (for free) on a project as complex as Ardour?

PD: The problems didn't really show up in a big way until we started adding MIDI support. This required many deep changes in the code, and since that time, we have two branches of the code under development. We face a real need to keep the MIDI one in sync with the non-MIDI one (where until recently, most development has taken place). There are no tricks to this—just hard work and a “merge early, merge often” policy that sadly I have not adhered to myself. Speaking more broadly, the most difficult problem is one of communication. We use IRC a great deal, and it works very well for us as a loosely connected team. But it has a great personal cost to me, in that I tend to feel a need to be available to talk to people in Finland, Bali, Australia and San Francisco no matter what time of day it is for me.

That said, as you noted, Ardour has some immensely talented people working on the program, and these people generally do not require much supervision. It is true that a much larger part of my days are now spent on communication, but it's really similar to what I read about Linus' role with the kernel. My main role is to foster consistency and appropriate timing of new features than to be the guy who thinks up all the cool stuff (though I'd like to think that from time to time I do still think up some pretty cool stuff).


Similis sum folio de quo ludunt venti.

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot