Linux Audio Plugin Development (LAPD)

Linux Studio Plugins

Interview with Vladimir Sadovnikov from Linux Studio Plugins

This interview was conducted by Amadeus Paulussen in 2025.

Vladimir Sadovnikov from Linux Studio Plugins

Dear Vladimir, I feel honored to be able to talk to you about Linux Audio plugins. I think it's not wrong to call your project a heavyweight in this context. Firstly, may I ask you what you think about proprietary audio plugins in general?

Hello, Amadeus!
I'm glad to answer your questions. And the first one is pretty interesting and looks like more philosophic.

As a developer involved in the development of proprietary products and open source products, the "proprietary" and "open source" worlds are just about how the resources are managed.

The proprietary world aims to receive the maximum profit from the results of the development, while the open source one follows the rule "paid once is available for everyone". And that has a high impact on how the corresponding project will evolve. I cannot say anything bad about proprietary plugins; they just exist, and they are in demand. The income from selling licenses helps manage a team of developers who are fully concentrated on the improvement of the product, and this is important. This is one of the reasons why commercial products are often considered being good and one or more steps forward to competitive products.

How did you get into developing the LSP, and what is your background?

All started when I asked my parents to gift me an electric guitar on my 20th anniversary. First I learned to play guitar, then collected a metal band, and then came to the problems of audio recording.

In the 3rd grade of a technical university, I completely switched from Windows to Linux because I joined a company that provided its solutions based on the Linux platform.

I got used to Linux-based operating systems and never wanted to switch back to Windows, so when the question came about audio recording, I started investigating how I can do it with Linux.

At that time, the third version of Ardour was released, and I started to learn how to deal with it. The first experiments were very bad, but I didn't give up and tried to improve my results. And the important step was buying gear that allowed for better recording results: audio interface and microphones. Thereafter, I started to learn about how to record guitar, bass, vocals, and other instruments. The collection of microphones and other gear like DI boxes and reampers started to grow, but the result still was not satisfying.

Anyway, I came with my band to that point where we were ready to record our album, and I decided not to rent some music studio but to do it with our own hands. I recorded guitars and bass sitting at home, then found a drummer who played drums for tracks, then we recorded synthesizer and vocals. And then started the mixing process, where I found that I'm very restricted with the current set of tools available for Linux. For example, there were no tools for correcting phase differences between different microphones, there were no adequate tools for triggering drums, and all equalizers I used, even commercial LinuxDSP (now Overtone DSP) ones, didn't fit my needs. Moreover, available at that moment, limiters did not allow reaching the desired PLR for the track.

Anyway, we ended up with eight songs on a CD, but the result sounded rather 'OK' than good. Still not satisfied with the results, I met a decent sound engineer, Mark Likhter and took his lessons and exercises to improve my skills. With these lessons, I significantly improved and, moreover, I proofed to him that Linux is possible for audio production. But the lack of even basic audio tools was weighing very heavily. So one day I decided to start developing tools that I needed first, and so the LSP project has started.

Is there any demand regarding the availability of LSP for macOS or Windows?

Yes, there is some demand, but it is hard to estimate it. I mean, I often get feedback that people are waiting for these plugins for Windows or macOS, but it is not so massive.

Even more, LSP Plugins already almost fully work under Windows and can be built for recent ARM-based Apple devices, but without UI at this moment. The main problem here is, that we still didn't find the right way of how to distribute builds for money, as I, personally, don't prefer to distribute builds for proprietary operating systems for free. I think it is pretty fair for people who use proprietary operating systems to pay for the software that runs under them. It also helps the developers to concentrate on the development of the product instead of doing some unrelated full-time job at some company.

Moreover, the latest decline in the relationship between Russia and Ukraine has completely screwed up all financial flows that could support the project. For example, I have a Patreon account that collects donations for the project but cannot withdraw any money from it until the best times will come.

I found my way to Linux after 25 years of Apple and macOS, and in my heyday on macOS, I think I was actually addicted to plugins. 🫣 The market is nowadays advertised pretty aggressively, and although there are still many plugin gems to discover, it is also flooded with dubious products. It regularly happens to me that I discover vendors I have never heard of before. How do you personally see this—I guess you could call it “exploitation” of the music market regarding the marketing of audio plugins?

It looks like a natural process because everyone wants to take their piece of the cake. And aggressive marketing is one of the means to reach the target. If you see the lack of something, then some time further there will be a group of companies fighting one against another for clients that want this 'something' to be available. This is a typical pattern of resource acquisition, and we already met it in different approaches to life.

As the best example, we can consider tons of mobile applications and mobile games in the Google Play Store or Apple App Store. Everyone wants to write their own game or application and earn millions of dollars, but finally, we get a trash can filled with unfinished, primitive, and buggy applications or casual games of the same type with a bit varying setting. Could we call this 'exploitation'? Yes. Is the result good? I suppose no.

