# CSOUND 7: Bare Metal and Co-Processing Hardwares

Victor Lazzarini, Aman Jagwani

► To cite this version:

Victor Lazzarini, Aman Jagwani. CSOUND 7: Bare Metal and Co-Processing Hardwares. Proceedings of the 19th Linux Audio Conference, Jun 2025, Lyon, France. hal-05096036

HAL Id: hal-05096036

https://hal.science/hal-05096036v1

Submitted on 3 Jun 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# CSOUND 7: BARE METAL AND CO-PROCESSING HARDWARE

Victor Lazzarini

Music Department
Maynooth University, Ireland
victor.lazzarini@mu.ie

Aman Jagwani*

Music Department
Maynooth University, Ireland
aman.jagwani.2023@mumail.ie

## ABSTRACT

This paper introduces the support for Bare Metal and co-processing computing devices available in the newest major version upgrade of Csound. Alongside a host of significant changes to the system and language, we have invested significant effort to expand the range of platforms in which Csound can be run. After an introduction setting the context for these developments, we explore first the challenges to porting the system to computing environments without an operating system. This is followed by a discussion of two different implementations on ARM hardware. We then turn our attention to co-processing devices and the possibility of partially running Csound on these systems, through the support of the module API. We discuss two cases: general-purpose graphic processing units and field-programmable gate arrays. The paper then concludes with an overview of potential applications.

## 1. INTRODUCTION

Csound is a Sound and Music Computing system. It is Free Software, licensed by the Lesser GNU Public Licence. Since its inception, the development of Csound has been focused on portability. It came to life as a C-language port (hence its name) of the MUSIC 11 system developed mostly in PDP-11 assembler by Barry Vercoe at MIT [1]. Originally written in Kerningham & Ritchie C, it was ported again in 1992-3 to ANSI C by John ffitch at Bath University. Also early on, versions for what may be classed as embedded or co-processing hardware came to light in terms of experimental parallel implementations on transputers [2] and digital signal processing hardware [3].

The development of an object-oriented application programming interface (API, as well as a fully re-entrant library) for version 5 in 2003 allowed further possibilities for porting to different platforms. This was applied to the One Laptop Per Child project [4], a hardware/software project that pre-empted the advent of single-board Linux-based computers such as the Raspberry PI. Ports to mobile phones (under Android and iOS) soon followed. With the appearance of Csound 6 in 2013, Csound became present on a variety of platforms, running on Web browsers (first through PNaCl, then JavaScript / Web Audio, and finally WASM / Web Audio), embedded under its own Linux distro (Intel Gemini/Edison) [5], single-board computer systems (Raspberry PI [6], Beaglebone black [7], Bela [8]), and co-processing hardware (general purpose graphic programming units, GPGPUs) [9], all the way up to supercomputers. From this perspective, the last frontier to conquer in version 7 became the bare-metal microcontroller (MCU) / system-on-chip (SoC) platforms: all environments to which Csound 6.x was ported relied on some form of operating system (OS).

In this paper, we discuss the porting of Csound version 7 to bare-metal hardware as well as some more recent developments in running components on co-processing hardware. We first discuss the support for bare-metal ARM [10] based platforms, in particular for the Electrosmith Daisy and the Xilinx Zynq 7000 boards. We complement the article by looking at the implementation of co-processing on GPGPUs and field-programmable gate (FPGA) hardware.

## 2. EMBEDDED SYSTEMS AND BARE METAL PLATFORMS

Embedded audio programming platforms enable users to create customised tools, instruments, and interfaces for musical performance, interaction, and expression. They extend the creative process into the design of the musical instruments or tools themselves [11]. Moreover, the easy availability and affordability of programmable embedded systems allow both artists and hobbyists, as well as larger commercial and research entities, to explore this field. This underscores the significance of the programming language or environment used in these devices, particularly in the audio domain. The availability of specialised and higher-level systems like Csound within these platforms can significantly enhance audio processing outcomes and accessibility.

