MAINMUSICCREDITSPHOTOSCONTACT

64-bit DAWs and Samplers

Updated: February 18 2008 Keywords: 64-bit DAW, sampler, 64-bit, 64bit


This article documents my personal experience and research while working with using 64-bit Operating Systems (in this case, Windows XP x64) in digital audio workstations.

Feedback is greatly appreciated – let me know your experiences too!

People have approached the relatively new and experimental frontier of 64-bit in two general categories:

  • Using a 64-bit OS for their main sequencing/editing workstation
  • Using a 64-bit OS for outboard sampling


Windows XP x64 versus Windows Vista 64

Results may be different on XP x64 versus Vista 64. This article reflects experiences with XP x64.

Many manufacturers are not “supporting” XP x64, and are developing their 64-bit support in favor of Vista 64-bit. In the long run, this may be good, but currently many people who are turning to 64-bit for audio purposes highly favor XP x64 because of its simplicity and stability. Vista has much more overhead in the operating system which ultimately uses more memory, CPU cycles, and disk access time. It is also more difficult to tweak Vista for audio.


Current Pros and Cons of Windows XP x64 for Audio

Pros

  • Break the 32-bit memory barrier.
    64-bit memory addressing can utilize upwards of 128GB of RAM and beyond. With the falling price of RAM, it is becoming very cost-effective to install 4 or 8GB of RAM into a system.
  • Native 64-bit processing
    64-bit audio can be processed as efficiently as 32-bit audio.
  • Supports 64-bit plugins
    If your sequencer is 64-bit native, you can load 64-bit VSTi plugins.

Cons

  • Driver Support
    It may be difficult to find working drivers, or any drivers at all for audio interfaces or other crucial hardware.


Driver Support

It can be tough to find working drivers. I say this because some manufacturers claim to have drivers or beta drivers, but they don’t function properly. From personal experience, 64-bit drivers for audio interfaces will either work, or won’t work at all.

For example, M-Audio has beta drivers for some of their hardware. The drivers would install and run without errors, but sequencers such as Sonar simply don’t see a hardware device at all, and you can’t get any audio from the device.

Digidesign does not officially support 64-bit yet.

Tascam, in my limited experience, claims to have proper 64-bit drivers but I have had trouble with them. The FW-1804 has a 64-bit driver and you can get audio out of it, except it has a strange issue with wordclock where it causes clock-error like audio artifacts over digital and analog outputs. I was never able to resolve this issue.

Frontier Design Group seems to have rock solid support. This is ironic, considering the Tascam FW-1804 that I mentioned above (which has malfunctioning drivers despite being “official” 64-bit drivers) is designed by Frontier. The Frontier Dakota PCI card has official 64-bit drivers and performs impeccably well.

Echo has good support as well, I've used the Gina 24/96 with success.

If you’re considering getting into 64-bit, it’s a good idea to search Google and find out across review sites and forums what people’s experiences are with your particular audio hardware. As I mentioned above, a manufacturer may claim to have 64-bit drivers but the cold reality is that they may not be working properly yet.


Software Support

There is limited availability of software that has been coded to take advantage of what a 64-bit environment has to offer.

Cakewalk Sonar has had native 64-bit support for some time now, which will let users see a remarkable increase in the number of plugins they can load. The honeymoon stops a little short at this point, however, because third party plug-ins and virtual instruments are mostly 32-bit currently. Sonar will allow 32-bit plugins to be used transparently as you would normally load them, but with some drawbacks. Their BitBridge technology loads all 32-bit components into a single process, which still retains the 32-bit memory limitation. In addition, this feature adds one additional buffer of latency which can be rather significant for those wanting to employ Sonar for real-time sampling purposes.

More developers are jumping onto the 64-bit bandwagon because they are realizing there is a market for it, and that there are very significant advantages to the end-user to enable


64-bit Systems as Networked Samplers

There are a number of options for using 64-bit machines as dedicated samplers (aka, “Giga” boxes)

Gigastudio 4 (Expected Q2 of 2008) may simplify the concept of 64-bit sampling, and not only for GIGA sample users. It’s allure is that it will be able to access all of your system RAM, as well as load VSTi instruments, making it an all-in-one solution. It is yet unclear whether Gigastudio 4 on 64-bit will have the same architecture as Sonar in regards to how it deals with 32-bit VSTi components. If 32-bit instruments are loaded all into a single process, you will still be stuck with the 2GB memory limitation for all the 32-bit instruments combined. (See below on enabling 4GB addressing for 32-bit apps) If each instrument is orphaned to its own process, then each would be capped at 2GB and thus offer far more freedom memory-wise.

