In this article Mark Wherry asks whether the migration of Apple computers onto Apple Silicon will bring pro users back to the Mac and whether this move will the destroy cross-platform parity we’ve enjoyed for so long in the process?

When Apple transitioned the company’s Mac computers from using PowerPC processors to those manufactured by Intel back in 2006, it began a period—perhaps unintentionally—where the hardware architectures used by personal computers were largely the same, regardless of the operating system software that greeted the user. For Intel, this established the company’s processor offerings as the de facto centre of the computer universe; everything from the now-not-so-humble PC to the servers found in datacentres now had Intel inside.

One key advantage of this uniformity was that it meant the x86 instruction set used by Intel’s processors (and similar, compatible offerings from companies like AMD) became the lingua franca upon which all software was executed. Simply put, you can think of an instruction set as the ingredients that make it possible to execute a recipe in a given kitchen. So, while Aimee Mann likely didn’t have cross-platform compatibility in mind regarding the music production software in use when she sang that “one is the loneliest number”, it turns out that one is also the most apropos number when it comes to the number of hardware architectures a developer must support.

Such parity has been beneficial for companies like Steinberg, Ableton, and, to a lesser extent, Avid, to mention but a few well-known names, since it meant their respective cross-platform offerings such as Cubase, Live, and native versions of Pro Tools now had to consider just one hardware architecture. This hasn’t saved developers from having to juggle the intricacies of different operating systems—macOS, Windows, and occasionally Linux—of course; but, at the very least it meant the lower-level code for audio processing could be designed with the assumption it would be running on an Intel processor, with I/O handled by the not-so-dissimilar ASIO or Core Audio plumbing.

Now that we’ve become accustomed to this balance in the force, Apple has shaken things up again – but this time in the opposite direction. By transitioning to what the company refers to as Apple Silicon, custom chips like the M1 will propel the Macintosh into a more powerful future whilst simultaneously requiring less power! And from the perspective of the musician and audio engineer, what’s not to like? Music and audio software tends to devour any available amount of computation; and, having quieter systems due to better efficiency is similarly welcome for work in noise-sensitive recording environments.

However, Apple Silicon is not necessarily a free lunch and there are implications for users of both MacOS and Windows. To begin with, the first offspring of this effort to be used in a Mac—the surprisingly performant and harpocratic (i.e. fast and quiet - Ed) M1—is quite unlike any desktop processor before it and, as such, is largely unconcerned of being obviously compatibility with other desktop systems. That’s great for Apple, who, as the company likes to remind us, is only concerned with making the best Macs for their users. It’s probably also great for those whose studio ecosystems are mostly Apple-exclusive, such as Logic Pro acolytes. But—and this is a big but—if your software studio relies on cross-platform offerings, no matter whether you’re a macOS or Windows user or both, you might find yourself more affected by cross-platform compromises going forward rather than the cross-platform conveniences you might have enjoyed.

For example, as a cross-platform developer, do you optimise your application to be dazzling on a macOS-based system powered by Apple Silicon, or a Windows computer based on Intel’s platform or another architecture? It’s hard to do both, and one will always be “better”. And with chips like Apple’s M1 being an entire system-on-a-chip (SoC) featuring dedicated accelerators in hardware for machine learning, decoding, and fast memory access, this represents a necessarily different solution for the future of computing that Intel is now moving towards. But that’s the advantage Apple has always had by being a vertical system provider, rather than needing to be all things to all users, from the laptop to the datacentre. However, this wasn’t always the case.

Extended Instructions

Having just one hardware architecture meant that there was only one way in which to optimise an application to really sing on a given processor – it’s the economy of resources, stupid, to paraphrase James Carville. And while many other factors and technologies have arisen since 2006, figuring out how to fully harness the power of Intel’s processors has been de rigueur for a long time.

One simple example where one can get the most out of a processor concerns optimisation, where programmers utilise under-the-bonnet techniques to squeeze the best theoretical performance from a system. For audio and music software, this means being able to play back the largest number of tracks and channels, whilst deploying the maximum amount of filtering and other signal processing techniques for plug-ins.