These platforms can be classified into two main categories, Linux or operating system-based single-board computers like Raspberry Pi and the BeagleBone Black and bare-metal systems or MCUs without operating systems like the STM32 [12] and ESP32 [13]. Most software that target desktop environments work seamlessly on Linux-based embedded systems, allowing users to leverage existing tools like Csound with ease. The convenience of operating systems also means that several tasks can easily leverage existing drivers. An example of this is peripheral communication, MIDI or OSC. However, generally these boards are not audio specific and require external break-out boards for audio, MIDI etc. They also come with overheads inherent in operating systems containing functionalities that are not required for audio applications and can result in higher latency or less available computational power for real-time audio. Specialised single-board computer systems like the Bela mitigate these issues by using dedicated sister-boards and Xenomai RT Linux to optimize for real-time audio with low latency. However these boards are relatively expensive.

On the other hand, inexpensive bare-metal microcontrollers have recently become very powerful, capable of performing most audio processing tasks with low latency and quick startup times [14]. The advantages of these devices include their cost, portability (due to small form factors), and specificity. Since all functionality is programmed directly onto the microcontroller, it can be optimised and tailored to perform a specific audio processing function at its highest level of capability. Furthermore, the cross-compilation process for microcontrollers can also be portable across different chips with the same architecture. For example, our experience with ARM-based bare-metal MCUs showed that building Csound for one chip, such as the Electrosmith Daisy [15], enabled it to work on other chips like the Xilinx Zynq 7000 [16] with minimal adjustments. This opens up several different MCUs and boards that have ARM CPUs with just one build process, such as the Teensy [17], Raspberry Pi Pico [18], and the STM32 Nucleo Boards [19].

However, bare-metal systems may be limited by the resources available on the MCU. Parallel or multi-core processing is also less common in these systems. Another challenge with bare-metal systems is that every task needs to be implemented manually for these chips, and most programming is done at a lower

<footnote>* This work was funded by the Maynooth University Hume Scholarship Programme</footnote>
level, potentially increasing development time. For example, a user may need to implement MIDI drivers individually on different microcontrollers to establish communication with their specific sets of peripherals. Similarly, functionalities that are typically managed by operating systems, such as file I/O, need to be implemented manually on microcontrollers as well. With the emergence of platforms like Arduino [20] and Daisy, as well as comprehensive vendor-supplied Hardware Abstraction Layers (HALs), a wide range of libraries and drivers are available to mitigate these issues.

Both types of platforms have their sets of advantages and disadvantages and are best suited for specific use cases. In terms of Csound and its supported platforms, it became clear to us that enabling its use on both types of platforms would be beneficial for users. Until now, Csound was only supported on Linux-based embedded systems, as demonstrated by the pioneering work done for Csound on the Bela [21] and the Raspberry Pi [22]. This limitation arose because Csound relied on the services of an operating system and libraries such as libsndfile [23], which were only supported on OS-based platforms. Now, with Csound 7, it can be built without these dependencies, enabling cross-compilation for bare metal.

## 2.1. Porting Csound to Bare Metal Platforms

Csound 6.x requires the services of an OS in order to run. However, since it is mostly made up of portable C/C++ code (mostly C in fact), it is not beyond the realms of possibility that a port of the system could be designed to run directly on a SoC without an OS. This is supported by the fact that many such platforms provide C/C++ compiler and linker toolchains. Unlike the previous attempts to run Csound on dedicated DSP hardware, we would not require any platform-specific programming through micro-coding and/or assembly.

In porting Csound to run on bare metal, the first step is to identify the parts of the system that required the presence of an OS. We can split these into three elements: (a) soundfile input/output (IO); (b) memory (free store); and (c) miscellaneous non-implemented syscalls. All other non-compatible parts of the Csound system can be turned off in the build, simplifying the process.

### 2.1.1. Soundfile Input and Output

Soundfiles have been essential means of IO for Csound since the very beginning. In fact, before any realtime device access was implemented in the early 1990s, the only means of audio programming required the use of soundfiles. Up until Csound 5 was released, Csound relied on its own implementation for accessing the various soundfile formats in common usage. From Csound 5 onwards, we relied on the services of libsndfile, which in these 20+ years has become the Free software standard for soundfile IO. In fact, in Csound 6.x it became the only required external dependency for the system, which reflected on the fact that it had become somewhat untangled internally with Csound. Fortunately, all other forms of file IO had either been moved to use core memory files (such as for instance temporary compilation files etc) or made optional. These meant that running in a platform with no file services boiled down to removing the libsndfile dependency.

