Latency Performance for Real-Time Audio on BeagleBone Black James William TOPLISS Victor ZAPPI Andrew McPHERSON Centre for Digital Music, School of EECS Queen Mary University of London Mile End Road E1 4NS London, United Kingdom, [email protected] [email protected] [email protected] Abstract with a musical experience not too far from the In this paper we present a set of tests aimed at one typical of acoustic and electric instruments evaluating the responsiveness of a BeagleBone Black [Berdahl and Ju, 2011]. This natural compari- board in real-time interactive audio applications. son with well known \devices", such as piano The default Angstrom Linux distribution was tested and guitar, underlines qualities like reconfig- without modifying the underlying kernel. Latency urability, independence/autonomy and high re- measurements and audio quality were compared sponsiveness, which can be assured only on a across the combination of different audio interfaces dedicated system. and audio synthesis models. Data analysis shows that the board is generally characterised by a re- As designers and developers of open source markably high responsiveness; most of the tested novel DMIs, we have decided to explore the configurations are affected by less than 7ms of la- promising and evolving world of embedded tency and under-run activity proved to be contained Linux technologies, focusing as starting point on using the correct optimisation techniques. the concept of responsiveness. The work here presented shows the result of a series of tests Keywords aimed at measuring the latency of a Beagle- Embedded systems, BeagleBone Black, responsive- Bone Black4 board (BBB), used as the core of a ness, latency, real-time. self-contained, open-source musical instrument. 1 Introduction Different hardware and software configurations based on the same Linux kernel (v3.8.13) have Research in Music Technology and, in partic- been analysed under different CPU loads and ular, on Digital Musical Instruments (DMIs) levels of code optimisation. is strongly connected to the field of Human- This work is part of a larger structured Computer Interaction (HCI). Following the study, whose goal is to assess longevity, usabil- trend of many other disciplines involving HCI, ity and reconfigurability of DMIs, compared to like Ubiquitous Computing [Kranz et al., 2009] the standards of acoustic and electric musical and Augmented Reality [Langlotz et al., 2012; instruments. Ellsworth and Johnson, 2013], DMI research has recently started capitalising on portable and 2 Related Work embedded systems rather than on general pur- pose architectures. After many years of com- In 2011 Berdahl et al. presented the Satellite plete synergy, musical instruments are increas- CCRMA [Berdahl and Ju, 2011], a platform for ingly abandoning the laptop/desktop computer teaching and practicing interaction design for in favour of onboard audio processing, leaving diverse musical applications, completely based an important mark in both academia [Berdahl on embedded Linux. It runs on a BeagleBoard5 et al., 2013; Oh et al., 2010; Bac lawski and coupled with an Arduino Nano6 and a bread- Jackowski, 2013] and industry (e.g., Aleph1, board, to support the use of sensors and ac- ToneCore DSP2 and OWL3). tuators. Two years later, Berdahl et al. up- This is due to the fact that DMIs require a graded the platform enabling the compatibil- specific set of design features to provide the user ity with more powerful boards, such as Rasp- (i.e., a performer, a composer, a casual player) 4http://beagleboard.org/products/beaglebone% 1http://monome.org/aleph/ 20black 2http://line6.com/tcddk/ 5http://beagleboard.org/Products/BeagleBoard 3http://hoxtonowl.com/ 6http://arduino.cc/en/Main/arduinoBoardNano berry Pi7 and BeagleBoard-xM8, and expanded cludes most of the standard components re- the range of possible applications including net- quired to synthesise and control audio in real- working capabilities and hardware-accelerated time on a self-contained instrument (i.e., with- graphics [s[Berdahl et al., 2013]. The project is out the need of laptops and any additional ex- based on a Fedora distribution with a custom ternal devices). Details on each of these com- low latency kernel. ponents are given in the following subsections. A good example of how new generation em- bedded Linux boards can be used to extend the 3.1 Board and OS capabilities of a musical instrument has been The BBB is an embedded Linux board based recently presented by MacConnell et al. [Mac- on a 1GHz ARM Cortex-A8 processor. It is Connell et al., 2013]. This work introduces shipped with an embedded Angstrom Linux dis- a BBB-based open framework for autonomous tribution (v3.8), optimised to run on embedded music computing eschewing the use of the lap- architectures. This distro is meant to run gen- top on stage. Some important features of em- eral purpose applications and it is not specif- bedded systems are here used to provide the in- ically audio-oriented. Our first intent was to struments designed using the framework with explore the capabilities of this default board high degrees of autonomy and reconfigurabil- configuration, without introducing any changes ity. Authors include also data regarding the in the underlying kernel. We believe this ap- latency of the system running Ubuntu 12.04. proach could be very useful for the community Since mainly FX-like processes are addressed, of embedded developers to have a clear outline only the audio-throughput time is measured, of the built-in audio capabilities of the BBB, under different system load configurations. Re- thus helping choose the right board. sults vary between 10 to 15 ms, according to the Although belonging to a new generation of kind of filtering. compact and fully accessorised boards (e.g., The necessity of measuring the responsive- HDMI, uSD card slot), the BBB does not na- ness of computer-based systems is not recent tively provide any audio interfacing. To test at all, especially in the context of real-time op- the performances of this board in relation to erative systems. In 2002, Abeni et al. used high quality audio synthesis, two commercially a series of micro-benchmarks to identify major available audio interfaces were chosen for com- sources of latency in the Linux kernel [Abeni parison; these were both configured for use with et al., 2002]. They also evaluated its effects the board so as to provide real-time audio out- on a time-sensitive application, in particular an put. audio/video player. Moving towards computer- based audio systems, it is worth mentioning the work by Wright et al. [Wright et al., 2004], in which the latency of MacOS, Red Hat Linux (with real-time kernel patches) and Windows XP are compared, both in an audio-throughput configuration and in an event audio-based con- figuration. The technique used to estimate the event audio latency consists of measuring the time delay between the sound produced by pressing a button on the keyboard and a sinu- soidal audio output triggered on the computer by pressing the button itself. 3 System Configuration The tests presented throughout this work aim Figure 1: The USB interface and the Audio at the evaluation of the capabilities of a BBB- Cape attached to the BeagleBone Black. based system when used as development plat- form for DMIs. The chosen configuration in- 3.2 Audio Interfaces 7http://www.raspberrypi.org/ 8http://beagleboard.org/Products/ We tested one USB interface and one Beagle- BeagleBoard-xM Bone expansion \cape" providing audio output. This choice aimed at comparing the two most model between operating processes and output common solutions used by BBB users for gen- devices. For this reason, only a synthesizer class erating audio output. Figure 1 shows both the was designed to operate as the client process, interfaces attached to the board. while a standard JACK server acts as the audio The first interface used is the Turtle Beach engine for transport. In this configuration the Amigo II USB Interface9'This device is bus- server pulls audio from the client process every powered and USB 2.0 class-compliant.. Once time it requires new output data, this is in stark attached, this device is automatically recog- contrast to the ALSA system whereby audio is nised as a new hardware interface, meaning that pushed to the output devices. it simply requires being specified as the selected Concerning audio synthesis, both the synthe- device for audio applications. This interface sizers implemented in ALSA and JACK gener- provides 2 stereo 3.5mm jack receptors, one for ate simple sine waves based on reading from input the other for output. Only the latter has a wavetable. Both systems are configured to been used for our tests. provide CD quality audio, (i.e., 16bit resolu- The second interface used for our tests is tion, 44.1KHz sample rate) and to run the au- the BeagleBone Audio Cape10; this device effec- dio thread at the maximum priority level using tively acts as an extension to the BBB, it simply a real-time FIFO scheduling. attaches to the top of the board to provide an A parallel control thread was included to audio interface. Audio data are exchanged to manage user input through the keyboard and to and from the BBB using an I2S connection. Un- have access to the general-purpose in/out pins like the USB interface, this device requires some (GPIO) read/write capabilities of the BBB. manual configuration to be recognised as a plug- in hardware interface. The on-board HDMI au- 4 Performance Test dio virtual cape must be disabled so that the The responsiveness and the audio quality of Audio Cape can be loaded by the firmware as four different specific configurations were tested, the main audio device; this can be easily done combining the use of the 2 audio backends by changing the uBoot parameters passed at (ALSA an JACK) with the 2 audio devices boot-time.