10 ms·

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

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 makers are going to want you to pay for an upgrade to the latest version that is released with ARM support. That said, 4-5 years down the line when this whole transition is over on macOS, it's going to be great. And for anything not relying on live synth/processing, you don't need many/any plug-ins at all, so that'll work well today. Personally, I'm really looking forward to doing real-time / live audio set-ups on my M1 Macs under Linux as soon as next year. The design of the M1, beyond just performance, is almost certainly much better than any x86 box for real-time processing, and likely capable of much lower latencies (due to x86 junk like SMBIOS and their power management approach killing worst case latencies; x86 can't match ARM embedded systems for real-time stuff, but M1 is from the embedded world). And since it's Linux, all the open source stuff is already ported to ARM, and the wine hack I use to run a few Windows VSTs ought to be compatible with shoving them under qemu-user without disturbing the rest of the set-up.

kevingadd 6y ago
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?
- TylerE 6y ago
  It’s within one process. There are ways to bridge it but basically you have a native plugin shim that talks to a process running the target arch and essentially passes protocol messages back and forth. Was common for a while on windows when many plugins were 32bit only and wouldn’t run in a 64 bit host
- ratww 6y ago
  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.
  - PaulDavisThe1st 6y ago
    It's a bit more than "just how DAWs are implemented today" https://ardour.org/plugins-in-process.html https://ardour.org/plugins-in-process.html
- marcan_42 6y ago
  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.
dingaling 6y ago
> They're going to have to wait until the synth industry gets their act together and ports to Apple Silicon though. Why is it their responsibility? Apple has literally billions in the bank, they should be running an incentive scheme if they want more native ports. This reminds me of people complaining that Docker doesn't run on Apple ARM yet. Why should it? Apple are the ones that changed the architecture.
- Sholmesy 6y ago
  It's naive to think that Apple needs Docker more than Docker needs Apple. If Docker didn't support Apple devices going forward, they would lose a significant amount of users. If Apple doesn't support docker going forward, they lose a tiny percentage point. That being said, its mutually beneficial, so Apple should be putting their best effort to making the transition smooth (which I think, at least from an outsiders perspective, they are)
  - bluedino 6y ago
    Apple should care more about this - web developers are a huge part of their brand
    - pvg 6y ago
      Using Apple computers is a part of some web developers' brands. Web developers are at best a tiny niche aspect of Apple's brand.
    - messe 6y ago
      > web developers are a huge part of their brand Are they? Maybe in HN's niche community—and it is niche—but I suspect the vast majority of Apple's customers don't remotely associate web developers with the brand.
      - chipotle_coyote 6y ago
        I think it would be accurate to say web developers are a part of their market more than a part of their brand. I don't know if I'd say "huge," but I suspect a financially significant chunk of MacBook Pro sales, specifically, go to design and engineering groups in tech companies.
jamesfmilne 6y ago
It would be perfectly possible to run the VST/AudioUnit in a separate x86 process and communicate with the host using shared memory. Thankfully the endianness is the same so data structures are compatible. Doesn't Logic Pro already support this? Admittedly it does mean the plugin runs in a separate process&thread, requiring IPC to render each chunk of audio through that plugin.
- ratww 6y ago
  > Doesn't Logic Pro already support this? It didn't support it during the 32/64 bit transition, don't know about Intel to ARM. Of course even if Logic does it, there's the other DAWs.
- rock_artist 6y ago
  > Doesn't Logic Pro already support this? It does. Apple provides all AU hosts ability to run Rosetta2 AUs in native DAWs
  - marcan_42 6y ago
    That's because AUv3 is an out of process plug-in architecture, with the performance overhead that that entails. See here for why that doesn't scale to serious productions with high track count: https://ardour.org/plugins-in-process.html https://ardour.org/plugins-in-process.html
- marcan_42 6y ago
  The endianness being the same does not mean data structures are compatible. There are many, many more details about data structure layout that vary between architectures (and even compilers of the same architecture, especially once you delve outside of C). VST2 is probably doable - what I use to run Windows VST2s on Linux is something similar with an out of process wrapper - but I can see VST3 with its C++ API being a major, major pain in the ass. And even then there are downsides. Running plug-ins out of process has significant context switching overhead. It's fine for one or two or half a dozen, but compare running 50 plug-ins in process and out of process and you'll notice a massive performance difference. You can fight that with larger buffer sizes, but that adds latency.
vimy 6y ago
> 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 Is this your personal experience or are you speculating? I haven’t noticed performance drops or stability issues under Rosetta so far. A truly impressive feat of software engineering.
- dagmx 6y ago
  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, but still slower than native.
  - vimy 6y ago
    That’s what I’m saying. There is no performance drop compared to x86 macs, the M1 is _that_ fast.
    - marcan_42 6y ago
      Well yes, x86 macs in those classes were using underpowered Intel CPUs :-). That said, I've yet to see any serious benchmarks of this kind of workload. We know the M1 is fast for single threaded UI code (fast as heck atomics sure help with ObjC reference counting), but that says nothing about SIMD and floating-point heavy audio processing. Rosetta adds overhead to that, potentially a lot vs native ARM code, depending on the code. There is no way to make a blanket "the M1 is so fast it overtakes Intel even under emulation" claim. I'd personally be more concerned about stability and drop-out issues. Apple sells Rosetta as an "ahead-of-time" translator, but that is necessarily best effort (because true transpiling is not a solvable problem, e.g. self-modifying code). Thus, there is always the possibility that the JIT gets invoked in the middle of the audio processing thread, and that won't end well for real-time guarantees. There are also programs that just don't work under Rosetta properly (for unclear reasons).