By 2018, bare metal started to emerge as a potentially important platform for audio programming. At that time, some initial investigations on disentangling Csound and libsndfile demonstrated that some form of major code surgery was required. At the time, we also started to plan a new major update to replace version 6.x. The opportunity to make significant changes to the code could not be missed. We developed version 7.0 in a very slow and incremental way, and in 2022 the removal of libsndfile as a dependency was carried out. This was followed, in the more

recent redesign of the API with a means of supporting alternative forms of audio IO, which can be designed in such a way to support any existing disk/memory file access in a SoC.

### 2.1.2. Memory

Another issue that we had not originally anticipated was the need to handle free store (heap) access. Under an OS, we in most typical situations only need to use the malloc syscall to access the heap, and then manage the memory for a program. Under the bare metal platform, this might not be enough. The system may not give direct access to all available memory. The solution is to implement our own version of malloc, which can then handle the allocation at a designated memory location, which we can set at compile time and declare in a loader script. With this in place, we are able to use the available memory resources of a SoC in a much more flexible way.

### 2.1.3. Miscellaneous Syscalls

A number of syscalls such as the ones handling directory access, dynamic loading, localisation, temporary files, IP network, threading, etc. had to be excluded from the bare metal build. This also meant for instance that no plugin libraries (for opcodes and other modules) would be available. However, Csound 7 has also introduced means of building the system with or without opcode plugins (allowing on one hand different library footprints, and support for systems with no dynamic loading, on the other). Therefore we are able to provide more or less a complete core system, without of course any components that may be dependent on external libraries.

## 2.2. The Daisy Platform

The Daisy is an open-source audio programming platform based around the STM32H7 microcontroller [12]. It contains an ARM Cortex-M7 CPU along with several digital and analog inputs and outputs as well as other peripherals such as audio ADCs and DACs, USB serial and MIDI communication, SPI, UART interfaces etc. It also contains different volatile and non-volatile memory locations, each of varying size and performing at different speeds, allowing flexibility in the trade offs between program size, RAM requirements and performance [24]. The Daisy also provides higher level access to the STM32 HAL through their libDaisy [25] hardware library, simplifying the programming process.

Apart from the Csound implementation, the Daisy supports programming in C++, Arduino, PureData, Max/MSP gen. Each of these environments have some limitations. The C++ and Arduino programming is generally done with DaisySP [26], Elektrosmith's DSP library containing DSP objects ported from different open source libraries (including Csound). The capabilities of audio programs done in this context would therefore be limited by the availability of objects in the library which may not cover all DSP or audio programming aspects. For example, there is not much support for generative techniques in this library. Surely, in a C++ environment missing features can be implemented from scratch or ported from other libraries as done in [11], but that is not suitable for users or artists with limited experience. Max/MSP comes with the inherent limitation of being closed source and requiring a paid license. In terms of Pure Data support, the Daisy utilises the PlugData [27] environment or the pd2daisy utility [28] which in turn use the Heavy Compiler/HVCC to generate C or C++ audio code from Pure Data patches. In this context, Pure Data is more like a front end rather than an audio engine that is used to generate the audio code. Also, all pure data objects are not supported by this compiler, so patches may be limited [29].

Therefore, Csound support can greatly enhance the Daisy platform. Firstly, Csound is a mature and complete audio pro-
gramming system. It covers virtually every DSP and audio pro-
gramming task that a user would require. Secondly, bare-metal
Csound builds and uses the Csound source code itself as a static
library. This enables portability of Csound programs to this plat-
forms as well as the leveraging and consistency of almost all of
Csound features.

2.2.1. Implementing Csound on Daisy

The development process for Csound on the Daisy had two parts. Firstly, following the basic work to enable the bare metal build, we worked on attempting to run Csound code on the board. We made a simple test program utilising the Csound API within the Daisy C++ environment as a test to enable Csound to compile, start and perform. As we were conducting our experiments we had to tackle some execution issues to have a successful run. One of the first issues was related to the Csound library footprint. By default, Daisy programs are stored on the internal 128kb flash memory of the board. This was not sufficient for our build of Csound, which required around 2MB of memory. The solution was to move the binary to an external flash memory, which supported 8MB of memory. While it provides enough space, there is a small impact on performance as a tradeoff.

