Hacker News Reader

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

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

I guess they're building on Catalina as we expect to do so until Apple or us/some other devs would find a way to use prdocutsign/codesign with backward compatibility on Big Sur

I'm not saying I expect it to be done now, I'm saying I expect a good subset of audio companies to still be dragging their feet a year from now, judging by history. Yours may not be one of those :-)

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.

Bravo, love Ardour.

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)

1. Also 10.9 needs SHA1.

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.

Check out sse2neon as a way to substitute your x86 SIMD instrinsics for ARM neon. Perf was good enough to ship in one of the past projects I worked with.

Thanks! Interesting. I'll look it up. What I know one of our devs didn't find equivalent to is ippsPowx_32fc_A11

You can produce two signed binaries, one for <10.11 that is signed with a SHA-1 and one for newer systems that is signed with SHA-256. Your update framework would have to know which one to pull, but that seems surmountable.

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

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.

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

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

These kinds of questions are why the post you're replying to asked if it was personal experience or speculation.

You responded with some technically-detailed speculation, which, fair enough. I guess we'll have to wait and see.

See https://lemire.me/blog/2020/12/13/arm-macbook-vs-intel-macbo... for SIMD performance. M1 is fairly competitive even under Rosetta. Also, if your audio code is self-modifying, I really have no idea what you could possibly be doing.

Self-modifying code is just one example. The point is there is no way to positively identify all basic block entry points on x86 (especially due to its variable-length instructions). That means that there is always the possibility that the AoT didn't catch everything, and then your plug-in takes a novel uncached codepath at some point, the JIT fires, and you get a real-time constraint violation and a drop out.

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

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

Insert "not sure if trolling" GIF here, but you get that what the OP is saying is that when M1 Macs run x86 code in emulation they're often running it as fast as comparable x86 processors run it natively, right?

Right, but if the conversation is about how this is going to change Broadway or anything, running just as fast means nothing changes (the case if you have to emulate)

The conversation started by the linked article is clearly suggesting it can change Broadway when software is recompiled to run natively with Apple Silicon, though, and this is a perfectly reasonable take. An M1-based Mac mini that's actually less expensive than the Intel one it directly replaced can be a lot faster.

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.

20 hours of battery life...and no fan noise.

To clarify, when I say native, I mean both arm and x86.

Switching to x86 emulation for compatibility, will be a performance hit against running native ARM

M1 emulating x86_64 is typically faster than any Intel Mac below a Mac Pro, so in the context of a Mac Mini it’s a safe bet on emulation from a performance standpoint.

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.

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

> Doesn't Logic Pro already support this?

It does. Apple provides all AU hosts ability to run Rosetta2 AUs in native DAWs

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

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.

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

[1]: https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot....

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.

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

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

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

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.

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?

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.

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

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

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)

Apple should care more about this - web developers are a huge part of their brand

Using Apple computers is a part of some web developers' brands. Web developers are at best a tiny niche aspect of Apple's brand.

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

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.

You don’t need docker to develop web apps.

There might not be an absolute need but the advantages of Docker are enough that, when removed, the pain is real.

... And yet Apple refused flash support on iOS. It didn't hurt Apple, and only strengthened web development by forcing new solutions to appear. Flash, once a big chunk of the web, is now a little more than a footnote.

Apple killed flash. If they will be able to kill x86 remains to be seen. I don't think web users won out because flash is dead though. Web games never recovered. Video making switched from animation to people filming themselves talking to the camera. What will we loose with x86, I wonder?

> Video making switched from animation to people

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'

> Apple killed flash.

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.

Security was indeed an issue, but I feel flash’s performance reputation was largely undeserved. Yes, it was cpu-hungry, too intense to run on the mobile hardware of the day, but that’s because it did things html5 couldn’t. You could do smooth animations and complex games in flash easily that were hard to impossible to do with regular web tech (pre-webgl). When flash died, web animation and web gaming mostly died along with it. Some of that is the engine itself, and some is the flash authoring tools, which don’t have an open web equivalent. Maybe that sort of power never belonged in a browser, but I still feel like we lost something that didn’t fully get replaced.

I still largely blame Adobe here -- they were the ones who should have been responsible for fixing Flash's performance. The complaints about it being a CPU hog weren't limited to mobile; even in the early 2000s, Mac users, at least, generally hated being forced to deal with Flash-based UIs. Adobe never seemed real concerned with optimization, I suspect precisely because of the advantages you listed, e.g., things that were hard-to-impossible to do without Flash.

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.

They where poor stewards of the platform, to be sure. The security situation was very bad, and they did little to discourage people from using Flash for all of the wrong reasons. But you could just as easily turn around and blame Apple for the depressing state of mobile gaming.

Flash has an HTML5 equivalent. Alongside the Animate rebrand (years ago) they released HTML5 tooling that lets you export animations for the web.

> Video making switched from animation to people filming themselves talking to the camera.

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 was completely built around Flash

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.

> Apple should care more about this - web developers are a huge part of their 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.

I dream that at some point, everyone will get their heads out of their asses and abandon this abusive relationship.

The abusive relationship trickles down no matter which platform you choice. Even on Linux you don’t have full control of all the driver binaries, control of the silicon of everything running on your rig. Even if you were to go RISC V chances are you are going to have to rely on some binary blob for things like your WiFi card.

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.

Agreed. We should all standardize on the most open systems that permit the most users to use the machines as we see fit. For example, on an open system, you can make special systems for Mac users. Or for Windows users. Or LSARS users.

That way we don't duplicate effort for an ever closing dictated by one greedy body.

How about the malware aspect? The most open system could be the most vulnerable as well.

It's a tool not a religion.

One is a toy, the other is a tool.

Docker does run on Apple silicon already by the way :)

This whole line of argument is just weird.

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