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)
Affinity Photo is an Arm/Intel universal binary that’s also compatible with OS X 10.9. Maybe look into what they’re doing?
2. We've been able to input down to 10.7 and didn't see any issues. The issue is productsign/codesign linking Security.framework which I assume changed.
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.
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.
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).
Also, audio companies sometimes like to use "fun" DRM/copy protection systems.
Besides, audio apps themselves doing JIT would not be unheard of. For example, that'd be a very efficient way of implementing a modular synth. Those apps could JIT in a realtime-safe way; Rosetta can't (it doesn't have enough info).
You responded with some technically-detailed speculation, which, fair enough. I guess we'll have to wait and see.
Switching to x86 emulation for compatibility, will be a performance hit against running native ARM
The arguments in the thread about "but a lot of software right now runs in emulation" and "who knows when the software companies will get around to transitioning" aren't wrong, per se, but they're also arguments that long-time Apple users have heard variants of in the PowerPC to x86 transition. And in the (original) Mac OS to OS X transition. And in the 68K to PowerPC transition. It turns out that when transitioning your software to the new platform doubles your performance and/or is necessary to keep selling your product, you have a fairly strong motivation to do the work.
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.
It does. Apple provides all AU hosts ability to run Rosetta2 AUs in native DAWs
See here for why that doesn't scale to serious productions with high track count:
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.
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.
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....
[1]: https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot....
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.
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
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.
There are alternatives, like the bridges mentioned by the sibling post, but it's clunky and manual to setup and slows down your workflow.
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.
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)
Apple didn’t kill Flash. Adobe did.
By failing to deliver a performant and secure version of Flash (under any architecture, but especially mobile), Adobe ensured Flash would be not be viable for the web as it evolved.
At this point, at least, I'm pretty sure WebGL can do most or all of what you could do in Flash. It's possible that the tools have never caught up, but it also seems possible to me that the space that used to be occupied by Flash games has largely been filled, ironically, by mobile gaming.
Youtube was completely built around Flash, the FLV format hit a sweet spot between "not looking like trash" and "not needing more bandwidth than the average user had" that else had before. I'm pretty sure we would be seeing a shit-ton of people filming themselves talking to the camera even if Flash was still a going concern - animation is a ton of work.
Youtube exists because of Flash. They were are the right time and place to have a flash object sitting on a webpage that could play video in a reasonably cross platform way.
Not sure this is entirely due to the flash web player being phased out. Kids just watched their friends play from the couch, or watched more generic broadcast television. Now they still watch and play together but remotely.
Edit: 'due' not 'sure', 'play' not 'pay'
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.
They demoed Docker on stage at WWDC. They've donated equipment to Docker. Apple built a significantly better virtualization framework for Big Sur/ Apple Silicon.
What makes you think they don't care about it?
This transition is in baby steps right now. It takes time to migrate software.
And even if we over come all those hurdles we still have to convince the avg joe to adopt them too otherwise it will just live in a small costly niche that the wider community just don’t bother supporting.
All we can do is try and pick the least abusive relationship we can afford and is practical to run.
My point is, I don’t it against people for using platforms others may find abusive. Sure us on HN are more likely to be in the position where we can switch platforms for fun just to see how they work out. But for most they simply don’t have the time or patience to swap and learn a new platform (let alone the cash).
Maybe this is a bad example because of what exactly happened with one manufacturer, but it’s why airlines like plane manufacturers to not go too far with design changes because it requires them to retrain their polits on the new aircraft.
If every time you purchased a new car you had to take into consideration that the control system was different between each manufacturer which may even require you to retrain in order to drive it you may very well consider with sticking with what you already know.
So I don’t hold it against anyone who simply wants to keep with what they know. They just want to fire up the platform at get to using it.
Anyways sorry for the rant, just my thoughts on the matter.
That way we don't duplicate effort for an ever closing dictated by one greedy body.
> 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.
Because they want to sell software and/ or hardware.
> 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.
Docker is getting migrated for the same reason it was originally ported to MacOS. Because the developers either run Macs or work for companies that support people who run Macs. It's the same reason any software is getting ported.
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.