Another issue was the location of the heap for our custom al-
locator. The Daisy board has 1MB of internal memory available
to programs. We identified that this was not enough for a typical
Csound usage; while it was enough for our stack needs, we had
to place the heap on the external 64MB SDRAM available on
the board. Following these adjustments, we were able to run a
program on the Daisy, which employed the Csound host API.

Once all of these steps were completed, Csound code was
able to run without any issue. The following is a basic example
of audio callback for the platform:

void AudioCallback (AudioHandle::InputBuffer in,
 AudioHandle::OutputBuffer out, size_t size) {
 const MYFLT *spout = csoundGetSpout (csound);
 int end = csoundGetKsmps (csound) *
         csoundGetChannels (csound, 0);
 for (size_t i = 0; i < size; i++) {
  if (cnt == 0) csoundPerformKsmps (csound);
  out[0][i] = spout[cnt];
  out[1][i] = spout[cnt + 1];
  cnt = cnt == end - 2 ? cnt + 2 : 0;
 }
}

The next step was to create an interface between the board
hardware peripherals and Csound code so that users could write
Csound code to access them. For this, we take advantage of the
Csound module API, and used the existing BelaCsound code as
a reference [21]. For analogue inputs, we simply connected into
software bus channels named Analog0, Analog1 etc. To han-
dle digital inputs, we also added an opcode with the following
signature:

out:k = digiInDaisy (pin:i, mode:i)

We also connected the Csound message callback mechanism
with the serial logging available on the board, so we could have
access to system running information. For MIDI, we imple-
mented a set of callbacks as a backend, connecting the Daisy
USB MIDI interface to Csound. Since both of these features use
the USB port on the board, only one of them is accessible at any
given time, unless a separate UART interface is used for MIDI.

The daisy Csound build is part of the Csound core codebase.
Examples can be found at

https://github.com/csound/csound

As shown in [11], the Daisy is useful for creating custom
audio processing devices for live performance. The small form
factor and relatively low price of this board also means that it
can easily be embedded into artworks and installations and com-
bined with various forms of interactivity through sensors. Csound
support can greatly enhance these benefits of using this platform.

2.3. Csound on the Zynq 7000

Besides the Daisy board, there are several other SoCs that con-
tain ARM Cortex CPUs. One of them is the Xilinx Zynq 7000,
which is an FPGA-based SoC. It contains two parts, the process-
ing system (PS), consisting of a dual-core ARM Cortex-A9 CPU
and the programmable logic (PL), containing the FPGA fabric
[16]. This enables interfacing between programs running on the
CPU with custom accelerated hardware running on the PL.

There are several development boards available with this
SoC. We used the Digilent Zybo Z7020 [30] for our experimen-
tal and development process due to the availability of a large
amount of hardware peripherals as well as logic resources on it.

Following our experience with the ARM CPU in the Daisy
board, we were able to develop a second bare metal build for
Csound to run on this SoC with minimal changes from the Daisy
board build. The main difference was that we had to re-target
our build and the cross-compile script to the Cortex-A9 instead
of Cortex-M7. The same compiler toolchain can be reused to
create the binaries. This allowed us to run Csound on the PS of
the Zybo board. To enable audio input and output, we had to
develop an interface with the PL.

The Zybo board contains an Analog Devices SSM2603 au-
dio codec that facilitates audio input and output to and from the
PL of the Zynq SoC. This codec transmits audio using the I2S
format [31], so to interface with the rest of the system, we used
the I2S transmitter and receiver intellectual property (IP) cores,
which are pre-packaged with the Xilinx development toolchain
in the Vivado software suite [32].

To send and receive audio between Csound on the PS and
these IPs, we used the AXI Direct Memory Access (DMA) con-
troller IP along with the Xilinx AXI DMA driver [33]. The
I2S IPs communicate audio data using the AXI Stream protocol
[34], so audio output from Csound was written to the memory-
mapped-to-stream (mm2s) channel of the DMA, while audio
input to Csound was read from the stream-to-memory-mapped
(s2mm) channel. For the PS application code, we again used the
Csound module API, similar to the Daisy implementation, and
connected the Csound engine main IO buffers (spin, spout) to
the audio transfers via the DMA controller.

