After a slow start, OSX is starting to look quite promising for musicians, judging by behind‑the‑scenes news from MacWorld and an independent report pronouncing it the 'least latent' OS, especially under pressure. Paul Wiffen reveals all.
Having had an opportunity to think for somewhat longer about the recent New York MacWorld show than I was able to do before last month's column, I have come to the conclusion that music and audio for OSX is beginning to shape up nicely, despite the fact that the musician's interests were less in evidence than in previous shows (no Music and Audio Village, and very little mention of the subject in keynote speeches or other public presentations). Of course, it would have been nice if the audio improvements in 10.1 had been mentioned in the keynote speech, along with the less critical (for us, at least) visual and general improvements, but we have to learn to accept the fact that for most mainstream Apple users, audio is an addendum which is always going to take a backseat to the main areas of performance. The most important thing is that key issues for audio are being addressed behind the scenes. It doesn't really matter that we discover them on day two of MacWorld from a more lowly Apple spokesperson in a one‑to‑one demo, rather than having them trumpeted to the world by Steve Jobs in the opening presentation. But just where does my greater optimism for the audio future of OSX come from?
Firstly, the greater performance of which 10.1 is clearly capable should mean that at least simple, everyday system operations such as opening files and redrawing waveforms are not slower than under OS9 (which definitely seemed to be the case in the first release of OSX). Secondly, the fact that Emagic and BIAS were able to get flagship programs like Logic and Peak demonstrable under 10.1, so soon after being 'seeded' with the 10.1 beta, means that it should not take long for other music companies to follow suit (many of the audio 'hooks' which they needed were simply not present in the original release of OSX). I know that Steinberg are not far behind with first Nuendo and then VST.
But the most exciting thing is that, finally, after all the years of waiting, multi‑channel operation of the Mac OS is finally on the cards. The advantages of this are not limited to just mixing numerous channels through external mixers and recording more than two channels at once (which, after all, has been possible for years with extra hardware). Rather, once the OS itself supports multi‑channel operation it will be possible to always have one program output on certain channels and another on completely different channels. Then using a multi‑output PCI card or FireWire device would mean that you could bring these separate outputs up on different channels of a mixing desk, even going as far as labelling the channels on the desk where your different 'instruments' appear.
Of course, these facilities are nothing new to many Mac users, but they have always been handled previously by a main audio application, such as Pro Tools or VST, taking direct control of the additional hardware through DAE or ASIO. This, in turn, has meant that any secondary applications, such as virtual synths, have had to be updated to be compatible with either Direct Connect or ReWire for the master application to be able to handle the separate output assignment. The result has been that, for long periods, one virtual synth has been able to work properly with main application A, but not main application B from a rival company, while another virtual synth works with B but not A. In other words, your choice of virtual products has been primarily made by which main application they can best be used with, rather than which sounds right for your needs. Once multi‑channel operation is supported by the OS itself, all that the various producers of each virtual synth or sampler have to do is support the one, standard, way of achieving separate outputs.
It is not that the separate output systems, such as Direct Connect or ASIO, introduced to make up for the lack of such I/O in the OS, are not good enough. They clearly are, as evidenced by the large numbers of people using them. It is rather that the work required to support several of them is a large burden on the (normally) much smaller companies who produce virtual synths and samplers. With OSX, they will all be able to spend more time on what they do best (sound generation and modification), rather than having to invest many man‑hours in evaluating the different multi‑channel I/O standards and the size of their installed user base, and then prioritising and writing the appropriate drivers for compatibility. I have always felt that this process robs us of even better sound generators, as key programmers get bogged down in areas which a) take up time and b) don't particularly make use of their special skills.
My more upbeat reflections on the future of audio with OSX were further vindicated, after I had already begun to commit some of these thoughts to word processor (it just doesn't have the same ring as 'to paper', does it?), by the arrival of a forwarded document in my email. Thanks to Jean Beining, who was first to point us to a MacWorld magazine story on the results of a report entitled 'Audio Latency Measurements of Desktop Operating Systems' (www.macworld.co.uk/news/main_new...) and asked that it be mentioned in a suitable place in our pages. Where better to report that Apple come out best in an audio test? (Except, of course, that here I am preaching to the converted, instead of the sinners out there in Wintel land!)
Authored by Karl MacMillan, Michael Droettboom and Ichiro Fujinaga of the Peabody Institute (part of Johns Hopkins University in the USA), it compared the audio latencies of numerous different systems, from the everyday Apple and Windows to more nascent ones like Linux and BeOS. The researchers found that OSX offered the best latency speed of all operating systems and platforms when running multiple applications. While it produced comparable figures (under 3mS) with the other systems on test in unloaded situations (ie. when the CPU was not having to work very hard), it was once the system load became heavier that OSX really shone. Its loaded latency figure of 2.83mS was identical to that in the unloaded test. Other systems which had a slight edge in the unloaded test quickly deteriorated under system loading. The best of them, Linux 2.4.1, which had edged out OSX on a 400MHz G4 at 2.72mS in the unloaded test (running on a 933MHz Pentium III with a third‑party audio software patch), could only manage 4.3mS once loading was applied, despite then being run on a dual‑processor PIII.
It is, of course, the loaded figures we should be looking at. Who has not had the frustrating experience of testing a newly‑arrived machine in splendid isolation from the stresses of everyday use with a simple audio or MIDI recording and pronouncing the results excellent, only to suddenly find that in the middle of a 'real world' project, latency problems occur? It is one thing to ask an OS to deliver low latency when playing back a couple of audio channels. It is quite another to get the same results when pumping out loads of MIDI, performing numerous EQ and effects routines and playing back half a dozen softsynth channels with high polyphony. Yet most of the time it is the latter we are asking the OS to do (especially at mixdown, when all the playback delays get set in stone).
The authors of this report conclude that "the new CoreAudio API, which was introduced with OSX, is clearly designed for low‑latency performance, and allows multiple programs to access the soundcard concurrently. Only an experimental system called Linux Audio Application Glue API provided comparable performance." If that isn't a reason for optimism, I don't know what would be. Now all we need is patience while the software houses get the support for this major leap in latency performance in place. It will certainly be much, much sooner than any of them will have their major products working with Linux, let alone this "experimental" Audio Application Glue (sounds messy!).
Since I threw a quick reference to a Czech website which used QuickTime VR into Apple Notes, I have had a few emails claiming that I am behind the times, that everybody is using it (well, estate agents, at least) and that I should have done more research before opening my big mouth. Even our esteemed publisher said that he had seen QT VRs on some upmarket studio web sites, including the RealWorld site. Apparently there is even a QT VR of our editor's studio on the SOS web site. All I can say in my defence is that I can only afford small, cheap studios, I don't spend as much time on the SOS site as maybe I should, and that I (happily) have a minimum of interaction with estate agents, so this is probably why I hadn't seen very much evidence of QT VR on the Internet.
However, the end result is that now I have seen a few more sites using QT VR and have also uncovered some clues as to why more don't. I am grateful to Moose, who emailed in the URLs of several examples of studios for whom she has done a QT VR number. You can see these at www.chicanemusic.com and www.alaskahighwayonline.com (then select pictures). She also appears to spend much of her time doing QT VRs of other subjects, some of which you can see at www.citrusgrove.com/qtvr.htm
Moose also advanced a very sound reason why fewer people use QT VR than I might have hoped. Apparently, in the US at least, people are quoting $10,000 or more to create a single example of the genre. Even in the UK, where we don't have quite so much money to burn, it is still apparently likely to cost you an arm and leg, so this might very well explain the relative paucity of examples on the web. However, an increasing number of sources for more economical QT VR are springing up, so maybe this will be reflected in the number of times I come across it in the future. If you fancy creating your own VR movies, check out VR Worx 2.0 ($299.99) from VR Toolbox (www.vrtoolbox.com).