In theory, 64‑bit operating systems allow us to use as much RAM as our software demands. So should we all be using them?
Computer technology seems to be in continuous transition. Just when we think we've got it all sorted, something else comes along and tempts us forward into a new promised land of awe and wonder. Some new technology, such as multi‑core processing, delivers on the promises and exceeds our expectations. Some, such as Windows Vista, are more like the Emperor's new clothes. The current carrot being dangled is the 64‑bit operating system (OS). With both Apple and Microsoft offering stable and compatible 64‑bit platforms, the time has come to dig around and consider the promises. In this article we'll be looking at the advantages of the 64‑bit environment and running some tests to show what this could mean for audio production software. We'll also look at how to manage the transition, mixing 32‑bit and 64‑bit applications, and ask manufacturers about the challenges involved.
To take full advantage of a 64‑bit environment means to run 64‑bit native applications on a 64‑bit processor within a 64‑bit OS. On the hardware side, 64‑bit processors have been around for decades, but it wasn't until AMD introduced the Opteron and Athlon 64 in 2003 that they made it into the mainstream desktop. Intel followed suit a year later, and since then all desktop architecture has been more or less 64‑bit compatible.
On the OS side, Microsoft released Windows XP Professional x64 Edition in 2005 to take advantage of the 64‑bit hardware, but very few hardware drivers were available, and compatible application software was virtually non‑existent. There was no 32‑bit emulation mode, so if it wasn't a fully coded 64‑bit application, it wouldn't run. At around the same time, Apple offered command‑line access to 64‑bit processing through OS 10.4 'Tiger', but no one really noticed. The first sign of a workable 64‑bit OS came with the release of Vista in 2006, which shipped with both 32‑bit and 64‑bit versions in the retail box. It triumphed over the XP version because of its ability to run 32‑bit applications within the 64‑bit environment. Mac OS X caught up in 2007 with 10.5 'Leopard', and in 2009, OS 10.6 'Snow Leopard' introduced Apple's 64‑bit kernel as default, with all the included applications migrated to 64‑bit native. Like Vista, Windows 7 shipped last year with both 32‑bit and 64‑bit versions.
Recent sales figures (from the second quarter of 2010) indicate that about half of the Windows 7 installations in use are 64‑bit, and this is increasing all the time. Sales of 64‑bit Windows operating systems now outstrip 32‑bit ones by about four to one. The consumer has been largely oblivious to the resolution of their OS, or the revolution within: browse any of the major PC ranges, such as those of Dell or HP, and you'll find the 64‑bit version of Windows 7 installed by default. For the majority of computer users, the move to a 64‑bit environment is seamless and uninteresting. It appears that it's only in a few specialist markets that there's any debate or trouble at all — and, unfortunately, digital audio is one of them.
Any straw poll of audio software users or manufacturers reveals that the key advantage of a 64‑bit OS is the ability to access more RAM. It's difficult to come up with any other quantifiable factors. Differences such as wider address registers, faster bus architecture and function calls, and better scalability are tricky things to measure in the field of audio, but, on balance, don't seem to yield much greater polyphony, or the ability to run more instances of effects and software instruments. Adobe, who have recently released 64‑bit versions of Photoshop, Premier and After Effects with CS5, have been quoted as saying that in some circumstances, with large and complex projects, Photoshop has been seen to run 15 times faster on a 64‑bit OS, but it's all a bit vague. In an effort to mirror this sort of complexity, a test was created to measure and compare the time taken to mix down a large, high‑definition audio project packed with effects. In Cubase 64 on 64‑bit Windows it took five minutes and 24 seconds; in Cubase 32 on 64‑bit Windows it took five minutes and 39 seconds, and in Cubase 32 on 32‑bit Windows it took five minutes and 41 seconds. Not exactly demonstrating the awesome power of 64‑bit native applications, but perhaps an indication, at least, that there are some gains to be had outside of RAM access.
Where memory access is the most useful is in the area of sample playback, or rather the use of samples in complex, multi‑articulated virtual instruments. When Gigasampler demonstrated its ability to stream gigabytes of sample data off a hard drive through Windows 98, the era of hardware samplers came to an abrupt end, and the era of the software sampler had begun. When it was released in 1998, the recommended specs were only a paltry 128MB of RAM, yet it was able to pull 64 notes of polyphony from a 1GB piano instrument. Once the power of the software sampler was understood, sample sizes increased dramatically, but, probably more importantly, so did the demands of the user. When Gigastudio was discontinued in 2008, the forums were full of people trying to squeeze a few more megabytes out of their 32‑bit Windows XP boxes, with clever manipulation of the memory management, in order to load that fully articulated trumpet that they couldn't live without.
It's here that we find the biggest demand for a 64‑bit production environment: in the realm of orchestral instruments and the loading of massive sample libraries. This may also give a clue as to why many musicians who deal mainly with either electronic instruments or live recording are perhaps bemused at what all the fuss is about. The last thing someone composing in Propellerhead Reason is going to run out of is memory. Similarly, recording mixing and processing multitrack audio in Pro Tools is much heavier on the CPU than it is ever going to be on memory. Both Propellerhead and Digidesign have been running successful production environments on the 32‑bit platform for many years, and being proprietary systems, they are not subject to some of the excesses of the third‑party VST plug‑in manufacturers. However, as the 64‑bit advantages become more apparent, users will be pushing for greater compatibility, and our 32‑bit friends need to be careful that they don't get left behind.
In order to get some broad brush‑stroke comparisons between environments, we're using Spectrasonics' Trilian Total Bass Module, which has a bunch of huge acoustic and electric basses that eat memory for breakfast. You can run dozens of synthesized and real bass instruments in Trilian without ever hitting the memory ceiling, but if you abuse it in the right way, it does a superb job of showing the limitations of the 32‑bit OS and the possibilities of the 64‑bit OS. Trilian comes in both 32‑bit and 64‑bit flavours. The test machine is a Core i5 750 with 8GB DDR3 RAM, dual booting in Windows 7 Professional 32‑bit and 64‑bit. Test hosts are Cubase and Sonar, both of which have 32‑bit and 64‑bit versions, and Ableton Live, which is 32‑bit only.
Trilian has a couple of huge acoustic upright basses, over 2GB in size, each with a couple of different articulations that load different sample sets. These are loaded into the first four of the eight available slots. They load partly into RAM and partly onto disk ready for streaming, and so usually take up about 1GB of actual memory. The other four are electric basses, each over 1GB in size, loading about 600‑700MB into RAM.
On 32‑bit Windows, an application is allowed a maximum of 2GB regardless of how much RAM is physically installed. A 32‑bit OS can only ever address a maximum of 4GB per process. Cubase, Sonar and Live were all able to load up a single full‑range upright bass instrument. Loading a second would get stuck at about 1.5GB, and a message would pop up saying that we were trying to load an instrument that exceeded what was available to it. The first instrument could still be played, but that was as far as it got.
With Windows XP, there was a much talked about '3GB Switch', which could be enabled by a simple edit in the 'boot.ini' file. This forced Windows into allocating 3GB of memory to an application, allowing the loading of a few more instruments. Sometimes this would interfere with how Windows was arranging resources for hardware, and clashes could occur with video and DSP cards, but when it worked, it was a great way to boost system performance. With Windows Vista, the boot.ini file vanished and this loophole was moved somewhere less accessible, while in Windows 7, the 'bcdedit' command can be used to turn on the 3GB switch by entering the following phrase into a Command window that's been run as Administrator: bcdedit.exe /set IncreaseUserVa 3072. Upon reboot, a whole other 2.3GB bass could be loaded, and this time it stalled on the third when it reached 2.7GB in total. Not a bad tip.
As a 64‑bit OS can access more than 4GB of RAM, it makes no sense for Windows to artificially limit the amount of RAM an application can use. This means, in theory, that a 32‑bit application running on a 64‑bit OS should be able to access a full 4GB of RAM (assuming that further RAM is available for the system to run). This certainly seems to be the case. Cubase, Sonar and Live could all load four instruments, totalling around 3.7GB. On loading instrument number five, they all crashed out with the dreaded Microsoft C++ RunTime Error. So some caution is required, as is frequent saving, but the test shows that even running a 32‑bit application in an emulated mode on a 64‑bit OS gives much better performance than running it on a 32‑bit OS.
As expected, we finally get to break the 4GB barrier on a fully 64‑bit system. We loaded up a full Trilian with eight instruments — nearly 7GB of samples loaded into RAM — and each played perfectly. Things started to get dicey on loading a second instance of Trilian, with playback beginning to crackle as the total physical RAM limit was being approached. It should be noted that when polyphony was raised and more notes were played the CPU would jump with the intensity of having to deal with so much data. This suggests that the CPU is still likely to be a factor when it comes to performance and sample playback.
A major factor preventing people from moving to a 64‑bit OS is that there's much confusion over what will and will not work in the 64‑bit environment. In particular, even if your chosen host is available in a 64‑bit version, many plug‑ins are not. Vista, Windows 7 and Snow Leopard all allow for 32‑bit code to be run on their 64‑bit versions, albeit with a small overhead, so in principle this shouldn't be a barrier to moving to a 64‑bit OS. However, running 32‑bit plug‑ins within a 64‑bit host or alongside 64‑bit plug‑ins is a slightly different matter, requiring a clever bit of bridging software.
The 64‑bit versions of both Cubase and Sonar come with their own 'bit bridge' technology. It's not flawless but it goes a long way towards providing compatibility while we wait for the software companies to pull their fingers out and come up with proper 64‑bit versions. Waves and Universal Audio are two of the 32‑bit culprits that set forums alight with troubled tales of bit‑bridging woes. With version 5.1 of Cubase, many UAD users had trouble getting stable performance from Steinberg's VST Bridge. With version 5.5, this is much improved, while for many others the solution lay with a third‑party bit‑bridge called jBridge, created by João Fernandes. João's motivation was that he wanted to continue using 32‑bit plug‑ins, both free and commercial, that would probably never make it to a 64‑bit version. In the writing and updating of jBridge he's had to overcome some enormous problems relating to compatibility and odd issues such as how the host displays the graphical user interface. Hardware‑based plug‑ins were particularly difficult, which may give a clue as to why neither Universal Audio, SSL, TC Electronic or Digidesign have come up with full 64‑bit versions as yet (although, at the time of writing, all except the SSL Duende will now install and run on a 64‑bit OS).
So, for the next stage in our testing we ditched the 64‑bit version of Trilian and loaded up the 32‑bit version in 64‑bit Sonar and Cubase. Sonar's BitBridge and Cubase's VSTBridge load up as their own process alongside the host. VSTBridge managed a disappointing single instrument of about 1GB loaded. When Trilian was set to unlimited memory, loading a second instrument would cause a runtime error and crash. In Sonar, the BitBridge happily managed four instruments, using 3.5GB RAM, and got stuck on the fifth. Swapping VSTBridge for jBridge in Cubase left it able to match Sonar's performance in loading up four instruments. It's almost as if VSTBridge is artificially restricted to the 2GB of a 32‑bit OS.
It's a little‑known and rarely understood fact that jBridge also works backwards. Not only can it bridge 32‑bit plug‑ins into a 64‑bit host, but it can bridge 64‑bit plug‑ins into a 32‑bit host. It may not be immediately clear what this means but, for instance, Ableton Live, a 32‑bit application on our 64‑bit OS, could use jBridge to run the 64‑bit version of Trilian. In our tests here, it matched the performance of 64‑bit Cubase and Sonar by loading all eight instruments. But taking it further, this presents an alternative to trying to bridge all those Waves and UAD plug‑ins into a 64‑bit host so you can use the odd 64‑bit instrument: instead, you could use the 32‑bit plug‑ins natively in a 32‑bit host, and bridge the odd 64‑bit instrument instead.
It's hard work having to maintain compatibility using bridging software. A lot of the criticism Steinberg and Cakewalk receive about bit‑bridging is down to the plug‑ins themselves rather than the bridging technology. It would be far better for all the hosts and plug‑ins to make the jump to 64‑bit native so that the user gets a more compatible and stable recording environment, without all this mucking about with bridges. It could also be said that the ease of 32‑bit emulation in the 64‑bit OS and the cleverness of the bit‑bridging has allowed companies without 64‑bit versions to drag their feet. On the other hand, we are talking about complex applications, built by relatively small companies, for whom the change to 64‑bit is a huge undertaking — particularly where, as in the case of software such as Live or Reason, there are very few advantages to the majority of their users. In programming terms, it's not simply a matter of recompiling using a 64‑bit compiler; it's more akin to a complete rewrite. For instance, Propellerhead use an API called the Carbon Human Interface Toolbox to create the windows, buttons and menus in Reason, but it's not available on the 64‑bit Mac OS X, so translating that user interface over to a 64‑bit OS is no small undertaking. Then there's a lot of other third‑party functionality that forms part of the software and would also need rewriting. In some respects, we're at a remarkable place of conflict, where we have the current 32‑bit environment clashing with the incoming 64‑bit future, but amongst the chaos and confusion, everything actually works — almost.
There's no doubt that we are heading into a 64‑bit future. The hardware is already compatible, there are very few problems outside the creative industries, and the forthcoming Windows 8 is rumoured to be 64‑bit only, although undoubtedly with full 32‑bit emulation. Some developers, such as Spectrasonics, welcome the move, as it enables products like Trilian to really shine and demonstrate why more RAM is good. Neither Ableton or Propellerhead would be drawn into suggesting any kind of schedule for a 64‑bit version of Live, Reason or Rewire, but it's certainly something on their radar (João Fernandes of jBridge fame suggested he might give Rewire a look). Avid recently released version 8.04 of Pro Tools, which brings official support for the Windows 7 64‑bit platform, making it the last of the major music applications to make the jump to the 64‑bit environment (though the application itself is still 32‑bit).
To push us to a fully 64‑bit native environment would probably take a killer 64‑bit only plug‑in that no one can live without. In the meantime, whether your host is 32‑ or 64‑bit, access to at least 4GB of RAM, the bit bridging of plug‑ins in one direction or another, the ever-increasing realism of sample libraries and the potential for performance gains are all advantages worth having. .
Music production software 64‑bit compatible? 64‑bit native?
Ableton Live 8.1 Yes No
Apple Logic Yes Yes
Avid Pro Tools 8.04 Yes No
Cakewalk Sonar 8.5 Yes Yes
Cockos Reaper 3 Yes Yes
Image Line FL Studio Yes No
Magix Samplitude Yes No
Presonus Studio One Yes Yes
Propellerhead Reason 5 Yes No
Propellerhead Record 1.5 Yes No
SSL Soundscape 6 Yes No
Steinberg Cubase 5 Yes Yes
Steinberg Nuendo 5 Yes Yes
A selection of plug‑ins 64‑bit compatible? 64‑bit native?
Antares Auto‑Tune Yes No
Arturia V Collection Yes No
Celemony Melodyne Yes No
EastWest Composers Collection Yes Yes
Fxpansion BFD2 Yes No
IK Multimedia Total Bundle Yes No
Native Instruments Komplete 7 Yes Yes
Spectrasonics Product Line Yes Yes
SSL Duende No No
TC Electronic Powercore Yes No
Toontrack EZDrummer Yes Yes
Universal Audio UAD Yes No
VSL Vienna range Yes Yes
Waves range Yes No
It's important not to confuse 64‑bit processing, applications or operating systems with bit depth in an audio context:
In version 1.2 of their STEAM playback engine, Spectrasonics introduced a new memory addressing option on the Mac version called the Sample File Server. This enables Spectrasonics' Omnisphere and Trilian to access memory outside of the host application, so when running in a 32‑bit application, they are unrestrained by the 32‑bit memory restrictions.