Paul Davis: an Ardour for the Challenge
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 www.ak.tu-berlin.de/menue/edgard-varese-gastprofessur/paul_davis), specializing in UNIX C/C++ environments. In 1994, he became the second employee of Amazon.com, 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.
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.
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 Amazon.com, 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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide