Audacity aims to be a simple to use but powerful audio editor.
About 3/4 of Audacity source code is concerned with user interface, and less than 1/4 with audio processing. The code is tangled, reflecting its history. Many people with widely varying skill levels have contributed.
- The audio code is multi-threaded. This is because audio is real time, it must be delivered at a certain rate (typically 14400 audio samples per second). Different threads work on data at different rates, e.g. large but less frequent bursts of data from Disk IO, with buffering of various kinds between the threads to accommodate the mismatches in rates. The code is more complex because it must both play and record at the same time.
- The GUI code is mostly written using wxWidgets library, which handles dialogs and common GUI controls. HOWEVER, the waveforms (in the TrackPanel) is not a standard widget, and Audacity code draws the TrackPanel itself, placing the lines and text and clickable icons.
Getting Audacity building on Linux is usually trouble-free because the right tools are there in the environment, or can be found and installed easily. On Windows and Mac it takes longer to set up the environment. Unless you are very experienced, you need to stay with the version of Visual Studio (Windows) and version of Xcode and OS X SDK (MacOS) indicated in the links below.
- Designing Audacity - read and write about what goes into Audacity and how it works
- Ensuring Quality - coding standards, commenting code, submitting patches...
- Notes for Packagers - people building Audacity for Linux distributions and the like.
- Please subscribe to our audacity-devel mailing list to exchange your ideas with our developers or to seek help.
Tips for New Developers
- Ask lots of questions and don't be afraid to look a fool. It's a learning process and like I tell my students, 'if you don't understand (after a reasonable amount of effort), ask somebody who can help'.
- Note our Coding Standards for Audacity (these don't apply to subordinate libraries). Most importantly, don't use tabs at all, and always use three spaces for indentation (otherwise things don't line up on different editors). We mostly use standard camel-case capitalization. Some use Hungarian notation, but not everybody.
- Note the challenge of maintaining Quality in open source software. We have had many short-term contributors over some ten years. This can result in "organic" interdependencies that aren't obvious, so any code change has the potential to break something. Write your own comments when you add new code. Summarise key points, don't just say the code in words. Choose names logically.
- Use the same tools other people are using.
Some Design Topics are worth reading when modifying and extending Audacity.
Improving and Adding Features
Adding new features is one of the more exciting aspects of the job, but needs care so as not to destabilise what is already there. New approaches using a plug-in type of architecture can help this. Even so, there are some things that cannot always be done in an open source application due to licensing restrictions. Have a look at our Feature Requests page to see what our users most wish to see in Audacity, add your own requests, and let us know if you are interested in helping us implement the best of these.
We also have a Roadmap of planned steps in Audacity development.
Tell us about your changes
When you have crafted your improvement or bug fix, please tell us about it on audacity-devel. At some stage you would typically commit the changes to your own clone of Audacity on GitHub and then submit a GitHub Pull Request. We may need time to respond and get the commit ready to merge, if we like your ideas. Always discuss it on audacity-devel if it is more than a couple of lines of code.
More about Digital Audio
There are also articles on the internet ranging from beginners' guides on how sound is represented in a computer, to research papers on digital signal processing (DSP) algorithms. For some recommended sources, see Digital Audio Recommended Articles.