Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An appeal to Apple from Anukari

anukari.com

Post reply on HN
Print view View original

131–140 of 197 posts

Re: An appeal to Apple from Anukari

#131

Post by kllrnohj »

Someone wrote: post #38
kllrnohj wrote: post #28

Earlier quoted context omitted.

That's pipelining and it's good for throughput but it sacrifices latency. Audio is not a continuous bit stream but a series of small packets. To begin working on the next one on the CPU while the previous one is on the GPU requires 2 samples in flight which necessarily means higher latency

I don’t see that. If the CPU part starts processing packet #2 while the GPU processes packet #1, not after it has done so, it will have the data that has to be sent to the GPU for packet #2 ready earlier, so it can send it earlier, potentially the moment the GPU has finished processing packet #1 (if the GPU is powerful enough, possibly even before that) That’s why I asked about the plug-in APIs. They may have to be a…

You're requiring that packet #2 be available before packet #1 has finished. That's higher latency than the goal, which is packet #1 is processed & sent to output before packet #2 has arrived at all.

Or perhaps you're missing that there's an in event as part of this, like a MIDI instrument? It's an in->effect->out sequence. So minimizing latency means that the "effect" part must be as small as possible, which means it's desired for it to happen faster than "in" can feed it data

Re: An appeal to Apple from Anukari

#132

Post by eikenberry »

duped wrote: post #37
thraway3837 wrote: post #30

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 stil…