Sonar 7 may be an expensive route for the task, but many people are using it as a VST host on outboard sampler PCs. Cakewalk ships 32-bit and 64-bit versions of Sonar on the same DVD, and you are free to use either version, with subtle differences:

  • Whether you use Sonar 64-bit or 32-bit, you will still be limited to the 32-bit memory cap for 32-bit VSTi’s you load.
  • Sonar 64 uses BitBridge to accommodate 32-bit VSTi’s which introduces additional latency. Sonar 32 can load 32-bit VSTi’s natively, which means it does not use BitBridge and will not incur the additional latency.
  • Sonar 64 will not load 32-bit DXi’s at all, only 32-bit VSTi’s. This shouldn’t be a problem as most instruments have a VSTi version. Sonar 32 will still load both 32-bit VSTi’s and DXi’s.

In an ironic twist, most people on 64-bit hardware are using the 32-bit version of Sonar because a lot of instruments are still 32-bit, and because Sonar 64 increases the latency. As more VSTi’s become 64-bit, then it would be more advantageous to use Sonar 64 to take advantage of more RAM. Sonar 32 will not load 64-bit VSTi’s.

Steinberg V-Stack & FX-Max FX-Teleport operate at the same efficiency as they do on 32-bit, but still being 32-bit applications, their total memory is still capped at 2GB regardless of how much system RAM you have installed. As such, they also cannot load 64-bit VSTi’s. Their addressable memory can be easily expanded to 4GB. See below.

MIDIoverLAN CP 3 works well on 64-bit for transporting MIDI over a network.

Newly engineered samplers, such as East West’s PLAY sampler (http://namm.harmony-central.com/WNAMM07/Content/EastWest/PR/PLAY.html) that is bundled with their new sample libraries, boasts the ability to take advantage of 64-bit fully.


Memory: 32-bit vs. 64-bit

32-bit Operating System:
Typically 32-bit Windows will only "see" 2GB of RAM in total, regardless of how much physical RAM is installed. With the useage of the "/3GB" switch in the boot.ini file, Windows will "see" up to 4GB of physical RAM. The reason why it's a "3GB" switch and not a "4GB" switch is that Windows has to emply a bit of a work-around in order to utilize this memory. It reserves the top 1GB of RAM for the system and free the remaining 3GB for applications. For instructions on how to set the 3GB switch, click here.

64-bit Operating System:
The "3GB" switch has no effect on 64-bit Windows because it can already address 128GB+ of physical RAM.

32-bit Applications:
32-bit applications have an inherent limitation of being able to occupy no more than 2GB for each app. This is true for 32-bit and 64-bit OS's. There is a simple fix for enabling a 32-bit application to be able to address up to 4GB for itself. (See below)

Addressing the RAM Issue

There’s a number of techniques to get the most out of large amounts of RAM. Until better solutions arrive, users wanting to take advantage of more than 4GB of RAM need to arrive at some compromises. No current single solution can occupy more than 4GB of RAM with 32-bit VSTi’s. As detailed above, Sonar may be 64-bit native but is still limited to the 32-bit memory cap when loading 32-bit VSTi’s.

  • LaaTiDo LAA extension
    There is a wonderful utility that enables 32-bit applications to load up to 4GB of memory instead of 2GB. It may not offer the full benefits of 64-bit addressing of 128GB+ of memory per app, but it’s a big help in the meantime. More details and download location available here:

    http://www.musikbanken.se/TechLaaTiDo.aspx

    This can, for example, enable a stand-alone Kontakt to load approximately 3.5GB of sample memory instead of hitting the 2GB ceiling.
    • Note that Sonar 7 32-bit is already Large Address Aware and will load up to 4GB without this utility.
    • The “/3GB” switch is not necessary for 64-bit operating systems, it only applies to 32-bit operating systems.
    • It may have little or no effect on Gigastudio, as it has very tedious issues with memory and can be unpredictable. I have yet to properly test the utility on Gigastudio 3.


Solutions

  • Run two or more VST hosts concurrently
    Users have had success running two hosts, each being able to address 4GB of RAM, in order to fill 8GB of RAM, for example. Sonar and V-Stack should play nice together, as long as your audio driver is non-exclusive. Sonar does not need the LaaTiDo patch, but V-Stack will, as will most other 32-bit hosts. You can also use Forte or Virtual Mixing Console (VMC) as alternatives but people’s general experience is that latency is higher with Forte or VMC however.
  • Run multiple samplers stand-alone
    With the LaaTiDo extension, a stand-alone version of Kontakt or another stand-alone sampling application can load upwards of around 3.5GB of RAM. Users have had success running two Kontakt instances to fill 8GB of RAM, for instance.