Bring in the Noise Interviews Stephan M. Sprenger

In the days before I decided to rip of slashdot and let you the readers do the interviewing, I asked Stephan M. Sprenger of Prosoniq to submit to an interview by your dedicated columnist. Stephan graciously agreed and I sent him a few questions. The answers to even the silly ones are below. I wanted to do an interview about the future of audio software on Macs, namely OS X and Altivec, and Stephan fit the bill perfectly. First, he is the man behind some software I really like, including what I think is the best editor on the Mac, sonicWORX. Second, he is a dedicated DSP guru, he works almost exlusively with the low level audio DSP code, not with pushing pixels around the screen. Not that I don't respect pixel pushers, but you see a whole lot of information on this web thingy about graphics and how they work, and not nearly as much about how a computer works with audio. He writes PPC assembly, which means he's a nasty hacker as well. Prosoiq wrote much of their original audio software for Silcon Graphics machines, which use both a RISC processor and the SGI flavor on UNIX, called Irix. Irix includes a lot of the same buzzwords and UNIX guts as OS X, things like protected memory, support for multiple processors, and we hope a full featured set of professional audio tools in the OS. With that background, I couldn't think of a better person to ask these questions.

I want to thank Stephan for taking the time out of a busy schedule to answer these questions. To be perfectly blunt, you should be VERY happy to get this kind of information from a source this knowledgable. I may miss a week or two here and there, but not a lot of other audio columnists will find out about compiler checkboxes and PPC instruction sets for you. He he he . . .

Q: Just generally speaking, what do you think of Altivec for audio DSP? Is it designed and implemented well? Will it live up to the hype? Are you excited about what it can do for your applications?

Personally, I'm very excited about AltiVec since it makes it possible to have some of our artificial neural network algorithms run in real time. This has been a problem with conventional CPU chips due to the lack of performing several calculations in parallel. Our algorithms require the CPU to do floating point calculations on a massive stream of data and due to the structure of artificial neural nets they are naturally predestined for AltiVec optimization. The SIMD (Single Instruction Multiple Data) processing technology used in AltiVec makes this processing come true for the first time on a desktop computer what has been a privilege of scientific computing systems that use a supercomper architecture to do vector operations on very long sequences of data in parallel. One could also say that AltiVec is the supercomputing for consumers. We look forward to experience a speed gain that is at least perceivable, if not dramatic, both for rather traditional algorithms like our OrangeVocoder and our novel technologies like MPEX which is used in TimeFactory.

Q: I have been told that the really fantastic thing about Altivec is that it can do the same operation on four 32 bit words at the same time. That's convenient since most all audio apps process their audio as 32 bit floating point samples. However, will this only be useful if you are running four versions of the same plug-in or process at the same time, or can smart guys like you have the same thing being done to different part of the same file? In other words, will Altivec give me more instances of the same processes, or more discreet processes or both?

Actually, neither. The parallelization happens inside the processor, and thus inside an algorithm, invisible to the user. AltiVec can indeed process four 32bit floating point operations in parallel, but it can also do 8 and even 16 calculations in parallel when you're working with integer data. This will allow for very fast execution times on data streams like computer graphics or raw PCM audio data. So while AltiVec will not really allow the user to directly run two DSP processes in parallel like you suggest - that is, one on the AltiVec unit and one on the PPC - it will lower the overall computational cost of an algorithm when the developer uses the AltiVec unit, thus indirectly allowing more processes to run in parallel on that machine. So what you will basically see as a software user is that AltiVec optimized products will simply run faster - our tests show that between 1.5 and 3 times as fast as on the G3 CPU is not unusual - giving you more bang for the same bucks. It is, however, a matter of fact that the software has to be partly rewritten in order to bring this advantage to the user and this might delay the actual benefit of this technology before it reaches the end user. In my opinion, the standard instruction set of the PPC processors should have been improved upon in the first place, by including hardware loops and more DSP specific instructions instead of adding an entirely new architecture. However, this way we can expect a leap instead of a step to faster software, which is also great even if it needs rewriting some of the code completely.

Q: I have a copy of Codewarrior 5. It includes Altivec support in the compiler. Is it enough to check the "Altivec" box when compiling, or is there still more work to be done for audio apps? If there is more work, how involved is it taking advantage of the new processor?