I don't disagree with you, but there simply isn't an alternative for pro audio developers. You go where the users are and the majority of the market (by revenue) are Mac users. Now a lot of people may reply to this that Windows isn't that bad with ASIO (third party driver framework) or modern APIs like WASAPI (which is still lacking), or how pipewire is changing things on Linux so you don't need jack anymore (but god…

> (but god forbid, you want to write pipewire native software in a language besides C, since the only documented API are macros)

I've read that Zig can wrap C macros. So maybe there is some hope.

Re: An appeal to Apple from Anukari

#133

Post by 4ndrewl »

gjsman-1000 wrote: post #72
4ndrewl wrote: post #71

Earlier quoted context omitted.

[flagged]

Even Wikipedia says Whataboutism can be completely deserved in some cases. It is absolutely deserved here - Apple built a 100 foot tower, and it's grown hairy over the last few decades. Linux built 7 30 foot towers without stairs in the same timeframe; but yelling about the overgrowth on the 100 foot tower is still somehow defensible. If they can't build their own towers correctly, they have no right to act like the…

> If they can't build their own towers correctly, they have no right to act like the main tower was built worse than their own.

And yet OP did.

Re: An appeal to Apple from Anukari

#134

Post by Suppafly »

pjmlp wrote: post #39
eigenspace wrote: post #31

Earlier quoted context omitted.

It's honestly nuts that so many developers continue to try to make software on MacOS. I understand the appeal of their current hardware, and I used to even be a big fan of the user experience, but it really seems like attempting to build software in MacOS is like trying to build a house on a sandbar. Apple has done nothing and continues to do nothing to engender any confidence in their platform as a development targe…

It is still better engineered that dealing with the distribution of the day, reinventing the way to do sound, graphics stack, UI, ...... Once upon a time I thought either GNOME or KDE would win, and we could all enjoy the one Linux distribution, I was proven wrong. Then again, I have been back on Windows as main OS since Windows 7.

>Once upon a time I thought either GNOME or KDE would win, and we could all enjoy the one Linux distribution, I was proven wrong.

Linux users don't want one to win. As soon as one gained any traction, the users would switch just for the sake of it. It's also crazy how neither ever actually improves because they are so focused on copying whatever windows and mac are doing instead of continuously improving. The linux desktop experience isn't any better now than it was 20 years ago.

Re: An appeal to Apple from Anukari

#135

Post by krackers »

duped wrote: post #43
LiamPowell wrote: post #7

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.

Developers aren't (yet) abusing audio workgroups for all their thread pools to get pcore scheduling and higher priority. So it would imply that if an audio workgroup is issuing commands to the GPU there should be some kind of timeout to the GPU downclocking based on the last time a workgroup sent data to it. GPU audio is extremely niche these days, but with the company mentioned in TFA releasing their SDK recently it…

I'm not too familiar with audio workgroups but since the early days XNU had low-level APIs to set pthreads as pseudo-realtime

Re: An appeal to Apple from Anukari

#136

Post by betterThanTexas »

bigyabai wrote: post #111
betterThanTexas wrote: post #78

Earlier quoted context omitted.

People complaining about whataboutism are more obstinately committed to avoiding decent conversation than the people who commit it. This ain’t a formal debate.

[flagged]

Formal in what sense? There's certainly no set form for discussion outside of threading. But there's certainly no assumption of persuasion or sense of shared goals or values.

Re: An appeal to Apple from Anukari

#137

Post by atonse »

overfeed wrote: post #120
duped wrote: post #37

Earlier quoted context omitted.

I don't disagree with you, but there simply isn't an alternative for pro audio developers. You go where the users are and the majority of the market (by revenue) are Mac users. Now a lot of people may reply to this that Windows isn't that bad with ASIO (third party driver framework) or modern APIs like WASAPI (which is still lacking), or how pipewire is changing things on Linux so you don't need jack anymore (but god…

> I don't disagree with you, but there simply isn't an alternative for pro audio developers People used to say this about video pros too, until Apple royally screwed the pooch by failing to refresh its stale Mac Pro hardware lineup for many years, followed by a lackluster Final Cut release. An entire industry suddenly realized Windows was viable after all, they just hadn't bothered to look.

But they had to be pushed in that direction. IT actually affected their work.

In this case, the users of these tools seem perfectly ok with them and aren't going to just explore something as disruptive as an entirely different OS just for kicks.

Re: An appeal to Apple from Anukari

#138

Post by dgs_sgd »

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

Re: An appeal to Apple from Anukari

#139

Post by overfeed »

atonse wrote: post #137
overfeed wrote: post #120

Earlier quoted context omitted.

> I don't disagree with you, but there simply isn't an alternative for pro audio developers People used to say this about video pros too, until Apple royally screwed the pooch by failing to refresh its stale Mac Pro hardware lineup for many years, followed by a lackluster Final Cut release. An entire industry suddenly realized Windows was viable after all, they just hadn't bothered to look.

But they had to be pushed in that direction. IT actually affected their work. In this case, the users of these tools seem perfectly ok with them and aren't going to just explore something as disruptive as an entirely different OS just for kicks.

Not sure why you started off with "but" when we are in agreement and/or you're not disputing my point - that Windows is viable but the Mac-using audio professional aren't (yet) sufficiently motivated to seriously evaluate Windows as a migration target.

> In this case, the users of these tools seem perfectly ok with them

That wasn't my takeaway from the article. The plugin is outright broken on the latest hardware, even with the workaround.

> [...]something as disruptive as an entirely different OS just for kicks

I don't think switching OSes is less disruptive than switching software packages. Cubase or Ableton on Windows is not much different from the respective DAWs on Mac OS. Modern desktop OS UI paradigms map 1:1, so switching isn't a big deal

Re: An appeal to Apple from Anukari

#140

Post by Archit3ch »

duped wrote: post #43
LiamPowell wrote: post #7

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.

Developers aren't (yet) abusing audio workgroups for all their thread pools to get pcore scheduling and higher priority. So it would imply that if an audio workgroup is issuing commands to the GPU there should be some kind of timeout to the GPU downclocking based on the last time a workgroup sent data to it. GPU audio is extremely niche these days, but with the company mentioned in TFA releasing their SDK recently it…

> if you're doing thing on GPU you're saying you don't care about latency

This does not follow. Evidently it is possible to have low-latency audio processing on the GPU today (per the SDK).

Post reply on HN