Do you think that your LSP suite of plugins and, for example, a DAW like Ardour are enough to produce music on Linux? Or do you think it is desirable that more and more vendors, including proprietary ones, discover Linux Audio for themselves?

I think that it is still not enough. There are many cool things that I could introduce in LSP, but I don't have enough time to do it.

If we look at the commercial companies that have been carefully improving their products for decades of years, open source projects still cannot compete with them due to several reasons. And the main reason already was mentioned by me in the answer to the first question: the management of the resource. Besides developing just tools that process the audio, there are also many other things you need to know and be experienced with. For example, supporting and improving different features in the UI of a plugin is much more labor-sensitive. Supporting multiple platforms and processor architectures is also time-greedy, and so on.

Proprietary companies manage their resources to pay salaries to developers, while open source projects often are developed by single enthusiasts. Even if we close the question of financial support, there is also the performance, which is evaluated in man-hours. A team of developers, testers, and designers working full-time will give much more output than one person who works on the project after completion of a regular full-time job. Moreover, it is much easier to find experts in different domains of computer science than to be an expert in all of these domains by yourself.

I, personally, wish, admittedly somewhat utopian, that everything in this world would be open source. Not just software, but also knowledge, blueprints for products, etc. However, many vendors have reservations about offering their products under an open-source license. Do you think that it would be possible for the majority of the commercial vendors to exist successfully, providing their products under open-source licenses? Or do you have the impression that proprietary software is the more suitable business model for certain vendors?

Yes, it really looks like a utopian idea. Let me try to explain why. The main drive of the evolution is competition and dominance. The humans went not so far from animals; a few thousands of years ago, they lived in caves surrounded by an aggressive environment. According to the theory of evolution, an individual with such resources as food, water, and fire has much more probability to survive and continue their family line than an individual without such resources. This is an extremely aggressive program flashed into our brains for hundreds of thousands of years by nature, and it cannot be easily rewritten by a few thousands of years, as we know from historical books.

This yields to the specific behavioral pattern: humans always look for some kind of profit from their doings, and if there is no profit, then there is no motivation to continue these doings.

Let's try to project it to the 'ideal' world where every software project, specification, blueprint, etc. is open source.

If it is fed only by the enthusiasm of individuals that lead them, finally we'll get a situation where every individual will be under heavy risk of not receiving vital supplies. If these individuals are required to apply for some other job to fill a lack with vital supplies, then they will have much less time to support an open source project, and finally the enthusiasm will disappear. A very sad scenario, really.

So let's consider people have enough vital supplies to support open source projects. The first question is, What's the source of these supplies? If the project is open source, everyone is free to use and modify it.

For others, there is no heavy reason to support developers as it comes against the strategy of resource acquisition flashed into our heads by nature — the natural egoism. If the thing (in our case some software product) does not cost anything, then it will be acquired for free, there is no crazy person who will give back some part of their resource for the costless thing. So the project always needs to prove that it is still in demand and competitive against other similar open source projects. Otherwise, we will fall into the first scenario. And the second question is, what about the competition and dominance strategy also flashed into our heads? According to this strategy, there always will be individuals who want to superseed the competitors to gain more resources. And the primary key to doing this is to close the source code and start selling licenses instead of sharing the result of the work.

This will allow to quickly collect significant material resources, which can be applied to gain a heavy advantage against competitors, which will yield the competing open source projects to die.

What's the main conclusion from this? People should have enough and a stable supply of vital resources to work on open source projects to keep them alive. As I described previously, the natural market cannot fulfill this. So here we come to some kind of model where development of open source projects is supplied from a stable source, like the budgets of governments. But the idea of government also comes in counterpart with 'digital freedom' because it is also based on the same competition and dominance principle.

So I consider open source an amazing phenomenon that could never exist if humans only looked for material profits. To make open source mainstream, the mindset of humans should be radically changed. But being involved in a game of survival, one against another, we are far away from that.

From my perspective, Linux Audio has evolved positively in recent years, to a point where I now believe that my Linux-based system is not inferior to a macOS or Windows-based setup — on the contrary. How do you see the development of Linux Audio, and are you confident about the future or do you have concerns?

I see positive movement in the development of Linux Audio. But to make it rapidly rise, we need some game changers like Valve with their Steam platform and Proton. In other words, we need more market players who will attract more sound engineers, producers, and artists to use Linux-based solutions.

Linux already became a user-friendly environment but still has problems with audio device support and audio tools. In short words, many people are already used to some commercial products from Izotope, Native Instruments, FabFilter, etc. and are not ready to switch to the system that is missing such tools. In many cases, they can replace these products with some native Linux solutions, but not everyone is ready to spend a lot of time learning new tools and the mechanics of how to use them.