EamonnMR 6y ago
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.
- deleted 6y ago
  [deleted]
- rock_artist 6y ago
  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 not always possible for real-time processing. So not all SIMD code can be compiled just by changing a flag. - machine specific code. While rare. Some companies still got such code for various reasons. And needs more complex transition. - Not all companies were able to obtain DTK. We for example, got our first M1 machine 3 weeks ago. - Backward support. While we'd like to have universal builds, musicians use their systems for years. We still support 10.7. With Big Sur Apple seems to break SHA1 signs making builds from Big Sur work reliably only on 10.11 or newer. (The first release to support SHA256 codesigns) - some companies already got Universal builds. REAPER, FabFilter and Adobe Audition are few I can remember. Keep in mind electron, docker, Homebrew and even other "devs" tools still not fully Apple Silicon ready. So indeed the above statement is unfair for a small industry (vs finance or other software markets)
  - Wowfunhappy 6y ago
    > With Big Sur Apple seems to break SHA1 signs making builds from Big Sur work reliably only on 10.11 or newer. (The first release to support SHA256 codesigns) Affinity Photo is an Arm/Intel universal binary that’s also compatible with OS X 10.9. Maybe look into what they’re doing?
    - rock_artist 6y ago
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
gumby 6y ago
> ...you have to run […] under Rosetta, with the performance drop and stability compromises that that entails. Have there been stability issues with Rosetta? I haven’t seen reports but I’m not switching right away so may not just be looking closely enough.
hammock 6y ago
So I've been out of the DAW game for a number of years now and would like to get back into it. Don't own protocols or any plugins anymore. I was about to buy the M1 Pro. Should I not do that?
namibj 6y ago
Have you looked at the continuous testing, e.g. [0] for AMD and [1] for Intel? They consistently deliver latencies below 300 us, and for the most part, even lower. Intel largely below 50 us, AMD more around 170 us. Remember, DAW deployments are not actual hard realtime. If you drop one chunk of samples every night, no one cares. [0]: https://www.osadl.org/Latency-plot-of-system-in-rack-c-slot.qa-latencyplot-rcs8.0.html?shadow=0 https://www.osadl.org/Latency-plot-of-system-in-rack-c-slot.... [1]: https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot.qa-latencyplot-r0s6.0.html?shadow=1 https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot....
erwincoumans 6y ago
I own some M1 and the arm version of Logic Pro X can load most x86 VST plugins without problems. A recompile is a bit more energy friendly but not strictly necessary.
joshlk 6y ago
Unfortunately it's unlikely Linux will ever run on the new M1 Macs: "Linus Torvalds doubts Linux will get ported to Apple M1 hardware" https://news.ycombinator.com/item?id=25238175 https://news.ycombinator.com/item?id=25238175
blymd 6y ago
Yeah, it'll be a while before VSTs get caught up. I did some testing with MainStage concerts using Apple's built-in stuff and my wife's M1 MacBook Air performed just as well if not better than my $4000 MacBook Pro. This is why I'm so excited for Apple Silicon computers for this sort of work.

