from Hacker News

An appeal to Apple from Anukari

by humbledrone on 5/6/25, 3:40 AM with 188 comments

  • by humbledrone on 5/6/25, 3:40 AM

    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! :)

  • by humbledrone on 5/6/25, 11:46 PM

    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...

  • by AJRF on 5/6/25, 3:09 PM

    I’ve worked in two high profile companies with very prominent apps on the Apple App Store.

    The team we talked to at Apple never ever cared about our problems, but very often invited us to their office to discuss the latest feature they were going to announce at WWDC to strong arm us into supporting it. That was always the start and stop of their engagement with us. We had to burn technical support tickets to ever get any insight into why their buggy software wasn’t working.

    Apples dev relations are not serious people.

  • by krackers on 5/6/25, 8:03 AM

    >The Metal profiler has an incredibly useful feature: it allows you to choose the Metal “Performance State” while profiling the application. This is not configurable outside of the profiler.

    Seems like there might be a private API for this. Maybe it's easier to go the reverse engineering route? Unless it'll end up requiring some special entitlement that you can't bypass without disabling SIP.

  • by LiamPowell on 5/6/25, 8:44 AM

    The problem with exposing an API for this is that far too many developers will force the highest performance state all the time. I don't know if there's really a good way to stop that and have the API at the same time.
  • by threeseed on 5/6/25, 9:58 AM

    Best way to do this:

    1. Go through WWDC videos and find the engineer who seems the most knowledgable about the issue you're facing.

    2. Email them directly with this format: mthomson@apple.com for Michael Thomson.

  • by vessenes on 5/6/25, 3:11 PM

    Side note: Anukari should put out a Mick Gordon sound pack and share revs with him. That dude is making some crazy crazy stuff; his demo is awesome. Pairing up with artists once you have such a strong tool is good business and good for the world. If you like Mick Gordon. Which I do.
  • by sgt on 5/6/25, 11:10 AM

    I have zero need for this app but it's so cool. Apps like these bring the "fun" back into computing. I don't mean there's no fun at the moment, but reminds me of the old days with more graphical and experimental programs that floated around, even the demoscene.
  • by philsnow on 5/6/25, 8:12 PM

    Don't miss the link thrown in the second to last paragraph to https://x.com/Mick_Gordon/status/1918146487948919222 , a demo Mick Gordon put together, to which @anukarimusic replied

    > Lol on the second day it's out, you have already absolutely demolished all of the demos I've made with it and I've used it every day for two years

  • by phkahler on 5/6/25, 4:32 PM

    1024 objects updating at 48khz seems possible on the CPU - depending how the code is written. 48M updates per second? It seems like a possible use for OpenMP to run a few loops in parallel across cores.
  • by Someone on 5/6/25, 9:51 AM

    One thing I don’t understand: if latency is important for this use case, why isn’t the CPU busy preparing the next GPU ‘job’ while a GPU ‘job’ is running?

    Is that a limitation of the audio plug-in APIs?

  • by jonas21 on 5/6/25, 4:42 PM

    I'm having trouble understanding what the problem is -- as in, what are the actual symptoms that users are seeing? How much latency can the app tolerate and how much are you seeing in practice? It would be helpful (to me at least) in thinking about potential solutions if that information were available up front.

    Perhaps there's something in this video that might help you? They made a lot of changes to scheduling and resource allocation in the M3 generation:

    https://developer.apple.com/videos/play/tech-talks/111375/

  • by charcircuit on 5/6/25, 11:33 AM

    >Any MTLCommandQueue managed by an Audio Workgroup thread could be treated as real-time and the GPU clock could be adjusted accordingly.

    >The Metal API could simply provide an option on MTLCommandQueue to indicate that it is real-time sensitive, and the clock for the GPU chiplet handling that queue could be adjusted accordingly.

    Realtime scheduling on a GPU and what the GPU is clocked to are separate concepts. From the article it sounds like the issue is with the clock speeds and not how the work is being scheduled. It sounds like you need something else for providing a hint for requesting a higher GPU clock.

  • by dgs_sgd on 5/6/25, 6:38 PM

    > in parallel with the audio computation on the GPU, Anukari runs a second workload on the GPU that is designed to create a high load average and trick macOS into clocking up the GPU. This workload is tuned to use as little of the GPU as possible, while still creating a big enough artificial load to trigger the clock heuristics.

    That's quite the hack and I feel for the developers. As they state in the post, audio on the GPU is really new and I sadly wouldn't be holding my breath for Apple to cater to it.

  • by PaulHoule on 5/6/25, 2:40 PM

    It's an interesting trade-off. For decades the answer to having a reliable Windows computer has been to turn off as many power saving features as possible. Saving power on USB plugs for instance makes your machine crash. Let your CPU state drop to the minimum and you'll find your $3000 desktop computer takes about a second to respond to keypresses. Power savings might not be real, but the crashes and poor performance are very real.
  • by chrismorgan on 5/7/25, 9:54 AM

    > (An aside: chalkboards are way better than whiteboards, unless you enjoy getting high on noxious fumes. in which case whiteboards are the way to go.)

    That looks to be a smoother chalkboard than I’ve ever encountered. If I had been using such chalkboards, I suspect I’d agree, but based purely on my experiences to this point, my opinion has been that chalkboards are significantly better for most art due to finer control and easier and more flexible editing, but whiteboards are better for most teaching purposes (in small or large groups), mostly due to higher contrast. But there’s a lot of variance within both, and placement angles and reflection characteristics matter a lot, as do the specific chalk, markers and ink you use.

  • by ramesh31 on 5/6/25, 2:39 PM

    Be careful what you wish for here. Knowing Apple, they will stonewall any API requests, and may very well shut your app out for the private API workarounds described.
  • by rock_artist on 5/6/25, 8:39 PM

    While very different, it was already tricky in the past to make Apple silicon (on iPhones as well) perform reasonable.

    Ableton engineers already evaluated this in the past: https://github.com/Ableton/AudioPerfLab

    While I feel for the complaints about the Apple lack of "feedback assiting" The core issue itself is very tricky. Many years ago, before being an audio developer, I've worked in a Pro Audio PC shop...

    And guess what... interrupts, abusive drivers (GPUs included) and Intels SpeedStep, Sleep states, parking cores... all were tricky.

    Fast forward, We got asymmetric CPUs, arm64 CPUs and still Intel or AMDs (especially laptops) might need bios tweaks to avoid dropouts/stutters.

    But if there's a broken driver by CPU or GPU... good luck reporting that one :)

  • by notnullorvoid on 5/6/25, 7:07 PM

    Sorry to hear about the issue, not too surprising given Apples track record with this kind of thing though (You still can't even pin processes to specific CPU core/threads). Anukari is really cool though, wish you had a Linux build :)
  • by thraway3837 on 5/6/25, 1:31 PM

    This is all just too much Stockholm syndrome. Apple’s DX (developer experience) has always been utterly abysmal, and these continued blog posts just goes to show just how bad it is.

    Proprietary technologies, poor or no documentation, silent deprecations and removals of APIs, slow trickle feed of yearly WWDC releases that enable just a bit more functionality, introducing newer more entrenched ways to do stuff but still never allowing the basics that every other developer platform has made possible on day 1.

    A broken UI system that is confusing and quickly becomes undebuggable once you do anything complex. Replaces Autolayout but over a decade of apps have to transition over. Combine framework? Is it dead? Is it alive? Networking APIs that require the use of a 3rd party library because the native APIs don’t even handle the basics easily. Core data a complete mess of a local storage system, still not thread safe. Xcode. The only IDE forced on you by Apple while possibly being the worst rated app on the store. Every update is a nearly 1 hour process of unxipping (yes, .xip) that needs verification and if you skip it, you could potentially have bad actors code inject into your application from within a bad copy of Xcode unbeknownst to you. And it crashes all the time. Swift? Ha. Unused everywhere else but Apple platforms. Swift on server is dead. IBM pulled out over 5 years ago and no one wants to use Swift anywhere but Apple because it’s required.

    The list goes on. Yet, Apple developers love to be abused by corporate. Ever talk to DTS or their 1-1 WWDC sessions? It’s some of the most condescending, out of touch experience. “You have to use our API this way, and there’s this trick of setting it to this but then change to that and it’ll work. Undocumented but now you know!”

    Just leave the platform and make it work cross platform. That’s the only way Apple will ever learn that people don’t want to put up with their nonsense.

  • by Liftyee on 5/7/25, 12:27 AM

    Out of curiosity, what's the origin of the Anukari name?
  • by SOLAR_FIELDS on 5/6/25, 11:04 AM

    https://xkcd.com/1172/ feels a lot like the workaround OP describes
  • by throwaway48476 on 5/6/25, 5:13 PM

    Another 'appeal to the tsar'?