An ex-Googler with a dream: Evan Mezeske not only created a one-of-a-kind physics-based synth, he helped pave the way for low-latency audio on the GPU. We chat with him about GPU dev, what actual innovation requires, and his journey as an audio developer.
Editor’s note: Since this interview was recorded, Evan reports that his whole world turned upside down: he’s managed to make Anukari faster and more reliable by running the physics calculations on the CPU instead of the GPU. He wrote a three part devlog series on what happened.
I just saw on your website that Anukari is still in public beta. I thought you were launched, is this an “early access” kind of thing?
Yeah, I debated what to call the launch. I thought about “early access” because I use Steam and that terminology has kind of shown up in the last years.
One challenge for Anukari is the fact that it uses the graphics card for computation and compatibility was a challenge. I had alpha testers, maybe 20 people. And even that was not enough to get a sense for if it worked on a broad selection of hardware.
That’s always going to be a challenge, I think. I have a stack of laptops over here. And it keeps getting bigger because somebody reports an issue and I’m like, “I have no idea”. My users have been great about helping to debug, but at a certain point I’ve got to run a debugger on this thing. So eBay has been my friend.
Did you know you were signing up for this sort of “adventure” when first getting started?
Not at all.
When I first set out, I was vaguely aware that Open Computing language (OpenCL) was a cross platform way to do GPU stuff. I didn’t realize the reality of the situation was going to be so bad. Apple supports it decently. Nvidia supports it ok. But outside of that, things start to get just complicated. I did end up writing a CUDA specific backend and an Apple specific backend.
With Nvidia, they’re releasing driver updates for like the oldest cards that anybody has. The old hardware may not have all the cool features that new hardware has, but the drivers are up to date and working and bug-fixed forever.
AMD does not appear to be like that. AMD is like, “Oh, you have an old card. Yeah. We dropped support for that two years ago. Good luck.”
I forget where you said it but I remember you saying your message to your peers was if you don’t have to use the GPU, don’t do it!
Yeah, it introduces a lot of complexities and difficulties. I do want to make sure nobody thinks I hate on GPU Audio. If somebody else is taking on those headaches, that’s probably awesome.
I come from a performance tuning background — it’s something that I enjoy more than feature work. I get the feeling you are maybe similar? In the sense that you prefer low-level challenges?
I love performance work for a number of reasons. It’s very puzzle-like. When you’re trying to figure out the best way to lay something out in memory and there’s four or five different ways and you get to sort of experiment and learn more about how the hardware works.
I worked on optimization for large-scale distributed systems and it’s different but also kind of the same. The mindset is the same. You have to be creative and come up with cool ideas, but you have to also be honest and benchmark it and even though your idea was awesome and it took you a week to build, it’s like 10% slower and you have to accept that this did not work.
Yes, there is this attraction to the beautiful idea. But in reality, you end up somewhere different, because you don’t know at the outset what the real constraints and compromises are.
What I have to focus on is recognizing that those missteps are an important or critical part of the process. And it’s not easy in the moment to feel that way. I have to slow down and remind myself I had to go through building it in the wrong way for me to really understand why that’s not going to work.
That latency issue with Apple where you figured out what the problem was, hacked around it, wrote a plea and they contacted you — you are basically making it possible for others to run audio on Apple GPUs. Did they end up improving latency?
The people I worked with at Apple were awesome. Once I got through to the correct people I got the most enthusiastic, excited, cool people. They’re realizing that low latency ML model evaluation is really important for a lot of stuff, including audio. They announced Metal 4 a few months ago and I understand the stuff they’ve done in Metal 4 is definitely going to be easier to get low latency results.
Yeah, I guess Metal 4 is macOS 26 and above, so to support anything older you’d still need workarounds?
That’s definitely been a challenge for me, like, “What’s the oldest macOS version I can realistically support?” Apple, via the NDA, helped me support older stuff.
That’s really cool. So is there a non-zero chance you’ll go work for them at some point? [laughs].
[laughs] Well, at one point I was joking that maybe the easiest way to get in touch with people on the Metal Team would be to interview with them! But no, I think I’m done with the corporate part of my life at this point.
Are you happy to not have a manager these days?
There’s pros and cons! The huge paycheck coming reliably… The nice thing about a place like Google is there’s just projects laying around everywhere that you know are going to have a ton of impact.
Whereas when you are on your own, you’re kind of like, “Will people want this?”
You are working in a void. Inventing the whole narrative.
Yeah, exactly. It’s easier to work at a corporation. It comes with a bunch of difficult other things. But in terms of what you are going to work on tomorrow? You can figure that out.
What motivates you to write on your blog? Is that a big part of your process?
I’ve always enjoyed writing. Like we were talking about, these technical problems are fun. It’s fun to write about them.
Google was the first place I worked where I came in and immediately was foisted into working with people who were obviously smarter than me. Not saying I never worked with anybody smarter than me before, but walking into Google was a very humbling experience.
One of the things I enjoyed so much about working there was getting to talk with them and really learn from people who knew what they were doing. That’s one of the things I lost leaving a company like that. The devlog is sort of like me continuing to talk tech, but with the internet instead of people.
Where did the hygiene for writing come from?
That’s a good question. I think part of it is me sort of coalescing my thoughts. It’s like me sort of cleaning up my tools and putting them away in the garage or whatever.
I like that.
It also just forced me to structure my thoughts in a way that was really valuable, especially when you’re working on optimization. Keeping yourself honest about whether it’s working or not working by writing a little blurb about the results forces you to be honest.
That’s cool. It’s also kind of like you are sending out a message in a bottle. My experience is that sometimes it comes back like 6 months later, a year later, two years later. At first, I might question why I’m bothering to share something, but a year later it can make someone’s day.
Absolutely, yeah. I’m glad you said that because you reminded me there is definitely one other reason for the devlog that I didn’t mention, which is that I just love reading devlogs.
You must have gone through long phases where you are just heads down on the GPU and it’s not about music. When you come out of that phase, how is it to wake up and suddenly be making music and patches? What does that transition look like?
One challenge is to always keep the music part in the back of my head, even when I’m doing the other stuff. But you’re totally right. I can remember periods of like a month where I literally did not do any musical stuff. I pressed a note on a keyboard to make sure it still worked or something. And then you kind of like, surface from that and it’s like, “Well, what was the point of all that work?” It’s actually to do something musical.
There’s also this challenge that I’m a far better engineer than a musician. There’s this balance where it’s like, a really good musical demo is probably the thing that the project needs. But also, there’s bugs that I know about. And those are easier for me to go solve.
This is like THE plugin dev conundrum. You get into it to push music forward, but then you have months where you all you are doing is playing a single C note.
You know, in a certain way you know EXACTLY what’s possible with the tool. But that’s like this low level idea of what it can do, like how many oscillators or whatever. It’s hard to get back into that mindset of —forget all about the technical aspects, what sounds can come out of it? How can I do things with it that I wasn’t expecting it to do?
I find it incredibly challenging.
Were you surprised when you had alpha testers and preset designers coming in? They must have come up with stuff you didn’t think about.
Yes, I would say, of the whole project, by far the most rewarding part is just seeing people do weird stuff with it. Even seeing people explore the stuff that I know is there for the first time is pretty cool. Everybody at some point creates a spin-y bob thing and watches it go and is just like “What!?”
Did you have a go to market plan? I think I heard you say on Joshua’s channel (The Audio Programmer) that you didn’t super invest in marketing. But you did get on Hacker News twice!
My plan so far has been I don’t really want to invest a ton in marketing until I’m very confident in the product. I had some people on the mailing list. But I didn’t have a grand plan. What happened with the beta was I published it and started to get some sales.
And then the first YouTube video that happened about it was some review like, “A plugin you might not need.”
Hah, that’s so classic.
The first day was kind of exciting but the second day already the sales are dropping off. People are having technical issues. But on the second day, Mick Gordon just randomly out of the blue publishes a video that’s like the coolest thing I’ve ever seen anybody do with it. He fixed everything. So that was my go-to-market plan — just get super super lucky!
[laughs] Build something so awesome you can “just get lucky.” Anukari is very innovative. The underlying tech pushes the envelope for both DSP and UI. You must feel like there’s still a lot of room to innovate in audio instruments?
Innovation-wise, I have a lot I could say. My basic thesis is innovation is only possible if the thing that you’re doing might be awful. If there’s not some chance that what you’re making sucks and is the stupidest thing every, then I don’t think that innovation is possible.
There’s the form of innovation that’s incremental improvement. It has its place. If you work in the film industry and need a compressor that nails it every time and is predictable, incremental improvements to get there is good. That’s one type of innovation…
Another way of putting it: If you know for sure that the thing you’re building is going to succeed, it can’t be that interesting. Because how else would you know it’s going to succeed? You know it’s going to succeed because it’s similar enough and better than something else that exists.
So that’s my feeling: you can’t play it safe. If you want really new stuff, you have to take some degree of risk.
My basic thesis is innovation is only possible if the thing that you’re doing might be awful.
Evan Mezeske
Is that because experimentation and iteration is required to get anywhere meaningful? You have to be “traveling” and when you travel you don’t know what to expect?
I think you nailed it just with “not knowing what to expect.” If you know what to expect, by definition you are in charted territory. To me, really new creative stuff happens just by leaving charted territory. But you have to actually leave it in a way where you don’t know where you going to end up.
You don’t discover something by going five feet out from what is familiar. You discover something by parachuting into some new continent and being like “What’s here?”.
So maybe it’s an advantage to some degree that you self-describe as an outsider to the industry. You are coming from this angle of “Wait, this should be possible.” You’re not climbing a mountain that has already been summited. You’re not coming from a DSP background and adding one more layer.
I don’t think I could compete with that. If I went to one of those existing mountains and tried to solo dev the thing, I’m going to get my ass handed to me.
But also, my personality… the value I provided at Google a lot of the time was that I was the “bad ideas guy.” We’d be working on some difficult problem and I was the person who would ask, “Well, why don’t we just do this dumb thing?” And 80% of the time we’d talk about it for five minutes and be like, “Yeah, because it’s dumb.”
But 20% of the time we’d be like, “Well, can we just do that?” Like, “Okay if we wrap the whole thing in duct tape, that’s actually the best solution.”
I think, just being able to not filter the ideas too early. I worked in a lot of very experimental research-y type stuff. There’s this whole thing you have to get good at called “time boxing”. Like, “Okay, we’re going to do something real experimental, but we’re calling it in two weeks. If we can’t show some kind of interesting result, we stop. We do something else”.
Yeah. I was drawn to a completely different idea to additive synthesis at the start. One of those “beautiful ideas” that ended up very boring. It was based on the idea if you have two sine waves at slightly different frequencies, you create beating at a difference between the rates. I wanted to create a synth out of those beats, but it was too subtle to be musically fun.
That’s a really common type of thing I’ve seen in these types of explorations. You do that experiment and sure, you say, “This was not a success.” At Google, I would tell my reports an experimental failure is not a failure. If you did things right, you learned something from that.
You learned the beats thing is too subtle, but having tons of sine waves is interesting. So using those experimental results to help guide which direction you go in. And I feel that’s a way you get into uncharted territory.
You said in the interview with Joshua that you’re interested in doing more physics, right? A string is different from a spring, right?
Yeah, the funny thing about Anukari right now is in a lot of ways it’s really is doing something pretty simple: There’s this spring mass formula and you can connect a bunch of springs and masses and do a bunch of formulas. But ultimately it’s not that complicated.
But the thing I really think is cool about it is that you see what it’s doing, and it’s right there in front of you. And so strings are the kind of thing that I would love to do, but I don’t know how yet.
Like, visually?
Well, for me, I could think about ways to model a string physically. But like for it to in my mind fit into like what Anakari is trying to do, I would want the string to really be this kind of like physical thing. Visually, yes, but not just visually. The visual thing would have to correspond to some way of modeling a string that fits into that world.
Having like a string object, somehow it would need to work, it would need to be able to connect to springs and masses in like some kind of crazy, chaotic way. Like you can just connect a spring to the middle of the string. So yeah, that kind of thing would be really cool. I just don’t know yet how I want to fit it in.
Do you have any guiding principles UI-wise or usability-wise? You’re building in 3D and then have a JUCE graphics overlay, right?
Right. I remember when I was first working on modulation, I was struggling with it because there’s this cool 3D environment and then you go to a menu and there’s a table of information and it just didn’t feel right. For me, it was a big insight when I realized the connector from a modulator to the thing it controls could be a 3D connection.
I realized everything should be in the 3D world. Any kind of connection should be represented that way. And it’s a challenge because if you connect a modulator to 300 things, you get 300 lines and it’s kind of busy. Eventually maybe there’s a way to hide them.
Performance-wise, I’m curious. I saw you state you had to build your own physics engine because graphics engines are built for 60 or 240fps maximum — but why does the engine have to run at audio rate? Did you experiment with block sizes and determine the fidelity wasn’t good enough?
The way that the microphone picks up sound is literally based on the motion of one (or more) of the bodies. Ultimately, to be able to get a 10Khz frequency out of that, the body has to be able to move back and forth that rapidly. Physically the system is actually vibrating that quickly. All of those interactions are being simulated at that rate.
Gotcha! Another random tech question. Before this interview I was rushing to ship a version of my synth. I was juggling NANs and INFs and I’m wondering if on the GPU is that… nicer? Worse? Are there still NANs and INFs and cases where your data implodes?
Yeah, I mean that stuff is pretty similar. Anukari needs INFs on the GPU. That’s a design decision I may revisit, it does restrict the kinds of optimizations that you can allow the compiler to do. But I would say for the code that runs on the GPU, it’s pretty similar.
You know, the way you think about what’s happening and the code that runs the threads and synchronization — that’s all different. But if you just looked at the code for simulating a body or whatever, you would have no problem reading that code. So that stuff is pretty similar. But tuning it to get the best performance is a very different game.
That sounds more like a fun puzzle than on the CPU. On the CPU there’s only so many routes.
The GPU is just complicated. There’s parallelism within a thread group. NVIDIA has thread blocks. And then there’s broader parallelism. There’s different levels of memory and caching and the way that memory can be shared between threads. There’s SO many ways you could possibly arrange things. That’s good and bad because maybe one of them is good for you, but it’s bad because you can go off on tangents.
Yeah, it seems like you could be picking block sizes for a full month or something.
Totally. It’s sort of a similar problem to CPU stuff. Like, if you can arrange things in a way where the cache is working for you (and of course it varies by CPU and how big the cache is). On the GPU to some extent that’s easier because in a way you can kind of manually take over the L1 cache. It’s awesome if you have a problem where that’s an obvious solution. In Anukari’s case, it’s really clear that the mutable physics state all fits in L1 cache. And so it’s just put there. We’re not wondering where it is.
But yeah, NANs and INFs — just as much of a problem.
Okay, I just wanted to make sure we shared similar pain [laughs].
Yeah, it’s horrible. [laughs]
So, last question — given all this investment, do you imagine doing other GPU-based instruments down the line?
When I set out to leave Google, I wrote up a list of things that I might do in the plugin space to convince myself that I wanted to leave.
Probably because I’m a performance geek, I do gravitate to things that are super computationally expensive. One of the ideas I have is some kind of fluid dynamics simulation — something where there’s a viscous liquid. And I’ve got some ideas on how you might get audio out of that.
Evan was interviewed by Sudara from melatonin.dev.
Have comments on this interview? Ideas for who we should talk to next? Let us know on the JUCE forum.