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! :)
bambax · 3h ago
> This is going to be a VERY LONG HIGHLY TECHNICAL post, so either buckle your seatbelt or leave while you still can.
Well, I read it all and found it not too long, extremely clear and well-written, and informative! Congrats on the writing.
I've never owned a Mac and my pc is old and without a serious GPU, so it's unlikely that I'll get to use Anukari soon, but I regret it very much, as it looks sooo incredibly cool.
Hope this gets resolved fast!
TheAceOfHearts · 3h ago
I missed the Show HN, but the first thing that came to mind after seeing it was that this looks like it would lend itself well to making some very creative ASMR soundscapes with immersive multidimensional audio. I selfishly hope you or one of your users will make a demo. Congrats on the project and I hope you receive help on your Apple issues.
aplummer · 4h ago
Have you filed a feedback? Seems like the right next step.
bayindirh · 4h ago
The post opens with the following TL;DR:, snipped for brevity:
> It would be great if someone can connect me with the right person inside Apple, or direct them to my feedback request FB17475838 as well as this devlog entry.
sgerenser · 13m ago
Feedbacks often go into a black hole unless either:
1. A bunch of people file effectively the same bug report (unlikely here)
2. An individual Apple employee champions the issue internally
3. Someone makes a fuss on Twitter/X and it starts to go viral
Sounds like the OP is trying to get #2 to happen, which is probably his best bet.
Dlemo · 1h ago
Your topic is neither long nor very technical btw.
CPU/GPU clocking is neither complicated or new.
mensetmanusman · 17m ago
It’s technical to over half of programmers who don’t need to know these types of details about hw/sw interactions.
LiamPowell · 3h ago
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.
JimDabell · 2h ago
The article mentions game mode, which is a feature of the latest Apple operating systems that is optimised for cases like this. Game mode pops up a notification when it’s enabled, which most applications wouldn’t want to happen. So far I haven’t seen anything abuse it.
grishka · 2h ago
There already is an unending number of ways for just one app to waste charge on battery-powered devices. It all already relies on developers not unnecessarily running energy-intensive tasks, either intentionally or accidentally. Adding one more API that has the potential to waste energy if not used appropriately will not change that.
madeofpalk · 1h ago
macOS also has a bunch of mechanisms to inform the user about this! IIRC the battery menu has entries for apps draining a lot of power (iterm always shows up there for me!)
nottorp · 1h ago
Manual permission? Maybe hidden somewhere, it's probably necessary for very niche apps.
And default deny at the OS level for Zoom, Teams and web browsers :)
krackers · 3h ago
>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.
bambax · 3h ago
There has to be a private API for this; the post says:
> 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.
How would the Metal profiler be able to do that if not for a private API? (Could some debugging tool find out what's going on by watching the profiler?)
sgt · 46m ago
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.
threeseed · 1h ago
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.
Hnrobert42 · 1h ago
Or his brother Pichael at pthomson.
Someone · 2h ago
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?
That's more like "I had to trick the OS into thinking that spacebar was held for my application to run at all".
charcircuit · 23m ago
>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.
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! :)
Well, I read it all and found it not too long, extremely clear and well-written, and informative! Congrats on the writing.
I've never owned a Mac and my pc is old and without a serious GPU, so it's unlikely that I'll get to use Anukari soon, but I regret it very much, as it looks sooo incredibly cool.
Hope this gets resolved fast!
> It would be great if someone can connect me with the right person inside Apple, or direct them to my feedback request FB17475838 as well as this devlog entry.
Sounds like the OP is trying to get #2 to happen, which is probably his best bet.
CPU/GPU clocking is neither complicated or new.
And default deny at the OS level for Zoom, Teams and web browsers :)
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.
> 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.
How would the Metal profiler be able to do that if not for a private API? (Could some debugging tool find out what's going on by watching the profiler?)
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.
Is that a limitation of the audio plug-in APIs?
>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.