kevingadd 6y ago

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?

TylerE 6y ago
It’s within one process. There are ways to bridge it but basically you have a native plugin shim that talks to a process running the target arch and essentially passes protocol messages back and forth. Was common for a while on windows when many plugins were 32bit only and wouldn’t run in a 64 bit host
ratww 6y ago
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.
- PaulDavisThe1st 6y ago
  It's a bit more than "just how DAWs are implemented today" https://ardour.org/plugins-in-process.html https://ardour.org/plugins-in-process.html
marcan_42 6y ago
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.

dingaling 6y ago

> They're going to have to wait until the synth industry gets their act together and ports to Apple Silicon though. Why is it their responsibility? Apple has literally billions in the bank, they should be running an incentive scheme if they want more native ports. This reminds me of people complaining that Docker doesn't run on Apple ARM yet. Why should it? Apple are the ones that changed the architecture.

Sholmesy 6y ago
It's naive to think that Apple needs Docker more than Docker needs Apple. If Docker didn't support Apple devices going forward, they would lose a significant amount of users. If Apple doesn't support docker going forward, they lose a tiny percentage point. That being said, its mutually beneficial, so Apple should be putting their best effort to making the transition smooth (which I think, at least from an outsiders perspective, they are)
- bluedino 6y ago
  Apple should care more about this - web developers are a huge part of their brand
  - pvg 6y ago
    Using Apple computers is a part of some web developers' brands. Web developers are at best a tiny niche aspect of Apple's brand.
  - messe 6y ago
    > web developers are a huge part of their brand Are they? Maybe in HN's niche community—and it is niche—but I suspect the vast majority of Apple's customers don't remotely associate web developers with the brand.
    - chipotle_coyote 6y ago
      I think it would be accurate to say web developers are a part of their market more than a part of their brand. I don't know if I'd say "huge," but I suspect a financially significant chunk of MacBook Pro sales, specifically, go to design and engineering groups in tech companies.

jamesfmilne 6y ago

It would be perfectly possible to run the VST/AudioUnit in a separate x86 process and communicate with the host using shared memory. Thankfully the endianness is the same so data structures are compatible. Doesn't Logic Pro already support this? Admittedly it does mean the plugin runs in a separate process&thread, requiring IPC to render each chunk of audio through that plugin.

ratww 6y ago
> Doesn't Logic Pro already support this? It didn't support it during the 32/64 bit transition, don't know about Intel to ARM. Of course even if Logic does it, there's the other DAWs.
rock_artist 6y ago
> Doesn't Logic Pro already support this? It does. Apple provides all AU hosts ability to run Rosetta2 AUs in native DAWs
- marcan_42 6y ago
  That's because AUv3 is an out of process plug-in architecture, with the performance overhead that that entails. See here for why that doesn't scale to serious productions with high track count: https://ardour.org/plugins-in-process.html https://ardour.org/plugins-in-process.html
marcan_42 6y ago
The endianness being the same does not mean data structures are compatible. There are many, many more details about data structure layout that vary between architectures (and even compilers of the same architecture, especially once you delve outside of C). VST2 is probably doable - what I use to run Windows VST2s on Linux is something similar with an out of process wrapper - but I can see VST3 with its C++ API being a major, major pain in the ass. And even then there are downsides. Running plug-ins out of process has significant context switching overhead. It's fine for one or two or half a dozen, but compare running 50 plug-ins in process and out of process and you'll notice a massive performance difference. You can fight that with larger buffer sizes, but that adds latency.

vimy 6y ago

> 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 Is this your personal experience or are you speculating? I haven’t noticed performance drops or stability issues under Rosetta so far. A truly impressive feat of software engineering.

