An appeal to Apple from Anukari

Apple feedback, escalation, and process

• Several comments say filing Feedback (radar) is necessary but often ineffective unless:
  • Many devs report the same bug,
  • An internal engineer champions it, or
  • The issue becomes public/viral.
• People suggest:
  • Booking WWDC lab time to reach the right Metal engineers.
  • Identifying knowledgeable engineers from WWDC talks and emailing them directly.
• Later in the thread, the author reports a “super productive” conversation with a Metal engineer, apparently yielding short‑term hints but no shareable technical details, reinforcing the “undocumented trick” criticism.

GPU performance-state control and hacks

• The blog’s key issue: macOS GPU clock heuristics don’t recognize low‑latency audio workloads, forcing a “spin” workload to trick the GPU into higher clocks.
• Multiple commenters infer there must be a private API (used by Xcode’s Metal profiler and Game Mode) to set GPU performance state.
• Some propose:
  • Reverse‑engineering the profiler,
  • A public entitlement or API to mark Metal queues as real‑time,
  • Or routing GPU work through a separate daemon for more control.
• Others warn that exposing a simple “max GPU clock” API could be abused, though counter‑arguments note:
  • Apps can already waste power with busy‑loops,
  • macOS surfaces power‑hungry apps to users,
  • Game Mode’s full‑screen + notification model limits abuse.

Real-time audio, latency, and pipelining

• Discussion dives into why naive pipelining or double‑buffering doesn’t fix the problem:
  • Real‑time audio is stateful and packetized; processing “buffer N+1” before N is finished either introduces extra latency or races.
  • Audio callbacks run against strict device buffer deadlines; missed deadlines cause crackles and dropouts.
• There’s back‑and‑forth about:
  • How much end‑to‑end latency users can perceive (sub‑5 ms vs more),
  • Whether CPU could handle the workload instead of the GPU.
• The author explains the scale: many voices × many objects × arbitrary interconnections with expensive math and per‑parameter modulation, yielding only a few CPU cycles per “thing”; GPUs fit this parallelism much better.

Apple ecosystem and developer experience

• A large subthread debates Apple’s overall DX:
  • Strong criticism: proprietary tech, weak/vanishing docs, unstable frameworks, Xcode bloat/fragility, platform lock‑in (including ToS against cross‑compilation), and difficulty shipping pro audio apps.
  • Others push back:
    • macOS/iOS users pay for software; revenue can justify the pain.
    • Compared to historical embedded/mobile work, Apple’s platforms are still relatively pleasant.
    • Many other platforms (Windows, Linux desktop) also have serious API, documentation, and stability issues.
• Some audio developers say macOS still dominates their revenue; others claim Windows (with ASIO) or even Linux are now viable for pro and live audio.
• One comment describes abandoning a macOS pro‑audio app and moving to USB hardware to escape OS constraints and App Store policies.

Power management vs performance

• Broader discussion notes that all modern platforms struggle to balance power saving with low‑latency real‑time workloads.
• Examples range from Windows machines needing power‑saving features disabled to avoid lag, to historic issues with interrupts and CPU sleep states.
• Many see Anukari’s “fake load” workaround as a symptom of overly opaque, heuristic‑driven power management without adequate real‑time hints.

Community reaction

• Many commenters praise the technical clarity of the post and the originality of Anukari, even from people who can’t run it.
• Some speculate about creative uses (e.g., ASMR, complex soundscapes) and suggest artist collaborations.
• Others are pessimistic about Apple prioritizing such a niche GPU‑audio use case, but the eventual successful contact with Metal engineering is taken as a small positive outcome.