We're here not to shame such an approach, but to understand the reason why Linux Audio is now in such a state. On the other side, we see positive movements related to DAWs: there is already a bunch of commercial DAWs that provide support for Linux like Reaper, Mixbus, Bitwig, Waveform, Renoise, etc.

How important is UI/UX for you when developing your plugins, or what do you focus on when creating your plugins?

The UI/UX is very important for the user. Over 80% of the information we perceive is through our vision. Very often, the UI allows to better understand the processes occurring inside of the plugin.

On the other side, developing the UI is a very time-consuming job, it takes much more time to provide a well-organized UI rather than write a DSP code. And in most cases, it covers only 80% of the usability, if we recall the Pareto rule. The success of UIs of commercial plugins is hidden in the rest of the 20% of nuances that are accurately tuned for a better user experience. And this is often a heavy argument why commercial solutions are preferred to open source ones.

For LSP plugins, I've built a plugin framework that allows to generate the UI from some XML-formatted document. That way, we can provide a UI without writing a single line of code using the programming language, but it allows just covers that 80% of functionality. The remaining 20% is a pretty time-consuming job of writing the code to make the user experience better.

I assume you are happy that you don't have to deal with things like copy protection mechanisms in connection with LSP. Do you also think that systems like PACE's iLok would not be able to bear fruit on Linux?

This question yields me into double thoughts. On one side, the liberty of using open source is great; on the other side, you cannot just concentrate on open-source if it is royalty-free.

Many successful open-source projects, even the Linux kernel, have some commercial background, and that's why they are alive and evolving. That's exactly why I want to split the liberty of open source for libre operating systems and add some commercial background to my project for non-libre operating systems.

As I understand, the idea of iLok is to personalize the licenses and to avoid sharing licenses on multiple computers which allows to gain much more profit from software installations. My opinion is pretty simple: if someone wants to bypass the rules of the game, once they will do it. So, the first question I would ask was: Is the copy-protection mechanism I want to integrate into my software worth to spend man-hours to implement it? For my project, I think the answer is 'No'.

What do you think are some of the best aspects of the LSP?

The first one is a tunability. I know, many people hate to learn how some device work, they just want to add the device, select some preset, touch a pair of knobs, and voilĂ , all works as they expected. But if you completely get familiar with the device you're working with, you can gain much more from it and do the thigns you even never believed you can do with alternatives. That's why some sound engineers organize challenges for their students to mix records using a very restricted set of tools: the understanding gives a better result.

The second one is an aim to cover almost all regular purposes of a sound engineer or an artist. We prefer to extend the list of tools, even if they are not perfect and do not provide the best user experience, rather than produce a fixed, limited set of tools that are constantly tuned and improved.

The third one is an orientation on performance. Unlike other open-source solutions, we aim to gain additional performance from modern CPUs by utilizing vector instruction extensions like SSE, AVX, NEON and ASIMD. Often it ends up with writing direct assembly code but it's worth to do it.

And what are, let's say, the most challenging aspects of the LSP from your perspective?

One of the most challenging aspects of LSP comes from its best aspect: to provide a UI that will not fear regular users. Often I see feedback where some user runs some LSP plugin, open the UI and become completely lost in the forest of knobs and switches. One of the ways to ease the user experience is to hide rarely used controls and make them accessible only when you really need them. But only in the latest releases we finally came up with a solution on how we can do this.

The second challenging aspect is the support of a high variety of operating systems, CPU architectures, plugin formats, DAWs and audio backends. For example, we've recently introduced support of OpenGL UI rendering mechanisms in LSP as the previously used Cairo backend was slow when drawing many lines even on computers with modern graphics cards. Even if OpenGL looks like a good portable library to deal with, we met serious problems on several devices and several operating systems where OpenGL driver behaved improperly or even worked slower than Cairo. I suppose we will issue a set of releases until we end up not facing OpenGL problems on users' devices.

And even so, we're not protected from device and driver bugs, which users often interpret as problems in our software.

Another example, if we introduce some DSP algorithm, we need to adopt it for use of modern CPU vector instructions for all hardware architectures we currently support. Let's say, for x86 and x86_64 architectures, we need to introduce at least three additional implementations of the same algorithm for the SSE, AVX and AVX-512 instruction sets, for 32-bit ARM we need to add a NEON implementation, and for 64-bit ARM we need to add an ASIMD implementation. But besides these architectures, there is at least POWER architecture and gaining much more popularity RISC-V architecture, which also requires some experience for implementing DSP algorithms for these devices.

How are you organized, and how many developers work on the LSP?

I spend my spare time developing LSP plugins. I try to follow the 'no day without a commit' rule if it is possible. In other words, even if you do something small this day and push the result to the repository, it is much better than nothing and makes the project advance one step forward. If you're tired or burnt out, you can still do some mechanical work, which you probably wouldn't do being in good shape.

