PC Audio 127

My time with PC Audio started way back in the days of 8-bit computer games, when clients started to ask if I could compose music for their PC games, as well as for the Commodore 64, Amiga 500, and Atari ST machines I was already working with. At best, those early PCs could manage a beep, courtesy of a tiny buzzer on its motherboard whose voltage could be toggled high or low. So, for instance, if you wanted to produce an A440 squarewave (the only possible waveform!), you had to code a routine that sent the appropriate commands 440 times a second. Some PCs even had the luxury of a tiny loudspeaker (typically with the same capabilities, but at least capable of making a somewhat louder noise). Then the industry moved on to the first plug-in soundcards, from the humble Adlib (with rather tinny 11-voice FM synthesis courtesy of the same Yamaha chip used in its PSR and PSS keyboard series), to the first Soundblaster soundcard, with 8-bit audio sampling. I even got to write MIDI-based music for Roland’s LAPC-1 PC expansion card!

CHIP OFF THE OLD BLOCK 

Just recently I had the opportunity to dust off my extremely rusty programming skills, when I was once again asked to write some music for the Commodore 64’s famous SID chip (Sound Interface Device). The C64 was the best-selling home computer in history (apparently over 17 million were sold), and SID was also the most famous 8-bit sound-making device of the time. Devised by engineer Bob Yannes (who later co-founded Ensoniq), it contained three oscillators each offering four different waveforms, plus three ADSR envelope generators, a multi-mode filter, and even ring mod and sync options, all with hardware personality. This was revolutionary stuff in 1981!

However, what really surprised me all these years on, is that the PC can now accurately emulate the SID chip via software. So, I didn’t even need a C64 to write this music. This time I could create it all on the PC, even down to auditioning the small changes in how this music would sound when played back by the various SID chip revisions manufactured over the years. Even better, the entire C64 is now available in PC emulated form for free download, courtesy of applications such as VICE (Versatile Commodore Emulator, available at vice-emu.sourceforge.net). Frankly, I was amazed at how accurate these emulations were, even down to incorporating bugs in the original hardware that still need to be carefully worked around (like the infamous SID ADSR bug that occasionally results in a 33ms delay before the envelope switches between a slow and fast envelope rate). The SID chip has even been re-created for the PC in VST Instrument form, most notably by Plogue, whose chipsounds VSTi (plogue.com/products/chipsounds) authentically emulates 15 different vintage 8-bit era sound chips in incredible archaic detail.

WHAT GOES AROUND COMES AROUND

However, as I waded back into 6502 assembly language programming to update my C64 music driver routine (this time assembled and run using my PC as a ‘pretend’ C64), I began to realise just how many parallels there are between coding and music-making in general. There I was, shuffling the order of my audio driver code segments to optimise their average CPU overheads, paying particular attention to avoid any unexpected peaks of demand that could result in the game graphics glitching or juddering. Then it suddenly struck me that this is exactly the same problem that still affects so many modern PC musicians — attempting to achieve low latency audio recording and playback without glitching, and for exactly the same reason. It only takes one errant Windows routine (even something seemingly unrelated, such as network sharing, or automatic updates) to unexpectedly demand more than its fair share of  your PC resources to tip your audio buffers over the edge, resulting in audio clicks, glitches and eventually sonic juddering. Countless articles have been written (some by me!) on how best to tweak the various Windows versions to achieve lowest audio latency, particularly vital while recording with plug-in effects or playing back VST instruments in ‘real-time’.

Modern developers also have to bear average/peak CPU requirements in mind during the design of software plug-ins and instruments, as a single unexpected CPU peak demand significantly beyond the norm might stop your DAW in its tracks. Some developers may even offer run-time quality options in their products that manage the average CPU, to keep this overhead lower during mixdown when you demand ’real-time’ performance, but let you increase it to maximum when you render the final track off-line, to achieve higher audio quality.

PEAKS & TROUGHS

The more I thought about this process of keeping an eye on the average and avoiding unexpected peaks, the more audio parallels I came up with. The most obvious one is compression itself, a technique designed to do exactly this — adjust the average audio levels while taming errant peaks — although we don’t want to be too heavy-handed about it and suck the life out of the music. Another common problem that so many of us face when mixing is allowing enough room for every sound to breathe. Once again, if we pile up too many similar-sounding instruments at the same time we can end up with a muddy mix.

Some resort to EQ sculpting on each track, to carve out some extra space for each element and let them breathe, but often a far more successful ploy is to consider the musical arrangement itself. For example, do you really need those six guitars playing at the same time? Does that bass sound complement the kick drum, or do they conflict frequency-wise? It’s often beneficial to juggle musical segments so that each one has its chance to shine in the overall mix, rather than fighting each other for space, exactly as I was doing with my code segments. There are, of course, negative ways to manage this balance between average and peak levels, as we know so well from the so-called loudness wars on commercial releases.

Nevertheless, the quality of these gaming computer emulations running inside my PC via free downloads was stunning, and I realised how closely this parallels the audio plug-in world. There will always be a place for hands-on hardware (I still build some myself), but there’s now little discernable difference between the best plug-ins and the hardware they model. Yes, some will be able to tell the difference, but in a blind test I’d be surprised if many people could reliably tell which was which, and even those who could, might begrudgingly agree that using the plug-ins makes far more sense on the many occasions when a mix may need to be recreated in the minutest detail months after the event. Nostalgia isn’t what it used to be — now it’s far more about software emulation!