dagmx 6y ago
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, but still slower than native.
- vimy 6y ago
  That’s what I’m saying. There is no performance drop compared to x86 macs, the M1 is _that_ fast.
  - marcan_42 6y ago
    Well yes, x86 macs in those classes were using underpowered Intel CPUs :-). That said, I've yet to see any serious benchmarks of this kind of workload. We know the M1 is fast for single threaded UI code (fast as heck atomics sure help with ObjC reference counting), but that says nothing about SIMD and floating-point heavy audio processing. Rosetta adds overhead to that, potentially a lot vs native ARM code, depending on the code. There is no way to make a blanket "the M1 is so fast it overtakes Intel even under emulation" claim. I'd personally be more concerned about stability and drop-out issues. Apple sells Rosetta as an "ahead-of-time" translator, but that is necessarily best effort (because true transpiling is not a solvable problem, e.g. self-modifying code). Thus, there is always the possibility that the JIT gets invoked in the middle of the audio processing thread, and that won't end well for real-time guarantees. There are also programs that just don't work under Rosetta properly (for unclear reasons).

EamonnMR 6y ago

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.

deleted 6y ago
[deleted]
rock_artist 6y ago
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 not always possible for real-time processing. So not all SIMD code can be compiled just by changing a flag. - machine specific code. While rare. Some companies still got such code for various reasons. And needs more complex transition. - Not all companies were able to obtain DTK. We for example, got our first M1 machine 3 weeks ago. - Backward support. While we'd like to have universal builds, musicians use their systems for years. We still support 10.7. With Big Sur Apple seems to break SHA1 signs making builds from Big Sur work reliably only on 10.11 or newer. (The first release to support SHA256 codesigns) - some companies already got Universal builds. REAPER, FabFilter and Adobe Audition are few I can remember. Keep in mind electron, docker, Homebrew and even other "devs" tools still not fully Apple Silicon ready. So indeed the above statement is unfair for a small industry (vs finance or other software markets)
- Wowfunhappy 6y ago
  > With Big Sur Apple seems to break SHA1 signs making builds from Big Sur work reliably only on 10.11 or newer. (The first release to support SHA256 codesigns) Affinity Photo is an Arm/Intel universal binary that’s also compatible with OS X 10.9. Maybe look into what they’re doing?
  - rock_artist 6y ago

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

gumby 6y ago

> ...you have to run […] under Rosetta, with the performance drop and stability compromises that that entails. Have there been stability issues with Rosetta? I haven’t seen reports but I’m not switching right away so may not just be looking closely enough.

hammock 6y ago

So I've been out of the DAW game for a number of years now and would like to get back into it. Don't own protocols or any plugins anymore. I was about to buy the M1 Pro. Should I not do that?

namibj 6y ago

Have you looked at the continuous testing, e.g. [0] for AMD and [1] for Intel? They consistently deliver latencies below 300 us, and for the most part, even lower. Intel largely below 50 us, AMD more around 170 us. Remember, DAW deployments are not actual hard realtime. If you drop one chunk of samples every night, no one cares. [0]: https://www.osadl.org/Latency-plot-of-system-in-rack-c-slot.qa-latencyplot-rcs8.0.html?shadow=0 https://www.osadl.org/Latency-plot-of-system-in-rack-c-slot.... [1]: https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot.qa-latencyplot-r0s6.0.html?shadow=1 https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot....

erwincoumans 6y ago

I own some M1 and the arm version of Logic Pro X can load most x86 VST plugins without problems. A recompile is a bit more energy friendly but not strictly necessary.

joshlk 6y ago

Unfortunately it's unlikely Linux will ever run on the new M1 Macs: "Linus Torvalds doubts Linux will get ported to Apple M1 hardware" https://news.ycombinator.com/item?id=25238175 https://news.ycombinator.com/item?id=25238175

blymd 6y ago

Yeah, it'll be a while before VSTs get caught up. I did some testing with MainStage concerts using Apple's built-in stuff and my wife's M1 MacBook Air performed just as well if not better than my $4000 MacBook Pro. This is why I'm so excited for Apple Silicon computers for this sort of work.