3. CO-PROCESSING

In this section, we outline some aspects of the implementation
of Csound components (opcodes) using co-processing hardware.
We will first discuss the use of GPGPUs. This will be followed
by a discussion of FPGAs and their applications.

3.1. GPGPUs

The first published implementations of Csound opcodes employ-
ing GPGPUs as co-processors stretch back over a decade. De-
veloped through the use of the module API, these included im-
plementations of the sliding phase vocoder (PV) [35], a sample-
by-sample highly parallel spectral process, and the implementa-
tions of hopping PV analysis and synthesis, as well as additive
synthesis (of amplitude-frequency PV data) [36]. These were
built using the proprietary Compute Unified Device Architecture
(CUDA) API and as a result targeted only NVIDIA hardware.
Fast partitioned convolution was also explored. Results were
very impressive, particular on consumer-grade GPGPUs. Later
a comprehensive implementation of streaming spectral analysis
opcodes was developed, and tested on two separate GPGPUs
with excellent results [37].

The over-reliance on a specific vendor, both in terms of software library and hardware, led us to explore alternatives. A portable option with open-source implementations is offered by the Open Computing language [38] (OpenCL) framework. For spectral processing, the main difficulty at the outset was that it
did not offer an off-the-shelf fast Fourier transform (FFT) im-
plementation (as CUDA did). Nevertheless, it appeared to be
the best avenue for further exploration. Moreover, OpenCL also
supports heterogenous computing, which may be useful in some
applications.

A highly efficient radix-2 FFT was thus developed as part
of the effort to implement time-varying convolution on the GP-
GPU [39]. With this, we were able to offer opcodes for both
time-varying convolution and linear time-invariant convolution,
as well as complex-to-complex and real-to-complex FFT,

```
out:a = clconv(in:a, table:i, size:i, dev:i)
out:a = cltvconv(in1:a, in2:a, freeze1:k, freeze2:k,
    partsize:i, size:i, dev:i)
out:k[] = clfft(in:k[], fwd:i, dev:i)
out:k[] = clrfft(in:k[], fwd:i, dev:i)
```

The code for the OpenCL FFT/convolution implementation
as well as the Csound opcodes can be found at

https://github.com/vlazzarini/opencl_ftt

A more generic co-processing approach has also been devel-
oped with a pair of OpenCL opcodes that serve as an interface to
the GPGPU. Taking advantage of the fact that OpenCL provides
a just-in-time compiler, we have put forward the idea that users
can embed kernel processing code in their application, and exe-
cute them directly on the device, with a means of sending inputs
and collecting the outputs in their Csound code.

A trivial example is shown below. The user specifies the
kernel as a string (in OpenCL code) and the clopd opcode is
used as the interface.

```
ksmps = 64
kernel@global:S = {
    kernel void process(global float *out,
                        global const float *in) {
        int i = get_global_id(0);
        out[i] = in[i]*in[i];
    }
}

clproc:InstrDef = create({
    dev:i = 0
    sig:a = oscili(p4, p5)
    sig = clopf kernel, dev, ksmps, sig)
    out(sign)
})

schedule(clproc, 0, 10, 0dbfs, 100)
```

During execution, the kernel code is sent to each process-
ing cell defined by OpenCL on a given device (ID 0 in this case,
multiple devices may exist in a system). The number of threads
(one per cell) is in this simple example set to the number of sam-
ples in the audio vector (ksmps), but typically will be one or
two orders of magnitude larger, depending on the process being
implemented. The other opcode of the pair can be used if double-
precision floats are employed (and supported by the hardware).
Any number of inputs and outputs may be used, control, audio,
or numeric array types.

https://github.com/vlazzarini/clop

3.2. FPGAs

In the context of FPGAs, co-processing can be achieved by in-
terfacing Csound running on the PS with custom hardware mod-
ules running on the PL. On the PS side, we developed plug-in
opcodes fpgaOut, which sends audio data into the FPGA, and
fpgaIn, which receives audio data from the FPGA back into
Csound. These opcodes have the following signatures:

```
left:a, right:a = fpgain()
fpgout(left:a, right:a)
```

These opcodes can be used within Csound code with stan-
dard audio-rate variables, allowing, similarly to the OpenCL case,
FPGA interfacing directly with the Csound language. As with

