Linux Audio Plugin Development (LAPD)
Elk Audio
Linux Audio developer interview with Stefano Zambon from Elk Audio
This interview was conducted by Amadeus Paulussen in 2025.
Dear Stefano, thank you very much for taking the time to do this interview! 🙌
Can you briefly introduce yourself and tell us how you came to Elk Audio, a company that develops a Linux-based operating system (Elk Audio OS) that allows vendors to manufacture hardware products based on their Linux Audio software applications and plugins?
My interest in computer audio goes way back, when, as a child, I was amazed by SID tunes on my C64.
I have always worked in audio and music during my career, first as an academic researcher doing physical modelling synthesis, then as a developer for an Italian company doing digital musical instruments (mostly digital pianos in my case), and then in 2014 I became one of the founders and first developer for Elk Audio when it started.
We were initially trying to market a product (a 'smart guitar') for which we decided that Linux was the best solution, but then later we ended up focusing on the core technology behind that product, which became the core of Elk Audio OS.
What makes Elk Audio OS better suited for embedded audio applications than other Linux distributions? I mean, what sets it apart? I heard that you are using two kernels, one normal and one real-time kernel. Is that correct?
Yes, that's correct, we use the Xenomai framework and its dual kernel architecture, combined with a custom audio stack that we developed, to achieve very low latencies on normal Linux platforms (down to less than 1 millisecond of analog roundtrip in certain cases).
The other core principle of Elk is its focus on making it easy to port conventional desktop software, like VST plugins, to embedded devices. We completely abstract all the internal details regarding the particular kernel architecture, and we offer a flexible plugin host (Sushi), which makes it possible to make a full product very quickly, reusing existing software and offering an easy API to control it in various ways (physical controls, touchscreen displays, or external applications).
Can you give us some examples of devices that are based on Elk Audio OS, which most people don't even know are using Linux?
The one that I can mention publicly is the series of synthesizers by Melbourne Instruments, like their Nina and Delia, with motorized knobs. Or several hobby projects that our community has developed, like the NeuralPi, for AI-powered guitar amp simulation.
Besides that, we have several private customers that use Elk in a variety of contexts, like large multispeaker installations, headphone research testbeds, or guitar multi effect pedals.
Funnily enough, I've heard time and again that Linux Audio is much bigger than most people would assume because of the numerous embedded applications in which in the audio market Linux is used. What do you have to add to this?
Indeed! Just recently, many KORG products like the Wavestate or the Ableton Move are based on a Raspberry Pi 4 Compute Module running Linux. Akai, Fender, Arturia and many other companies also have products on the market that are based on Linux under the hood.
And there are even more products where Linux is used for the non-audio parts, like UI and connectivity, together with a DSP or FPGA used for the real-time audio part.
Does the development around Linux becoming more and more publicly known as a solid foundation for audio applications play a significant role with your success around Elk Audio OS, or are you well established with your offering independently of that?
It definitely helps, for sure, that general development around Linux is more robust these days than it used to be, both for the reusable core components of the system and for the development tools.
When it comes specifically to Linux Audio development, I would say it is perceived from the industry as a mixed bag.
Some audio tools and applications are well respected, and our partners are interested in using them. But many other independent audio plugins are often more difficult to integrate, either for licensing reasons, or because their quality is not perceived as good enough, or because the project has a codebase that is difficult to adapt for a specific use case.
What role do newer technologies such as PipeWire and Wayland play for Elk Audio OS?
PipeWire has been an interesting solution to solve many problems in the world of audio that are not latency critical. We have recently integrated it in Elk Audio OS by creating a bridge between our low-latency system and PipeWire, so you can run at the same time both our plugin system for low-latency processing and, at higher latency, a PipeWire subsystem for things like Bluetooth audio streaming.
Wayland, like any other desktop manager system, is not a good fit for embedded applications of our kind. They are really designed with a traditional computer in mind, both in terms of display, computational resources available, and input system. In our case, we typically run any GUI straight on the framebuffer, where it's still possible to have GPU hardware acceleration and use frameworks like QT for a single application.
Do you or any other of Elk Audio team members make music with Linux?
Myself, very little these days, but I like to play around with tools to see what they can do. Other Elkhart team members that do more music production use some Linux-based devices in their workflow, but none is using a Desktop Linux Environment as their base music production system.
In your opinion, what are the biggest challenges in developing for Linux Audio (in general)?
If you are talking about generic, desktop focused Linux distributions, I personally think that the biggest challenge is still the relatively low adoption rate of Linux and the fragmentation of its ecosystem across multiple distributions, graphical systems, etc. I think that these days, some cross-platform development frameworks like JUCE are doing quite a great job in taking care of most of the problems for the developers, offering them a wider user base on macOS and Windows at the same time.
If, instead, we are talking about developing for embedded Linux applications running on low-powered platforms, which is a typical scenario for Elk Audio OS, the biggest challenge is the need to optimize the DSP code more than what is typically needed for a normal desktop PC.
Can you tell us a little about your development workflow for Elk Audio OS (team structure, infrastructure, software used, etc.)?
We are a relatively small team (six developers, plus some business/management people), plus some external consultants that we summon when needed. I'd say that half of us are specialized in a certain area, like low-level Linux driver or microcontroller firmware development, and the other half have a more generic C++ audio development background.
Our key software stack relies on the Yocto Project for packaging the Elk Audio distribution itself. We use a lot Docker these days to have a reproducible build environment that is easy to set up on the cloud or locally. Our userspace applications are written mostly in modern C++, with a few external dependencies, and then we use a lot Python for tools & generic plumbing.
I haven't tried Elk Audio OS myself yet. Are there any parallels to, for instance, Valve's Steam OS?
I would say that there are significant differences with Steam OS, which is based on Arch Linux and targets a device (the Steam Deck), which is very similar to a traditional computer.
In our case, we are targeting lower spec platforms, and in products like musical instruments, you want the overall experience to be more limited, but at the same time more robust and adapted to the specific use case. For example, you have to be extremely careful when doing software updates not to brick the device, the boot time is more critical, you might not have access to things like a full touchscreen display or network,...
That's the reason we use instead Yocto to better customize an embedded device, which is also a very popular choice for other embedded applications of the same kind, like smart fridges, automotive control panels, etc. Buildroot would have been another viable solution, but we prefer Yocto for its flexibility and ecosystem.
I assume that efficiency plays a major role for your operating system, as it is often used on hardware that is not particularly powerful, and challenges such as heat generation, etc. are likely to be of central importance. Is that correct?
Yes, that's correct, and indeed I have already mentioned it as a critical point in several answers.
Are GPUs relevant for you in any way, and what do you think about GPU audio?
Not much at the moment. There is still the inherent problem of sending the audio back and forth from the GPU to the CPU, which has its own latency and computation cost. I think GPU audio is doing a great job in solving that in environments where the tradeoff is good, because you can gain a lot in a desktop environment with a powerful GPU, but I believe that in the embedded world, the average gain is still not worth the amount of effort needed to make it work.
How do you license Elk Audio OS, and do you think open-source and donation-based models can be a sustainable way to make a living from developing audio software?
We have a dual-license model. There is a GPL 3 version (with some components using the AGPL 3 license instead, and others MIT), that anyone can use for free if they adhere to the licensing terms, i.e. if they make their source code available as well.
We then offer a closed commercial license to clients that want to make products without having to release their source code, and that is our main stream of revenue.
I personally don't think that we are at the point yet where people can make a living purely from donations in the small niche that is professional audio software. There might be the lucky rare exception, or more likely, developers being able to combine the donations with customizations for private customers and other revenue streams.
What is your stance on copy protection systems?
We have a quite agnostic view on the matter, and we let our customers free to choose if they want to implement one in their product. In that case, we sometimes offer some technical assistance and tools to help them in the process (like signed and encrypted software updates, or a secure way to store keys in the system), but we don't offer, at the moment, our dedicated, reusable copy protection system.
Do frameworks such as JUCE or plugin standards such as CLAP play a role in your day to day work with Elk Audio OS?
Absolutely! We have always targeted JUCE developers from the beginning, because we know it's a very popular framework, and we wanted to make it as easy as possible to compile and run JUCE plugins on Elk. We had a discussion with the developers at JUCE, which led to their support of "headless plugins" (without a GUI) in the recent versions of JUCE, and before that, we were providing a custom JUCE fork to achieve the same result.
We are not supporting CLAP yet, but we are looking at it with a lot of interest. We will probably start working on it after JUCE will have support for the format, which is planned for the JUCE 9 release.
Can you give developers who want to turn their software into hardware a recommendation on how to get started with Elk Audio OS?
My recommendation would be to head over to our main documentation, which gives you the instructions to get started on a Raspberry Pi 4 paired with one of the many audio hats that we support (HifiBerry, IQAudio, the official one from Raspberry, etc.). And we have a Forum where people can reach us and ask for help getting started.
It's also possible to run our Sushi Audio Host on Desktop Linux, Windows, or macOS, which is very convenient for prototyping your project before transferring it to the target hardware device.
And lastly; what do you predict for the future of Linux Audio? 😜
I think that if the current trend of crossplatform frameworks like JUCE supporting Linux natively will continue, we will naturally continue to see more products targeting Linux, because it will be much easier for developers to target the platform.
And there are hopefully going to be more embedded products using Linux for real-time audio processing, especially now that more powerful and cost affordable systems on chips are coming out.