BeOS Gaining Ground

Part 5: The Programmer's Perspective

Now I'd like to take another look at BeOS, this time from a programmer's point of view. I am not a full-time programmer, or even a very experienced programmer for that matter. Audio programming is just something I love to do, so this will be a high level overview.

When I first got started with audio programming, I was doing almost all of the work on SGI machines, which is where I was exposed to Csound. Doing the basic audio I/O on the SGI was pretty straightforward and I developed an app for doing some real-time effects. Once I moved and no longer had access to the SGI's, I needed an alternative. I had some tools for Windows so I figured I'd give that a shot.

Ughh! There is no comparison between Microsoft's interfaces to the audio hardware and SGI's. Porting my program turned out to be a rather painful experience. Being a recreational programmer, I didn't want to have to waste my time doing the low level routines. I had been keeping my eye on BeOS before that, and was very interested because the API was somewhat similar to that of the SGI. The problem was that I didn't have a BeOS capable machine at the time. That changed a while back when I got a new PowerMac and I finally had the chance to test it out.

C++ is the native language of BeOS. You don't need to buy any special tools to get started developing a program. A compiler by Metrowerks is included. The linker portion is limited to 64K, but you can actually create a fairly good sized app even with that limit because of the shared libraries. One problem with the limited linker is that it doesn't allow you to use any of the iostream or fstream functions, but you can actually get around this. The Be web site contains a header file that you can use to replace the standard iostream.h that gives you most of the functionality with standard C routines. For my program, I also needed the fstream library functions, and it was pretty straightforward to create my own fstream library and classes using the C routines. With these changes, I could do everything I needed without buying the unlimited linker. R4 for Intel will introduce a new set of GNU-based tools, which should offer better performance, and possible no linker limit.

For the actual audio data, the BeOS uses the concept of streams. There are streams for incoming and outgoing audio and these streams are accessible to any application. You subscribe and enter the stream to gain access. This truly is a great feature because your application will always be able to access the streams - you don't have to worry about another application monopolizing the audio ports. This is very nice from a user's perspective since they will never get an error message that the audio port is already in use and they can't use your program. You can also control the where your application subscribes to the streams relative to other applications. For example, say you've created a spectrum analyzer program. If you want to examine the spectrum of the audio being generated by the other programs, you could have the spectrum analyzer subscribe to the last position in the output stream, after all the other programs have added their data to the stream. This is now possible, although you can't lock the stream location - another application could come along and subscribe to the stream after your program.

So how hard was it to port my program to BeOS, running on my PowerMac? Absolutely nothing compared to the move to Windows. I actually spent more time working around the iostream and fstream limitations than getting the audio working on BeOS! With a small amount of optimization, I had my application processing an external audio source in real-time with a latency of 21 milliseconds. This compares to the 280 milliseconds or so I managed in Windows (but not using DirectSound which would offer some improvement.) Not bad. The BeOS API is clean, simple, and very quick. In some ways, the API in R3 is too simple however and some changes need to be made.

Be wants their system to do anything you could dream of, so they're trying to build a really strong foundation which you will see with the R4 release. It's a totally different beast and it will take some more programming build your app. The new Media Kit will handle both audio and video in a professional manner. BeOS comes with a mixer for audio and with R4, applications that want to generate audio will cause the mixer to grow new channels specifically for that application. This still ensures you will always be able to send your audio to the physical output device and it lets the user manage all programs easily. In fact, it looks like any two applications may be able to send audio streams amongst themselves with this new architecture. R4 will also include a protocol for asking the system what latency your program will encounter and notifying the upstream objects if they are late in providing your app with the audio data. Support for 24-bit audio is also in place. Be is looking forward to multi-channel formats like AC-3 and DTS, but don't expect to see support for all the various codecs and sound formats, at least right away. R4 will be a framework with many holes left to be filled. Give Be some time. They are producing a very capable system that should last a long time and I am anxiously looking forward to seeing it implemented.

Of course, if you want to build an app to sell, you have a very small installed base to work with, but that may change with time. Hard core programmers may find many things missing in the overall API, but for experimenting without being overwhelmed with complexity, I find it to be an attractive option.

I wish I could say it's been fun Windows, but for programming, I think it's time I moved on to better things.