the engine main IO buffers spin and spout, these opcodes are in-
ternally connected to an AXI DMA IP, and data is transferred to
and from the PL using the AXI DMA driver.

On the PL side, we created hardware ports of existing Csound
opcodes to leverage FPGA processing. This approach is ad-
vantageous because FPGAs allow a high degree of parallelism
and can perform ultra-low-latency, sample-by-sample process-
ing. They support a large number of GPIOs and are capable
of handling computationally intensive tasks with high through-
put [40]. These features make FPGAs especially suitable for
complex audio processing tasks such as spectral transformations,
large reverbs, high-channel-count processing, or physical mod-
elling, as demonstrated in [41] and [42].

However, programming FPGAs is generally difficult, requir-
ing specialised low-level hardware design knowledge. One solu-
tion to this challenge is the use of High-Level Synthesis (HLS)
techniques, which allow hardware designs to be generated from
C or C++ code. While HLS still requires certain hardware-
specific programming practices, it is considerably more accessi-
ble than traditional hardware description languages like VHDL
or Verilog [43, 40]. We use HLS to generate custom audio pro-
cessing IP cores which are like standalone modules that run on
the PL. Each of these modules can be considered a port of a
Csound opcode.

An example of this is the `reverbsc` opcode, which im-
plements an eight delay-line feedback network `reverb` based on
Sean Costello's original Csound orchestra version of the algo-
rithm [44]. To port this opcode into an IP core, the entire au-
dio processing functionality was wrapped in a single top-level
function, which was then synthesised into a hardware IP. The
arguments of this function define the communication interfaces,
while the function body contains all the signal processing logic.

In our system, all audio communication within the PL is con-
ducted with the AXI Stream protocol, as with the I2S IPs. Using
platform-specific data types and directives provided by the HLS
tool—Vitis HLS [45]—the input and output ports are defined as
AXI Stream interfaces. Parametric control is also supported, and
similar to the original `reverbsc` opcode, the FPGA hardware
version requires parameters such as feedback amount and damp-
ing frequency. These are set from within Csound on the PS and
transferred to the IP using the AXI Lite protocol. This interface
is also defined using HLS pragmas. The code excerpt below
shows the signature of the `reverbsc` top-level function:

```
void reverbsc(hls::stream<stream> &in,
              hls::stream<stream> &out, volatile float &fb,
              volatile float &cf)
{
    #pragma HLS INTERFACE axis port = in
    #pragma HLS INTERFACE axis port = out
    #pragma HLS INTERFACE s_axilite port = fb
    #pragma HLS INTERFACE s_axilite port = cf
    #pragma HLS INTERFACE ap_ctrl_none port = return
    ...
}
```

The complete HLS code is available at:

https://github.com/amanjagwani/ModFPGA/tree/
main/hardware/hls/ReverbSC

4. CONCLUSIONS

The effort in porting Csound to these different computing plat-
forms supports our aim towards *Csound Everywhere*. The sys-
tem is now available to run on small to large platforms, with or
without operating systems, on the web, as plugins in digital au-
dio workstations, on mobile phones, and use co-processing facil-
ities such as GPGPUs and FPGAS. Alongside these, other devel-
opments in the language, API, and engine appearing in Csound
7 have also enhanced its capabilities as a system.

With the support for bare-metal deployment, new opportu-
nities emerge for artistic, commercial, and scientific explo-
ration. Running Csound on small, portable, and low-cost mi-
crocontroller boards such as the Daisy provides flexibility and
mobility. This opens up possibilities for deploying Csound pro-
grams in installations, interactive sculptures, and embedded en-
vironments. New devices, synthesizers, pedals, and modular in-
struments can also leverage the extensive audio processing ca-
pabilities of Csound as part of their audio engine design. For
experienced Csound users, the transition is seamless—since the
bare-metal build uses essentially the same Csound source code,
existing applications can be directly adapted to new embedded
targets.

