Linux Audio Development (LAD)
M Media Audio
Linux Audio Developers Spotlight interview with Jeff Mutschler from M Media Audio
This interview was conducted by Amadeus Paulussen in 2026.
Dear Jeff, I am excited to be talking with you about your company, your plugins, and Linux! 😎 Thank you for taking the time to do this.
Could you briefly introduce yourself and M Media Audio?
I'm Jeff Mutschler, founder of M Media Audio, based in Austin, Texas. M Media started in audio production back in 1994, tracking, mixing and mastering with a mix of 70% broadcast, 30% artist, and I spent several decades on the technical side of software as well; now we primarily build plugins, utilities and applications with the occasional mix and master gig. My first software gigs were with a company called Freeside Communications here in Austin, they were excellent people and they showed me FreeBSD for the first time - blame them. :D A couple of years ago those two backgrounds merged into what M Media Audio is now: a small indie commercial VST3 plugin shop.
Can you walk us through how a plugin typically comes together at M Media Audio, from concept to release?
I have a list of different things I want to try with extremely silly names that's about a mile long, far more than I can realistically do in this lifetime… I keep adding to it. I'm supposed to have a release schedule, but I constantly put newer ideas at the front of the line, lol. In a general sense though, the process usually starts with a specific sound or concept I want that either doesn't really exist or is far beyond my hardware budget. From there it's writing a formal spec; it sounds archaic, but it really helps me gather my thoughts and identify any gaps. When I'm satisfied, now I know what we're building so I can design a GUI and get a lot of the UI functional so I can then spend the bulk of my time on DSP prototyping and get the algorithm doing what I want it to do. I've finally started getting more organized into building my DSP library of everything we've released and all the unreleased ones, and keeping my SDKs in check. Once the processing is finally right, it gets tuned by ear against real material, tracks and mixes. My least favorite hobby is putting one of our processors on a finished master and realizing it often sounds wayyyy better with the processor… My very favorite hobby is putting it on a bad mix and sometimes making it wonderful, or at the least, tolerable. Is mix or master ever really done? Every plugin goes through a reference-library evaluation before release, then an initial testing pass in Reaper in Windows, which really helps me see what it's doing at a CPU consumption level, then it's off to port and build the Linux version, also typically tested on Reaper. Once that's built, I do the same thing for macOS, then it ships through the license server and the store.
On your website, I read that all your plugins are evaluated against a reference library of more than 10,000 commercial masters. What exactly does that process involve?
It's a calibration step, not a marketing line. I run material through a plugin at its default settings and compare the result, loudness balance, low end response, high end response, spectral tilt, stereo width, dynamic behavior, against a large library of commercially released and unreleased masters across genres and eras that represent everything from metal to bluegrass, stoner rock to hard bop, to classical to electronica. The goal is that a plugin's defaults land somewhere musically sane out of the box, not just technically correct on a meter - what is "right" in the code and what actually sounds amazing aren't always the same thing. It gets even more interesting when comparing both analog produced material versus more modern digital material; if it holds up and flatters both, we're pretty much in business.
Can you give us some insight into your development process as well? Like what technologies, what operating systems, etc. do you use to build your plugins?
Everything is C++ on JUCE, CMake-based builds, VST3 as the format. Windows is where plugins get authored first since that's still where most of my own studio work happens (Cubase, Pro Tools, Reaper and Harrison Mixbus), then I port to a dedicated Linux workstation for the Linux build, and macOS separately. Licensing is a small but robust in-house system I built myself, Ed25519-signed license tokens against a license server I run, no third-party DRM. Reaper is my go-to for cross-platform plugin testing since it's consistent and honest on all three platforms. I should also fess up, I used to be really hard on Reaper, but the truth is, I think it's the most flexible DAW out there.
Did you develop for Linux, macOS, and Windows from the start, or was one of the platforms a latecomer?
Windows is first, only because it's my main workstation. That's where the studio work and the original development happened. By the time I decided to take these commercially to market, Linux audio support had matured, which was a source of great excitement to me, so that was a close second. Some apps still have me glued to Windows, and the alternatives are just too primitive. Apple support was actually the last one to the party, mostly because the tooling and certification costs are steep, and I've heard enough horror stories from friends and colleagues who develop for it to not rush in blind. I really want to support AAX as well, but VST3 and AU will have to do until we can hit more marketshare.
Are there ongoing challenges specific to supporting Linux, or have the Linux builds been mostly smooth sailing for you?
Mostly smooth once the pipeline is right, and that took time to get there, but I had a real one recently worth sharing; a user on Debian 12 reported one of our plugins failing to load with a missing GLIBC_2.38 symbol. Turned out my Linux build machine runs a newer Ubuntu, and glibc 2.38 quietly changed several libc functions (strtol, sscanf, and friends) to redirect to new ISO C23 variants under _GNU_SOURCE, which is GCC's default. None of my code asked for that behavior, it's just what you get building on a newer distro than your users have. The fix was building inside a pinned Debian 12 container instead of my bare-metal dev machine, which caps the binary at the oldest glibc I want to support instead of whatever the build host happens to ship. That one change fixed it across my entire Linux lineup in one pass. Beyond that: JUCE's own API changes between versions (some string-measurement functions got removed in JUCE 8, for instance), and a handful of keyboard-focus quirks specific to how JUCE's Linux backend interacts with hosts like Reaper, are the recurring categories of Linux-specific work.
When working on the Linux builds have you ever had to take a closer look at technologies like PipeWire or Wayland?
For the VST3 plugins themselves, less than you'd think, the host DAW owns the actual audio device, PipeWire, JACK, ALSA, whatever the user has running, the plugin just processes audio the host hands it. It matters more for my standalone player app, Reference Player, which does own its own audio path, which frankly has been a nightmare; I'm still figuring out the right way to sustain that level of support long-term. I can build plugins, which I love, or I can support Reference Player on a jillion Linux versions and distros, but I can't do both. I've had to be deliberate there about how JUCE's audio device abstraction and GStreamer behave across different Linux audio stacks (Reference Player? Not. Well.). Wayland is more of a windowing question than an audio one, and JUCE's Linux GUI layer still leans heavily on X11/XWayland compatibility rather than being Wayland-native, which is something to watch rather than something solved.
How do you think the decision process by musicians and producers to use Linux as their digital audio workstation has changed compared to maybe five years ago?
Dramatically. It's completely viable now for artists, as always, there's still not enough pro-level tools, but even that's changing at light speed. It feels less like a hobbyist statement and more like a practical choice now. Reaper's native Linux support, Bitwig, Ardour maturing, and just general fatigue with Windows update behavior (100% rapidly aging me) have moved many people over. It's still a minority of my customer base, but it's not a rounding error the way it might have been five or six years ago, and the people on it tend to be insightful, vocal and engaged, which often means everything for a small shop like mine. It's inspiring.
Why do you think some vendors still treat Linux as an afterthought?
Fragmentation is the only honest answer left. Try talking one of the big household-name plugin companies into it. Windows and macOS are each effectively one target. Linux is a dozen distros with different library versions, different packaging conventions, different desktop stacks, and a build that works cleanly on your own dev box can quietly fail for a chunk of your actual Linux users for reasons that have nothing to do with your code (coughcough, Reference Player). For a vendor sizing engineering time against a smaller install base, that overhead is easy to deprioritize.
For your particular case, does one operating system require noticeably less work—in development, maintenance, and support—or is it roughly balanced across all three platforms you currently support?
I could say Linux is currently the most maintenance-intensive per user, proportionally, of the three, for exactly the fragmentation reasons above, but the truth is I already have everything ironed out for what needs to happen, so to be completely transparent, it's now the same amount of work as macOS builds. I still need to reiterate, however, Windows and macOS mostly behave like themselves release to release. Linux is where I've had to build actual infrastructure, a container build environment, to keep builds portable across distros rather than just across my own machine, which I keep updated and fairly modern. I would add that the most helpful, insightful comments and requests I've received have been from the Linux community. We've come a long, long way since the rudimentary days of FreeBSD and Debian.
Are you planning to roll out other plugin formats on Linux besides VST3, such as CLAP or LV2?
VST3 only right now. CLAP is the one I'm watching most closely, it's a well-designed format and host support keeps growing. LV2 is more Linux-native but commercial DAW support for it is thinner. Nothing committed on a timeline yet, it's exciting to watch, but it's on my radar rather than dismissed.
What advice would you give other vendors who are considering adding Linux support?
I've started writing a new post for our site entitled "How Not To Build Audio Plugins", and it really details my many trials and tribulations getting to stability. I would say that it's a foolish choice to not build for the Linux platform, but choosing JUCE as the framework, for me, made it all viable - I can develop once, and it's incredibly portable. Redmond fatigue and the sheer invasiveness of the OS is finally reached a breaking point. My advice would be "Don't build on whatever distro happens to be on your dev machine and assume that's "Linux support." Nail your build environment to the oldest distro you actually want your users to be able to run, a container is the easy way to do that, and test the actual binary's library version requirements before you ship, not just whether it compiles. My own recent incident above cost a customer a broken plugin for something that had nothing to do with my code and everything to do with the most trivial of build-host assumptions.
A few vendors who'd like to support Linux are waiting for PACE to offer iLok for Linux. What's your stance on copy protection in general?
I preface this with the fact that we're a microscopic shop, but we don't use iLok or any third-party DRM. I built our own lightweight license system, signed license tokens, verified locally, no dongle, no always-online requirement after activation. My take is that heavy copy protection mostly punishes your paying customers while doing very little against anyone determined to crack a plugin. I watched a guy crack a waves plugin to prove their point in three minutes. It's 1s and 0s, and, yes, we've had a few cracked, which was also oddly flattering? LOL! But who would be foolish enough to install those? Once the initial shock wore off I realized cracked software is typically a delivery mechanism for something much worse. For Linux specifically, waiting on a proprietary vendor to bless the platform before you'll support it is backwards, you can build something simple and self-hosted today instead of waiting on someone else's roadmap. Build it and they will come.
Do you think Open Source can be a viable business model for a software vendor in the audio industry?
For infrastructure and tools, yes. For a small shop's paid creative plugins as the primary revenue line, I'm more than a little skeptical, at least as a sole model - we're trying to keep the lights on, so we're building as fast as we can and still keep quality high. I definitely wouldn't extend the same logic to a plugin that's actually a household's grocery money for a one-person shop, but definitely build something to contribute. I'm indifferent about handing out the framework and structure, but the DSP is what is unique.
How is your outlook on the growing role of LLM/AI, both in relation to human creative expression and in audio software development itself?
I still update our site, write our DSP, and all the fun stuff. Photoshop files with 400 layers. A common complaint, particularly on social media, has been "AI does all the fun stuff." Only if you let it, nerd. It's still me in Photoshop and Illustrator creating the 400 or whatever layers. It's still me rebuilding a build for the 300th time so I can get the DSP just perfect.
Early on, we wanted the highest resolution graphics imaginable, I used Photoshop Generative Upscale, and it made everything look like ChatGPT spit it out mid-hallucination, and I clearly paid the price for that; the originals were much more beautiful, but the resolution wasn't that big… my bad - we were crucified on Reddit, until I spoke up and had to state, no, we're not vibe coding this stuff, lol. For what it's worth, given everything above, most of our build/port/QA work runs through Claude Code in VS Code, so there's a real, specific answer available about AI as a development tool. Magnificent for keeping me on my toes and builds running smoothly. Ask me if I want to babysit build pipelines? No. No, I do not, so that's a great usage. I enjoy writing code like some enjoy sudoku or a great crossword, and yes, Claude could probably easily run circles around me, but would the technical debt be worth it?
How important do you think marketing has become in today's rather crowded audio software market?
It's become as important as the product itself, unfortunately. The AI era in particular has made building a technically competent plugin so much faster and cheaper than it used to be only 5 years ago. This results in a market that's infinitely more crowded with genuinely decent products than ever, and being merely good is no longer sufficient to be found, and these folks apparently have marketing budgets whereas we do not. I feel like we love what we do, I love building plugins, it's the marriage of four things I really, really love to do. For us, the miniscule indie developer, I'm not even sure how advantageous paid advertising is? At our price points, it really doesn't make sense. Certain companies are constantly doing a variation of 200 plugins for $29 each, along with the entire subscription model cash grab, which really brings me to the most important aspect of what we're all about: Pay once, own it, forever. That's the whole deal. Not a rental you lose when you stop paying, not a black box phoning home behind your back.
To get our feet in the door, we built a few simple but fairly unique plugins that most could understand, then we gave away plugins that, yes, maybe we should have sold, notably Volume Dealer and Violet Crown, that we used to gain a bit of an audience. That app alone got us a large mailing list and some very nice, flattering reviews. Many made videos that ultimately got us sales. The truth behind Volume Dealer and Violet Crown was that they were actually meant for Linux first, because there wasn't really anything on that level, but it turned out, many really, really needed that on all platforms.
Reaching the people who'd actually want what you built is its own discipline now, separate from building it well. We're still learning; and to be brutally honest, marketing is not a skill I really want, but I absolutely need to have - it's a bit exhausting.
What does the near future look like for M Media Audio? Is there perhaps anything you can share with us?
Mwahahahaha! We have SO many plugins in the pipeline. I've really been seeing absolutely incredible concepts from people, presumably using AI as a lot of them clearly aren't coming from anyone who actually codes, which honestly fascinates me more than it worries me. Watching that play out is going to be one of the more interesting parts of the next few years, seeing what people ship, if they survive, then seeing who actually sticks with it once the fun part's over. My honest guess is a lot of folks get excited, put something out, and then tire of the actual grind of maintaining a plugin, because that part was never the fun part for anyone, myself included some days. :D But as the models keep getting better, I think the people with one specific, genuine itch to scratch are just going to describe it and get exactly what they need, no shop required, no roadmap to wait on. I don't see that as a threat so much as a different category of person finally getting served. It's like making a record, there is no right or wrong way, whatever comes out of the speakers and moves you wins. As for us specifically, I'll just say the pipeline's long and some of it's pretty unhinged in the best way, more soon.
Would you like to touch on anything else or is there something you would like to add?
Just that I think being a decent human matters more in this industry than people give it credit for, tiny shop or not. Charge a fair price, don't lie to people, don't build something that phones home spying on someone's workflow, answer your own support email instead of hiding behind a ticket queue. That's basically our whole philosophy and it's not complicated, it's just occasionally inconvenient when you're this small.
I'm genuinely excited about Linux as a platform right now, not as a checkbox on a spec sheet but for real, and I'm proud to be even a tiny part of this world. I'm in a pretty constant state of learning and I'd like to actually give more back to it eventually, whether that's writing more about what breaks and why, or open-sourcing some piece of what I've built to make the next person's build pipeline less painful than mine was/is. Still figuring out exactly what that looks like. Right now, if I'm being completely honest, we're mostly just trying to figure out how to keep making a living doing the thing we love while the ground keeps moving under everyone in software; that's the real answer everyone needs.