We try to hold the interval of 1.5-2 months between sequential releases and plan the list of features we want to introduce in the upcoming release. All of this is simply performed using standard GitHub tools: we just create a milestone for the release and link all issues we want to close in a new release with this milestone.

Currently, I am the sole developer in the LSP project. Some years ago, Stefano Tronci from Italy helped me to introduce several useful tools like Latency Meter, Profiler, Noise Generator, Oscillator and Oscilloscope, but now he has stopped contributing to the project.

For the UI/UX is now responsible Boris Gotsulenko from Moldova. The new look of LSP Plugins introduced in the 1.2.0 release is the result of his hard work in conjunction with the result of my programming of missing UI functions. So every new plugin UI is now produced by Boris; great, thanks to him. He also helps to close some routine work and sometimes also does small changes in the code.

I'm also happy from rare contributions to the project by independent developers and maintainers. For example, integration of serveral CI scenarios by David Runge and Filipe Coelho helped a lot with catching some regressions in the code related to such dangerous things like memory corruptions, buffer overflows, and underflows. Often users provide good ideas of how we can improve some plugins, and this is valuable, too.

Do you think GPU Audio has a future (especially on Linux)?

Yes I do. If I remember correctly, even ten years ago, I stated that GPUs have enough resources to provide intensive parallel computations, which modern general-purpose CPUs cannot afford. Ideally, you supply some data to the GPU, launch some code that processes it, and get back the result. But here we get some problems related to communication with the graphics card, which does not allow considering the DSP code being real-time due to need of data transfer and synchronization between CPU and GPU and, there over, an introduction of additional latency.

If we get a solution that will allow us to avoid the introduction of additional latency, then there will be nothing that could stop audio being processed on GPU in real time.

Do you use a framework like JUCE for the development of the LSP? What does your development environment look like?

No, I don't use JUCE nor any other third-party frameworks. For such tools like plugins, it is very important to have full control over the code because plugins are not independent software; they are always running in some environment provided by the host. So the fewer external dependencies you use, the easier your job is with their distribution. As I said previously, I've implemented my own framework, which is still not completely portable between operating systems but fully satisfies my current needs: it supports multiple plugin formats, uses the established set of programming paradigms, and has a pretty clean architecture in its third reincarnation.

I always took into attention the ease of building, development and debugging the project. The usual development envirionment is an Eclipse IDE with C/C++ development tools addition with JACK running as an audio server, which allows launching plugins as standalone applications. This significantly reduces time for writing and debugging new code.

Do you test the LSP on different distributions and with different DAWs? Is the Linux fragmentation real?

That depends on what features we introduce. If we introduce a new plugin format or do some changes supporting already introduced formats, we're forced to test it across several DAWs. We also are forced at least to test build process for FreeBSD and Linux on different hardware architectures. If we introduce optimizations in some DSP algorithms, we're forced to test each implementation on hardware.

If we introduce some changes related to the window subsystem of the operating system, sometimes we need to check the result under different desktop environments. So, there always is fragmentation because we're writing portable code, and the primary drawback of the portable code is the need to support a high variety of environments and configurations. Still, that doesn't completely save us from errors and regressions. I hope once we'll find a specialist who will raise the quality control over the produced software.

What would you like to see for Linux Audio's future in general?

I would like to see much more professional developers involved into open-source projects related to Linux Audio and cooperation between them. I mean, when a group of developers work on a single project, they get much better results than each working on their own pet project related to Linux Audio. I also would like to see companies interested in Linux Audio that sponsor the development of open source projects instead of introducing proprietary ones.

What non-LSP plugins on the market fascinate you at the moment?

When you're completely involved into development of plugins, there is not so much time to perform deep learning of the market. You rather learn the needs of users and try to match them. If there are already competing tools, it is a good reason to look at them more precisely and understand what functions they are lacking. Anyway, I think any tool that allows to do what plugins from the LSP package do not allow you to do, is valuable.

Do you use the LSP to make music?

Sadly, but I stopped producing my own music three years ago, when the political environment has radically changed. Maybe I'll get back making music but don't have inspiration to do it at this moment. Instead of this, being located in an unstable surrounding environment (you know, I'm still located in Russia), I decided to focus on things I can do the best. Programming is my primary job and I think I can do the best to transform my skills into valuable results. Still, I sometimes act as a sound engineer and consultant, as LSP plugins became an essential part of one commercial project related to streaming processed audio for radio stations.

Can you give us an insight into what you are currently working on?

The development process is not straightforward. You're always involved into multiple features of different kinds you need to implement. The only question here is about the priority of these features to organize them into the right list of tasks. The primary targets are:

(^) Back to top