In terms of co-processing, combining Csound running on
a CPU with custom modules or processing kernels on GPGPU
or FPGA hardware enables accelerated, ultra-low-latency, and
highly parallel audio processing, within the compact footprint of
an embedded system. This hybrid approach allows users to re-
tain all of Csound's rich capabilities while leveraging specialised
hardware for performance-critical tasks. Another powerful use
case is to utilise Csound's generative capabilities, such as ran-
dom number generators, flexible probabilistic scheduling, and
algorithmic sequencing, to control synthesis or processing run-
ning on the FPGA that leverages the high-sampling rates, par-
allelism or low-latency. An example of a generative synthesis
design running on the Zynq-7000 SoC (Zybo Z7020 board) can
be found here:

https://youtu.be/sEWzhKcb3wc?si=
3xstMXMTkqE8QEzx

5. ACKNOWLEDGMENTS

Aman Jagwani would like to acknowledge the support of the
Hume Scholarship Programme, Maynooth University

6. REFERENCES

[1] B. Vercoe, “Computer system and languages for audio research,” *The New World of Digital Audio* (Audio Engineering Society Special Edition), pp. 245–250, 1983.

[2] Ian Bowler, Peter D. Manning, Alan Purvis, and Nick Bailey, “A transputer-based additive synthesis implementation,” in *Proceedings of the 1989 International Computer Music Conference, ICMC 1989, Columbus, Ohio, USA, November 2-5, 1989*. 1989, Michigan Publishing.

[3] Barry Vercoe, “Extended csound,” in *Proceedings of the 1996 International Computer Music Conference, ICMC 1996, Hong Kong, August 19-24, 1996*. 1996, Michigan Publishing.

[4] Victor Lazzarini, “A toolkit for music and audio activities on the XO computer,” in *Proceedings of the 2008 International Computer Music Conference, ICMC 2008, Belfast, Ireland, August 24-29, 2008*. 2008, Michigan Publishing.

[5] Victor Lazzarini, Joseph Timoney, and Shane Byrne, “Embedded sound synthesis,” in *Proceedings of the Linux Audio Conference 2015*, Johannes Gutenberg University, Mainz, Germany, 2015, pp. 1–6.

[6] “Raspberrypi,” https://www.raspberrypi.org/, Accessed: April 24, 2024.

[7] “Beagleboneblack,” http://beagleboard.org/black, Accessed: April 17, 2024.

[8] Andrew McPherson, “Bela: An embedded platform for low-latency feedback control of sound,” *The Journal of the Acoustical Society of America*, no. 3618, 2017.

[9] Victor Lazzarini, John ffitch, Joseph Timoney, and Russell Bradford, “Streaming spectral processing with consumer-level graphics processing units,” in *17th International Conference on Digital Audio Effects (DAFx-14)*, 2014, pp. 1–8.

[10] “Arm architecture,” https://www/arm.com/architecture/cpu, Accessed: April 28, 2024.

[11] Aman Jagwani, “Creative possibilities and customizability of live performance systems with open source programming platforms.,” in *Proceedings of the Ubimus 2023*, 2023.

[12] “Stm32 32-bit arm cortex mcus,” https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus.html, Accessed: April 24, 2024.

[13] “ESP32,” https://www.espressif.com/en/products/socs/esp32, Accessed: April 24, 2024.

[14] M. Mulshine and J. Snyder, “Oops: An audio synthesis library in c for embedded (and other) applications,” in *Proceedings of the International Conference on New Interfaces for Musical Expression (NIME 2017)*, Copenhagen, Denmark, 2017.

[15] Electro-Smith, “Daisy,” https://www.electro-smith.com/daisy, 2023, Accessed: 2023-06-08.

[16] Xilinx, “Zynq-7000 soc,” https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html, 2023, Accessed: [2023-05-07].

[17] “Teensy USB development board,” https://www.pjrc.com/teensy/, Accessed: April 28, 2024.

[18] “Raspberry pi pico,” https://www.raspberrypi.com/products/raspberry-pi-pico/, Accessed: April 28, 2024.

[19] “STM32 nucleo boards,” https://www.st.com/en/evaluation-tools/stm32-nucleo-boards.html, Accessed: April 28, 2024.

[20] “Arduino,” https://www.Arduino.cc/, Accessed: 2024-02-16.

[21] “Csound on bela,” https://csound.com/site/news/2019/05/06/csound-on-bela, Accessed: April 28, 2024.

[22] “Csound 30 years maynooth - workshop csound and raspberry pi,” https://cosmoproject.github.io/Workshop_Maynooth/, Accessed: April 28, 2024.