To facilitate this performance, in addition to the basic set, processors usually feature extended instruction sets to speed up tasks such as vector and matrix maths operations. If you were a long-time Mac user, you might remember a technology Apple dubbed the “Velocity Engine” in its PowerPC G4 and G5 chips, which executed instructions from the so-called AltiVec set. In the Intel world, you’ll know these types of extensions by names like SSE or AVX, with AVX-512 being Intel’s latest and tendentiously greatest.

There are two key reasons why these sets of instructions are useful to music and audio programming, beginning with the fact they can perform multiple instructions on a multiple data items simultaneously. This type of operation is known as Single Instruction Multiple Data (or SIMD), so if you wanted to reduce the gain by 6dB in an audio stream of 32-bit floating point samples, for example, you could process this steam 16 samples at a time by using an AVX-512 instruction.

While similar, with each processor having its own extended instruction sets to facilitate optimisations in music and audio applications, this would inevitably add some extra work for developers to ensure each platform delivered the best performance for its users. While there are naturally similarities between the matrix math instructions available in different processors—they are, after all, designed to achieve similar end results—there are also differences in the implementations that could lead to performance issues if not correctly observed.

Apple have traditionally simplified such optimisations for macOS developers by providing a handy framework called, appropriately enough, Accelerate. This abstracts the intricate knowledge required for implementing different flavours of vector and matrix maths operations, which is helpful if you’re only programming for macOS and obviously less so for developers of cross-platform offerings. Although, in the blissful world of only having to worry about one architecture, Intel itself offered a cross-platform framework for macOS, Windows, and even Linux development, known as the Integrated Performance Primitives (IPP).

Because of its heritage, the M1 has two completely different extended instruction sets. The first, Neon, has been part of ARM—the CPU core featured in the M1—since the ’90s. The second such extended instruction set is perhaps more interested as it’s cloaked in Apple’s veil of secrecy and is both unnamed and undocumented for users and developers alike. Its existence is known thanks to mentions in Apple’s marketing, as either AMX Blocks, accelerated matrix multiplication, or machine learning accelerators, and these instructions are largely designed for those purposes, although, as mentioned, these types of instructions can be highly useful when it comes to signal processing for audio – or even in powering a true AI composer.

Given the inscrutability of Apple’s own extensions, the only way for develops to make use of them is indirectly via the aforementioned Accelerate framework. In doing so, developers don’t need to worry about which instructions are being used, be they ARM, AMX, Neon, others that may be added later and unleashed with a simple recompile. And the Accelerate framework also works as is when developing now-“legacy” macOS x86 applications, which gives coders a good reason to focus on the Mac for some tasks and general performance as users of existing Macs are brought along for the ride.

If you’re a cross-platform developer, you’ll once again have the choice of whether or not to optimise for other platforms in this manner. This could mean abstracting the Accelerate the framework to balance the best of both worlds, or writing specific parts using dedicated libraries or your own code where necessary, for example. And while this might all seem rather complicated, handling different types of extended instruction sets is perhaps the smallest difficulty for developers in returning to a world where there’s more than one hardware architecture to support. 

Software Or Hardware?

Since the Mac and Windows worlds unified around Intel’s processors in 2006, there have been many interesting trends taking off in the opposite directions. For example, the success of personal computers with “Intel Inside” was predicated around the ability of PC processors to handle tasks that previously required additional, dedicated processing hardware for tasks such as handling video and audio. From trivial tasks such as DVD playback that originally required an MPEG-2 decoder card, to more complex applications for non-linear video editing, or even audio production.

However, just like the rise of larger, faster, monolithic, and general-purpose CPUs, its crescent seems to be waning. Where systems would become more powerful by such a chip gradually subsuming components previously requiring domain-specific hardware accelerators, we now seem to be heading back towards a greater diversity.