Basically, that would depend on how the Mwerks compiler sees and optimizes your code. Checking the box can produce optimal speed for algorithms that are easy to grasp for the optimizer and are thus automatically sufficiently parallelized. Nonetheless, the old assembly coding rule still applies: a good programmer can do a better job than any optimizer, since the optimizer does not have an idea about the overall inner workings of the code. If I check the AltiVec instruction set option in my compiler it won't give me a great improvement in speed for our algorithms, as the optimizer will not be able to rewrite my code properly (that has been optimized to work on PPCs) to really use the features of AltiVec. For a large part of our code, I will need to do this manually. Additionally, some of our algorithms, like the OrangeVocoder filters and NorthPole, are directly written in PPC RISC assembly. These will have to be rewritten, probably from scratch, to use the AltiVec unit. We're currently already working on that.

Q: It seems that many pieces of long standing audio software, like DAE and OMS, are going to have some problems with a transition to OS X. Why would that be, and what will be challenging about developing for OS X?

Well, MacOS X is an entirely different system. The basic unit is Darwin, based on the Mach 3 kernel, which is actually a BSD 4.4 compliant UNIX (it's just not called BSD since it's lacking X-Windows) which is a lot different to the MacOS we all know and love. Although you can still run most classic MacOS applications from inside the emulation, migration to the native OS X is in order to make full use of the SMP capabilities, memory protection and other benefits OS X brings the user. Fortunately, after the software industry has turned the Copland proposal down, Apple have adopted a different strategy for the transition to the new system which should be quite seamless for most applications. Nonetheless I would expect that in the OMS and DAE case it would require rewriting these specific applications entirely, although the future of OMS still remains in the dark and Digidesign doesn't officially comment on OS X yet.

Q: We all know that OS X is supposed to support Symmetrical Multi Processing. We also know that the G4 chip is SMP capable. Will audio programs be able to use multiple processors? Are there any specific problems writing audio DSP using multiple processing?

Principally, this would to a large part depend on the OS. If the OS itself supports scaleable machines with multiple CPUs and schedules the processes accordingly, no change would have to be made to the actual application. This is the case, for instance, with the SGI IRIX systems. However, for optimum results, and on machines that are dedicated to running audio applications, parallelizing DSP algorithms between multiple CPUs can again bring a great gain in speed, both for the application as well as for a single process. Like with the AltiVec option, when an algorithm can be broken up into separate, preferably alike and independent subsets, both multiple CPUs and AltiVec can mean a great gain in speed. As a matter of fact, simple numerical operations can be done as much as 10 times as fast compared to the PPC when AltiVec is used, with a factor of 2 or 4 in the ideal case for 2 or 4 CPUs. In practice, this is not realistic though.

Q: Will latency be better or worse in OS X, or is it not possible to tell yet?

I'd say that this depends to a large part on the Apple engineers and other hardware/driver suppliers and whether they do their homework. I'm not sure if this can be answered already before we see a final release of OS X with "native" drivers.

Q: What's with all of the damn "boxes?" Will audio apps run better in one box than the other? Will running an audio application in the "blue box" emulation hurt performance dramatically?

Apple has caused a great confusion with their boxes and their colors, so they are now calling them "Classic" (for running classic MacOS applications as they are today), "Carbon" (basically a way for porting MacOS applications to OS X without much change) and "Cocoa", which allows developing software directly for OS X. If the software runs under the MacOS X environment at all, I'd not expect it to make a great difference with regard to algorithm performance which of the three levels it has been developed or running on (if we leave out SMP issues for the moment). This is so since the main changes between the levels are calls to the MacOS toolbox routines, which are used for managing user interface, memory, resources and i/o stuff, but not really algorithm specific, timing critical code. It's certainly not like with 68k vs. PPC code where one could expect an emulation to degrade performance perceivably.

Q: We are also told that OS X marks the real final end of 68k code. Is that a problem for audio apps or are they all PowerPC code anyway?

I don't think that this is a problem. Prosoniq has discontinued 68k support long ago and we did not get one single complaint. Todays software usually does not contain 68k code anymore, some applications use 68k assembly resources for ADB drivers and other non-timing critical parts, but these relics will also soon disappear and be replaced by native code, at last when the transition to USB is finally complete on all levels.