[23] “libsndfile,” http://www.mega-nerd.com/libsndfile/, Accessed: April 28, 2024.

[24] “Electrosmith - memory: What is the difference?,” https://electro-smith.com/pages/memory-what-is-the-difference, Accessed: April 28, 2024.

[25] “libdaisy - hardware library for daisy audio platform,” https://github.com/electro-smith/libDaisy, Accessed: April 28, 2024.

[26] “Daisysp - digital signal processor library for daisy audio platform,” https://github.com/electro-smith/DaisySP, Accessed: April 28, 2024.

[27] Timothy Schoen, “Plugdata: A visual programming environment for audio experimentation, prototyping, and education,” https://plugdata.org/, 2025, Accessed: January 28, 2024.

[28] “pd2dsy - a tool for converting pure data patches to daisysp code,” https://github.com/electro-smith/pd2dsy, Accessed: April 28, 2024.

[29] “hvcc - heavy compiler collection,” https://wasted-audio.github.io/hvcc/, Accessed: April 28, 2024.
[30] Digilent, “Zybo z7 reference manual,” https://digilent.com/reference/programmable-logic/zybo-z7/start, 2023, Accessed: 2023-08-24.

[31] Advanced Micro Devices, Inc., I2S Transmitter and I2S Receiver LogiCORE IP Product Guide (PG308), 2024, Accessed: April 28, 2024.

[32] Xilinx, “Synthesis,” https://docs.xilinx.com/r/en-US/ug892-vivado-design-flows-overview/Synthesis, 2023, Accessed: 2023-08-18.

[33] “AXI DMA standalone driver,” https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842100/AXI+DMA+Standalone+Driver, Accessed: January 28, 2025.

[34] Xilinx, “Axi4 stream user guide,” https://docs.xilinx.com/r/en-US/ug1399-vitis-hls/Introduction, 2023, Accessed: 2023-02-18.

[35] Russell Bradford, John ffitch, and Richard Dobson, “Real-time Sliding Phase Vocoder using a Commodity GPU,” in Proceedings of ICMC2011. University of Huddersfield and ICMA, August 2011, ICMC, pp. 587–590, ISBN 978-0-9845274-0-3.

[36] Victor Lazzarini, John ffitch, Joseph Timoney, and Russell Bradford, “Streaming spectral processing with consumer-level graphics processing units,” in Proc. of the Int. Conf. on Digital Audio Effects (DAFx-14), Erlangen, Germany, 2014, pp. 1–8.

[37] Andrea Gianfranco Crespi, “Spectral manipulation of audio using general-purpose graphics processing units,” M.S. thesis, Politecnico di Milano, Milan, Italy, 2016.

[38] Khronos OpenCL Working Group, The OpenCL Specification, Khronos Group, Beaverton, USA, 2019.

[39] Victor Lazzarini, “Parallel computation of time-varying convolution,” Journal of New Music Research, vol. 0, no. 0, pp. 1–13, 2020.

[40] A.P. Jagwani, “Developing a modular sound synthesis platform for fpgas with high level synthesis techniques,” M.S. thesis, Maynooth University, Department of Music, 2023, Supervisor: Prof. Victor Lazzarini.

[41] Michon R. Risset, T. Cochard, P. Letz, S. Orlarey, Y. de Dinechin, F. Popoff, M., “Audio dsp to fpga compilation: The syfala toolchain approach,” Tech. Rep. RR-9507, Univ Lyon, INSA Lyon, Inria, CITI, Grame, Emeraude, May 2023.

[42] C. Wegener, S. Stang, and M. Neupert, “Fpga-accelerated real-time audio in pure data,” in Proceedings of the 19th Sound and Music Computing Conference, June 5-12 2022.

[43] Matai J. Neuendorffer, S. Kastner, R., “Parallel programming for fpgas,” https://arxiv.org/abs/1805.03648, 2018, ArXiv e-prints.

[44] Istvan Varga, reverbsc — 8 delay line stereo FDN verb, 2005, Accessed: January 28, 2024.

[45] Xilinx, “Vitis hls user guide,” https://docs.xilinx.com/r/en-US/ug1399-vitis-hls/Introduction, 2023, Accessed: 2023-02-18.