The first, tiniest, inkling of such a shift was arguably the rise of GPUs (for processing graphics) and a move towards GPU architectures for general purpose computing (using graphics processors for more than just graphics), particularly in deep learning and other AI-related tasks. However, thus far GPGPU hasn’t proved the DSP replacement predicted by many audio industry soothsayers, and I’ll save this subject for another article. So, besides providing smoother graphics that can offload the drawing and animation of both 2D and 3D user interfaces, audio applications have seen little benefit.

Similarly, with video, even though Apple’s own ProRes codec was specifically designed with high-performance editing with Final Cut Pro X in mind, presumably for native systems, the company launched the so-called Afterburner card alongside the most recent Mac Pro. This card can handle a maximum of six streams of 8K ProRes RAW or 23 streams of 4K Pro Res RAW simultaneously, with each stream running at up to 30 frames per second – all whilst barely scratching the system’s CPU resources.

What about audio, then? In many ways it’s been hard to substantially improve on CPUs and their extended instruction sets to provide significant leaps in performance in the past few years. Even dedicated DSP chips offer little in the way of actual performance, and these chips—once the lifeblood of a digital audio workstation—are more usefully put to work in devices to reduce the amount of latency where processing is required on physical audio inputs and outputs. In fact, even dedicated DSP chips are seldom used, with developers preferring to implement their own capabilities on FPGAs (Field Programmable Gate Arrays). An FPGA is essential a block of programmable logic, which can be updated “in the field” (hence the name) enabling new hardware features to be added after a piece of equipment has shipped.

That’s not to say the M1 doesn’t have a few hardware tricks up its silicon sleeve to speed-up general application performance, though, particularly when it comes to what Apple term as Unified Memory. This is essentially a way of providing memory access to different parts of the processor and offers two main advantages: speed and efficiency. Unified Memory is so performant, you can basically think of it as a level-4 cache, and it’s efficient in terms of not duplicating data required by different processing areas of the chip. And while this currently limits the maximum amount of memory available in an Apple Silicon-based system to 16GB, the company will surely find bigger sleeves with more memory and cleverer implementations going forward.

Conclusion

In the good old days of computing architectures—well, let’s say the ’80s for the sake of this point—there was a category of computers in between desktops (PCs) and servers known as workstations. While that designation is still employed today, it’s now more of a marketing term than technical nomenclature since all three classes of system generally use the same technology.

In the past, though, a PC would have conjured up images of IBM-compatible boxes or Macs (home computers from the likes of Atari and Amiga would be seen beneath these by most!), whereas the more expensive and alluring workstations came from companies like Silicon Graphics (SGI), Sun, and DEC. All of these computers had technically interesting, RISC-inspired custom CPUs—MIPS, SPARC, and eventually Alpha, respectively—and, in the case of SGI, arguably the world’s first GPUs famously used to create the dinosaurs in Jurassic Park.

However, as brilliant and interesting as these workstations were, their markets arguably weren’t big enough to save them from being flattened by the seemingly unstoppable x86 steamroller. Even as companies tried to replace their custom products with compatible offerings, they simply couldn’t compete against the margins of companies like Dell – even IBM got out of the computer market! Nevertheless, in this brave new world of a return to decentralised, domain-specific processing, a chip like the M1 seems to harken back to these halcyon days.

The big question will be whether cross-platform music and audio applications will continue to make sense for companies and users alike? Such an application will almost inevitably run better on one platform versus another, which arguably became the case in the latter days of Mac OS X and PowerPC-based systems. At the time, using cross-platform software like Cubase was like eating a good steak with a butter knife on Mac OS X and PowerPC when compared to running on Windows and Intel. So, it’s not inconceivable to imagine one platform again becoming the black sheep again for different reasons. Could it be that the combination of macOS and Apple Silicon will effectively eliminate the need for cross-platform compatibility altogether? Or at least make it economically questionable for developers.

It’s obviously too geminal to answer this question unequivocally, of course, although I don’t think it’s completely unforeseeable either. Because, if all you want to do is use a computer for music and audio engineering, just buy a new Apple Silicon-based Mac and you’ll be set. The only meaningful comparison you’ll be able to make when evaluating the two platforms is price, since other specifications like processor, clock speed, and possibly even memory will be largely irrelevant. It’s the ’80s all over again!