03_The Software choices
The software tools for this project were chosen on the basis of compatibility and price. We only included free software, with a strong preference for open source programs. In terms of compatibility, the software we used had to be compatible with the Raspberry OS version of Linux and the ARM processors on the Raspberry Pi. To ensure easy access to these tools for all students, we also favoured software that could be downloaded and installed directly from APT, or from deken in the case of Pure Data external libraries. A few exceptions to this are some Pd libraries that are not yet available for Raspberry Pi, but are expected to be soon.
However, this is only an overview of the software used; for detailed instructions on using the various libraries and setting up Raspberry Pi for Ambisonics work, see the dedicated guide and the sample patches included in the OAT documentation.
Audio in Linux relies on a specific framework which includes ALSA and a sound server. ALSA stands for Advanced Linux Sound Architecture and provides audio and MIDI functionality to the Linux operating system[1]. Typically, applications communicate with ALSA through a server, the two most popular being PulseAudio[2] and JACK[3].
PulseAudio is mostly used by consumer applications, but only provides features such as basic routing and volume control. Jack is its professional counterpart, used by DAWs and other music making applications, offering low latency functionality and advanced routing options. Some of the applications we will be using will work with JACK but not PulseAudio. While PulseAudio is included in Linux distributions, JACK needs to be installed via the APT.
Levels of challenge:
As a project that aims to create the necessary tools to use Ambisonics in DIY projects, but also to formalise an education on the subject, we have imagined the use of solutions that present challenges at different levels of difficulty, but that can also provide valuable insights and theoretical background to the users. However, due to the nature of the technology we are exploring and the tools available, this cannot really be conceived as a linear path, but rather as a series of modules that can be connected and integrated, an organic ecosystem of useful tools. However, there is a common end goal, which is to design a working decoder that will allow us to play back an Ambisonics file.
Focusing on Ambisonics decoding is a sensible choice because it is one of the most theoretically complex issues in our topic, touching on a wide range of relevant aspects - such as formats, orders, and irregular arrays - that will be addressed with concrete evidence, thus solving a large number of potential problems that might arise in the design of a listening room. It is also useful for both recording sound fields with Ambisonics microphones and synthesising sound fields with Ambisonics encoders.
Pure Data:
We chose Pure Data as our main tool for working with Ambisonics, partly because it is a language closer to Max MSP, which most of the students in our institution are already familiar with. An alternative to Pure Data is Super Collider, which also has all the necessary features to work with Ambisonics on Raspberry Pi [4, 5]. We explored three different Pure Data libraries dedicated to ambisonics, these are iem_ambi, ceammc and [vstplugin~], these three libraries offer three different approaches, but they also have pros and cons, for this reason we found it interesting to present them all.
Iem_ambi: This library was developed by IEM at the University of Music and Performing Arts Graz, it has a few dependencies on other libraries developed by IEM and runs perfectly on Raspberry Pi. The drawbacks are that it uses a nowadays obsolete channel ordering [SID] which requires some conversion work to make it compatible with formats that are in use nowadays. Also, the decoding method is mode-matching, which makes it a less than ideal choice for speaker setups that are not perfectly regular. Another aspect to consider is that this is the lowest level library and requires the most patching, but it also shows some of the things that normally go on under the hood, which is a very good learning opportunity.
Decoder example patches using iem_ambi are available here
Ceammc (aka hoa.): The Hoa library is an old project developed by CIMC [6] and now discontinued, which has been incorporated into a larger library developed by the Moscow Conservatory Centre for Electroacoustic Music. Its approach is more plug and play than Iem_ambi's, but it is limited to 2D ambisonics. It has a wider range of useful objects, such as a reverb and a number of different panners, and with three types of decoder (basic, in-phase and Max-rE) it allows dual-band decoding. Unfortunately, this library is not yet available on Raspberry Pi, but it is likely to be as a major update is on the way.
Decoder example patches using ceammc hoa are available here
[vstplugin~]: this is the easiest approach in terms of coding, because it allows us to just load existing VST plugins in a wrapper object. Both the IEM plugin suite and the ambiX plugin suite by Matthias Kronlachner are available for Linux, and can be used in the wrapper. However, declaring parameters and values can appear somewhat unclear because of the specific syntax of the wrapper as VST plugins accept parameter values in a range from 0 to 1. However, using [vstplugin~] is very convenient for binaural decoding. As with the previous library, the [vstplugin~] object is not yet available for ARM processors, but may be soon as it is under constant development. [7]
Decoder example patches using [vstplugin~] are available here
In addition to these example patches I have also produced a set of utilities and abstractions including players, testers and format converters. these are available here
ADT + AmbDec:
Another approach is to use the Ambisonics Decoder Toolbox[8] developed by Aaron Heller in conjunction with Fons Adriaensen's AmbDec[9].
AmbDec is a Linux compatible, very complete Ambisonics decoder with dual band decoding, distance and near field compensation. While AmbDec provides audio processing, it does not have any functionality for calculating the required matrices, which must be done by other software. One possible solution is to use the Ambisonics Decoder Toolbox, a library for GNU Octave that generates filter matrices that can be imported into AmbDec [10]. In ADT we can design loudspeaker layouts and save them as .m files, which we can import into decoder designers that produce matrices based on our input parameters. This is the approach to decoding we ended up using in this project.
I have produced a set of loudspeakers layouts and decoder designer scripts that can be used as a starting point for the production of custom decoders, the scripts are available here.
Using AmbDec with Pure Data:
AmbDec is a standalone application, but we can easily set up an internal routing chain using JACK to route sounds from Pure Data, which can be used as our encoder, processing unit or player, directly into AmbDec and then to our loudspeaker setup. I have produced some Pure Data patches that I used during the experiments to play ambisonics sound files and manage levels, and to route sound to AmbDec via Jack. These patches are available here.
References:
[1] https://www.alsa-project.org/wiki/Main_Page
[2] https://wiki.debian.org/PulseAudio/
[4] https://www.ambisonictoolkit.net/documentation/supercollider/
[5] https://madskjeldgaard.dk/posts/raspi4-notes/
[6] Sèdes, Anne, Pierre Guillot, and Eliott Paris. "The Hoa Library, Review and Prospects."
Paper presented at the International Computer Music Conference| Sound and Music Computing, 2014.
[7] https://git.iem.at/pd/vstplugin/-/issues/172
[8] https://bitbucket.org/ambidecodertoolbox/adt/src/master/
[9] https://kokkinizita.linuxaudio.org/linuxaudio/downloads/ambdec-manual.pdf
[10] Heller, Aaron J, and Eric M Benjamin. "The Ambisonic Decoder Toolbox: Extensions for Partial-Coverage Loudspeaker Arrays."
Paper presented at the Linux Audio Conference, 2014.
OAT 03_SOFTWARE CHOICES