Hacker News: humbledrone

Despite enjoying your idea, I probably won't do that, but certainly anyone who actually has this same problem should reach out to me and I'll put them in touch with the right folks at Apple, who can share the info.

New comment by humbledrone in "An appeal to Apple from Anukari"

humbledrone — Tue, 06 May 2025 23:46:56 +0000

Hey everyone, it worked, I had a super productive conversation with exactly the right person on the Metal team! Thanks for helping me get Apple's attention. I didn't at all expect this amount of support.

https://anukari.com/blog/devlog/productive-conversation-appl...

New comment by humbledrone in "An appeal to Apple from Anukari"

humbledrone — Tue, 06 May 2025 20:02:09 +0000

I attempted to preempt your question in the section of my blog post, "Why don’t you just pipeline the GPU code so that it saturates the GPU?" It's one of the less-detailed sections though so maybe you have further questions? I think the main thing is that since Anukari processes input like MIDI and audio data in real-time, it can't work ahead of the CPU, because those inputs are not available yet.

Possibly what you describe is a bit more like double-buffering, which I also explored. The problem here is latency: any form of N-buffering introduces additional latency. This is one reason why some gamers don't like triple-buffering for graphics, because it introduces further latency between their mouse inputs and the visual change.

But furthermore, when the GPU clock rate is too low, double-buffering or pipelining don't help anyway, because fundamentally Anukari has to keep up with real time, and every block it processes is dependent on the previous one. With a fully-lowered GPU clock, the issue does actually become one of throughput and not just latency.

New comment by humbledrone in "An appeal to Apple from Anukari"

humbledrone — Tue, 06 May 2025 19:21:26 +0000

It's a real-time audio app, so if it falls behind real time, no audio. You get cracks, pops, and the whole thing becomes unusable. If the user is doing audio at 48 kHz, the required latency is 1/48,000 seconds per sample, or realistically somewhat less than that to account for variance and overhead.

New comment by humbledrone in "An appeal to Apple from Anukari"

humbledrone — Tue, 06 May 2025 19:15:52 +0000

1. Anukari runs up to 16 entire copies of the physics model for polyphony, so 16 * 1024 * 48K (I should update the blog post)

2. Users can arbitrarily connect objects to one another, so each object has to read connections and do processing for N other entities

3. Using the full CPU requires synchronization across cores at each physics step, which is slow

4. Processing per object is relatively large, lots of transcendentals (approx OK) but also just a lot of features, every parameter can be modulated, needs to be NaN-proof, so on

5. Users want to run multiple copies of Anukari in parallel for multiple tracks, effects, etc

Another way to look at it is: 4 GHz / (16 voice * 1024 obj * 4 connections * 48,000 sample) = 1.3 cycles per thing

The GPU eats this workload alive, it's absolutely perfect for it. All 16 voice * 1024 obj can be done fully in parallel, with trivial synchronization at each step and user-managed L1 cache.

New comment by humbledrone in "An appeal to Apple from Anukari"

humbledrone — Tue, 06 May 2025 18:55:15 +0000

Thanks for the thought, unfortunately when running as a plugin Anukari is subject to whatever plist.txt the host application uses. I think that I did try that with the standalone binary at one point, but unfortunately I did not appear to take notes! That probably means I did not have success.

New comment by humbledrone in "Show HN: I built a synthesizer based on 3D physics"

humbledrone — Tue, 06 May 2025 03:57:26 +0000

For anyone seeing this post a bit late: I need a bit of help from someone inside Apple who works on Metal. If you know someone, it would be great if you could connect me to them:

https://news.ycombinator.com/item?id=43901619

https://anukari.com/blog/devlog/an-appeal-to-apple

New comment by humbledrone in "An appeal to Apple from Anukari"

humbledrone — Tue, 06 May 2025 03:40:10 +0000

Some folks may have seen my Show HN post for Anukari here: https://news.ycombinator.com/item?id=43873074

In that thread, the topic of macOS performance came up there. Basically Anukari works great for most people on Apple silicon, including base-model M1 hardware. I've done all my testing on a base M1 and it works wonderfully. The hardware is incredible.

But to make it work, I had to implement an unholy abomination of a workaround to get macOS to increase the GPU clock rate for the audio processing to be fast enough. The normal heuristics that macOS uses for the GPU performance state don't understand the weird Anukari workload.

Anyway, I finally had time to write down the full situation, in terrible detail, so that I could ask for help getting in touch with the right person at Apple, probably someone who works on the Metal API.

Help! :)

An appeal to Apple from Anukari

humbledrone — Tue, 06 May 2025 03:40:10 +0000

Article URL: https://anukari.com/blog/devlog/an-appeal-to-apple

Comments URL: https://news.ycombinator.com/item?id=43901619

Points: 405

# Comments: 188