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

The impact of Apple Silicon Macs on Broadway

brianli.com

Post reply on HN
Print view View original

171–180 of 294 posts

Re: The impact of Apple Silicon Macs on Broadway

#171

Post by marcan_42 »

kevingadd wrote: post #71
marcan_42 wrote: post #43

They're going to have to wait until the synth industry gets their act together and ports to Apple Silicon though. The DAW/music ecosystem is notoriously bad at these kinds of transitions. Due to how VSTs work, if any of your plug-ins are not ARM compatible, you have to run the whole plug-in host and all plug-ins under Rosetta, with the performance drop and stability compromises that that entails. And a lot of plug-in…

Couldn't you run a VST host in the Rosetta environment for your x86 VSTs and run everything else native in ARM in a separate host? Or does the VST model require that all the VSTs loaded run synchronously within a single process?

It's possible, but it would have to be a built-in feature of the DAW to be convenient, and could seriously compromise performance even if optimized.

Let's assume an ideal implementation where there is only one process per architecture. Take a 100 track project with two plug-ins per track (say, compressor and EQ). If the compressor is x86 and the EQ is ARM, that's 200 context switches per audio period. That makes it impossible to run at small buffer sizes. A very smart flowgraph implementation could attempt to batch everything into the minimum number of context switches, but that has other problems with threading. It's very hard to get this perfect.

This solution works fine for when you just have a few straggler plug-ins of the wrong architecture, but it would still require quite complex engineering by the DAW to make it work transparently to the user. Consider, for example, that the plug-in UI needs to embed in the DAW across a process boundary.

Re: The impact of Apple Silicon Macs on Broadway

#173

Post by PaulDavisThe1st »

rock_artist wrote: post #128
EamonnMR wrote: post #111

Earlier quoted context omitted.

Saying that synth makers need to 'get their act together' is a bit unfair. Nobody asked Apple to invalidate all binaries, they just went ahead and did it.

I work for an audio company. Indeed, that's unfair. Unlike the PPC to Intel transition. This time it's a little easier since most modern toolsets require much less changes in code. Having said that some consideration to keep in mind: - audio code needs to be optimized for real time thread constrains. Many optimizations usually made by vectorizing rather than threading that would've lead to locks and synchronization n…

We've already released a "test" build of Ardour for M1. Because we already support Linux on ARM, it was relatively trivial - the main work was getting our build stack to compile first. Other than that, it just works. The same codebase supports Linux, Windows and macOS/OSX back to 10.8 and PPC.

Re: The impact of Apple Silicon Macs on Broadway

#174

Post by PaulDavisThe1st »

ratww wrote: post #116
kevingadd wrote: post #71

Earlier quoted context omitted.

Couldn't you run a VST host in the Rosetta environment for your x86 VSTs and run everything else native in ARM in a separate host? Or does the VST model require that all the VSTs loaded run synchronously within a single process?

It doesn't require everything to be on the same process, it's just how DAWs are implemented today. There are alternatives, like the bridges mentioned by the sibling post, but it's clunky and manual to setup and slows down your workflow.

It's a bit more than "just how DAWs are implemented today"

https://ardour.org/plugins-in-process.html

Re: The impact of Apple Silicon Macs on Broadway

#175

Post by PaulDavisThe1st »

20 years ago, the audio software industry could have decided to support Linux. Some notable players in the industry tried to convince others to do this (e.g. Waves). It didn't work.

Plugin makers, DAW makers all refused to go down that path, despite the possibility of liberating their highly complex, deeply technical products from the whims of Redmond and Cupertino.

At that time, Linux already had better latency than OS X or Windows. It would have provided access to faster, bigger systems than anything you could run OS X or Windows on, and access to ARM "early" too. The industry could have actually convinced people that they need specialized computers, not off-the-shelf laptops and desktops to do this stuff (still largely true). But more or less nobody wanted to play.

And now, in 2020/2021, just as when the PPC->Intel shift happened under Jobs, because Apple tells them all to dance, they will.

It's sort of pathetic, even if all "understandable" from various points of view.

Re: The impact of Apple Silicon Macs on Broadway

#176

Post by PaulDavisThe1st »

vultour wrote: post #162
avianlyric wrote: post #151

Earlier quoted context omitted.

My understanding of this has been that OSX has always had much lower audio latency than Windows or Linux. Apple have put quite a bit of effort into making their audio sub-systems both performant and reliable. Something that isn’t true on Windows and Linux at the moment. I also assume that part of if is driven by audio professionals using Macs elsewhere, and you don’t want to be using an unfamiliar system when running…

Does Mac have a built-in low latency system? The Windows ones are terrible but I don't think anyone would use them anyway when there is ASIO.

It does. CoreAudio gets the job done.

Re: The impact of Apple Silicon Macs on Broadway

#177

Post by ksm1717 »

vimy wrote: post #160
dagmx wrote: post #154

Earlier quoted context omitted.

I believe they mean performance drop versus native. Let's say you have a DAW with ARM and x86 binaries but a VST/AU/RTAS that's x86 only. You need to run the DAW as x86 under Rosetta, which will result in reduced performance versus a native binary, assuming the native processor was capable of equal performance. Given how zippy the M1 is, that performance penalty may well still put you ahead of where your x86 perf was…

That’s what I’m saying. There is no performance drop compared to x86 macs, the M1 is _that_ fast.

Well if it’s just as fast, what is there to be excited about?

Re: The impact of Apple Silicon Macs on Broadway

#178

Post by rubatuga »

PaulDavisThe1st wrote: post #175

20 years ago, the audio software industry could have decided to support Linux. Some notable players in the industry tried to convince others to do this (e.g. Waves). It didn't work. Plugin makers, DAW makers all refused to go down that path, despite the possibility of liberating their highly complex, deeply technical products from the whims of Redmond and Cupertino. At that time, Linux already had better latency than…

Linux audio support is not good. Macs have much better audio support.

Re: The impact of Apple Silicon Macs on Broadway

#179

Post by PaulDavisThe1st »

rubatuga wrote: post #178
PaulDavisThe1st wrote: post #175

20 years ago, the audio software industry could have decided to support Linux. Some notable players in the industry tried to convince others to do this (e.g. Waves). It didn't work. Plugin makers, DAW makers all refused to go down that path, despite the possibility of liberating their highly complex, deeply technical products from the whims of Redmond and Cupertino. At that time, Linux already had better latency than…

Linux audio support is not good. Macs have much better audio support.

I've been at the heart of Linux audio for more than 20 years.

The situation on Linux is not "not good". Most people who comment on it simply don't know what they are talking about.

It is fair to say that Macs are easier to get good results with.

Re: The impact of Apple Silicon Macs on Broadway

#180

Post by mrpippy »

rock_artist wrote: post #128
EamonnMR wrote: post #111

Earlier quoted context omitted.

Saying that synth makers need to 'get their act together' is a bit unfair. Nobody asked Apple to invalidate all binaries, they just went ahead and did it.

I work for an audio company. Indeed, that's unfair. Unlike the PPC to Intel transition. This time it's a little easier since most modern toolsets require much less changes in code. Having said that some consideration to keep in mind: - audio code needs to be optimized for real time thread constrains. Many optimizations usually made by vectorizing rather than threading that would've lead to locks and synchronization n…

I believe Xcode 12 can only target back to 10.9. (Xcode throws an error when you try to go older, I think the command-line tools can still go back farther though)
Post reply on HN