Inside the BeOS Media Kit

BeOS provides a powerful media foundation.

Scot Hacker, 12/00

Setting Priorities

Ever wonder why BeOS is sometimes referred to as "The MediaOS?" After all, most industrial-strength audio and video applications are released only for MacOS and Windows. But just because those platforms own the market doesn't mean they necessarily provide the best infrastructure on which to build media applications.

For years, Be engineers have placed their greatest emphasis on optimizing the system for high-bandwidth media performance. Any time a question about how to implement some aspect of the system architecture arose, Be engineers would re-pose the question as: "Which technique would give us the best media performance?"

Because that question was asked during the design of the filesystem, BFS is optimized for handling large files, rather than small. Because the question was asked while the kernel was being developed, the BeOS scheduler always "gives highest priority to timing-critical media, like audio." And, of course, the pervasive multithreading that gives all BeOS applications maximum responsiveness under heavy multitasking loads was conceived with media performance foremost in mind.

It is for reasons like this that BeOS can address audio hardware as much as seven times more efficiently (i.e. with much lower latencies) than Windows running on the same machine, and why it was possible to play four QuickTime movies and eight MP3s simultaneously back in the day when a dual 233 BeBox seemed like a rocket ship.

The fact that it's pretty much possible to do the same thing on Windows and MacOS today points to something that's been on my mind a lot lately -- consumer-grade hardware has become so fast that it's capable of steam-rolling through difficult media tasks by brute force, rather than addressing problems through efficient operating system design. The purist takes the stance that BeOS is faster on equivalent hardware. The realist responds that it doesn't matter -- with a PIII 800 and a bunch of RAM, the end user still gets a pretty good media experience under Windows. The rapid evolution of the hardware world has effectively erased the perception of Windows and MacOS being slow, and thus threatens to undermine the impact of a key BeOS selling point.

But BeOS hasn't been referred to as "The MediaOS" just because it offers great media performance. It also offers a sophisticated media infrastructure -- one that has no parallel in the Mac, Windows, or Linux universes.

A Kit To Call One's Own

As I've described before, BeOS is built on a client-server model. Internally, you've got a net_server, an input_server, an app_server, a media_server, and so on. The BeOS programmer deals with the object-oriented BeOS API, which is divided into a series of "Kits," including the Interface Kit, the Storage Kit, the Network Kit, the Game Kit, the Media Kit, and so on.

So what does the Media Kit do? What does it get you? For starters, it provides microsecond timing controls, which allows application developers to synchronize audio and video -- even between disparate applications -- with relative ease and a high degree of accuracy. Any media "node" can also be used as a timing source -- an app developer might decide that the audio stream is to be considered the basis of all timing-related issues, and time the display of video frames by using the audio stream as a sort of clock. "Time" can thus be made to progress faster or slower than real time, as dictated by the needs of the application.

More importantly, the Media Kit provides a unified and consistent method for media streams, files, hardware, and applications to intercommunicate. It accomplishes this by allowing any media object to act as a "consumer" or a "producer" (or both). When an object is instantiated, it publishes itself to the system "roster," saying in effect, "Here I am, ready to produce the following types of media streams," or "I exist, and am ready to handle any media you throw my way."

Media objects, or add-ons, can also publish "nodes" which are like sets of properties or controls. Through this system, a piece of media hardware connected to or installed in the system can present itself identically to any application that wants to make use of it. The flexibility of a system like this has to be experienced to be appreciated.

As an example of how all of this fits together, consider a digital video camera connected to the computer via FireWire. When the system detects the camera, it becomes a system object, and its control nodes (rewind, fast forward, play, record, pause, stop) become available to any video application that wants them.

As a result, plugging in a DV camera causes it to appear immediately in the Media preferences panel, which includes a set of controls for operating the camera. An application like personalStudio doesn't need to bother learning about specific cameras or FireWire cards. It simply slaps its own user interface over the nodes already published to the system.

Compare this to the Windows model. When you connect a DV camera to a Windows computer, nothing built into Windows will let you control the camera -- you still need to install a 3rd party app like MotoDV if you want that (unless you're using Windows ME, which includes rudimentary DV tools). And while DirectX does enable app developers to control cameras without knowing all their specifics, the model is not as clean or elegant as that provided by Be's Media Kit.

To be fair, DirectX has improved steadily over the years, and has recently come to offer most of the pluggability Be's Media Kit has offered for quite some time. However, DirectX programmers are left having to debug Windows kernel mode code -- an unpleasant proposition to those weaned on the BeOS development model.

The Media Kit also provides audio and video applications with access to media encoders and decoders installed on the system -- both those which ship with BeOS and those added by the user later on. This frees application developers from having to know how to decode or encode specific types of media.

Technically, Be needs to publish the API for codec development in order for 3rd parties to release codecs guaranteed to work correctly. In the future, it should be relatively simple for 3rd parties to create codecs that will automatically work with installed media applications.

Fun with Cortex

Until recently, few BeOS end users fully grasped the flexibility of the Media Kit's architecture. Then Be engineer Eric Moon released Cortex, a graphical application that lets end users connect and disconnect BeOS media add-ons at will.

Cortex is currently billed as a developer's testbed, not as a fully functional application. Its rough edges should be smoothed out in the future.

Rather than having to wait for application developers to figure out clever ways for their audio and video applications to intercommunicate, BeOS users can now gaze into the belly of the Media Kit and decide how its "organs" should be connected up.

For example, a user might want to take SoundPlay's output stream and route it through an effects filter before sending it on to the sound card. Or load digital video files into a DV camera without using a dedicated DV editing application. Or, theoretically, encode an audio stream being generated by a synthesizer or tone generation application straight to MP3.

With Cortex, the user can see currently attached audio and video hardware and currently running audio applications, and know all of their possible inputs and outputs instantly (it's important to understand here that BeOS is the one keeping track of all these things -- Cortex just presents a graphical interface onto them). These inputs and outputs can be hooked up on demand by connecting and disconnecting the appropriate "wires." See this tip for one example of a young version of Cortex in action.

cortexsmall.jpg
Cortex lets you manipulate connections between BeOS audio and video applications, hardware, and add-ons. Click for full-size version.

The example above shows off another cool tool that's been gaining traction in BeOS audio lately -- the collection of VST plug-ins that have been ported to the BeOS Media add-on format. VST plug-ins, developed originally by Steinberg and later released as an open source specification, are like software versions of a guitarist's effects boxes. The plug-ins have gained cross-platform currency as an audio plug-in standard of sorts.

When used under MacOS or Windows, you install and use VST plug-ins in concert with specific applications. Yes, you can have several Mac or Windows apps that all draw on the same pool of plug-ins, but those apps must be designed to work with VST plugins, and you can't use them as inter-application effects. In BeOS, they function as plugins to the operating system itself. Thus, you can use VST plug-ins as effects filters situated between any two audio apps (whether they were designed to communicate with VST plugins or not), or between an audio app and your sound card.

As an aside, SoundPlay has recently implemented the VST API, so users can now use their centralized collection of VST plug-ins to manipulate any audio stream handled by SoundPlay.

Does It Matter?

BeOS may provide an outstanding architecture on which to develop next-generation audio and video applications, but that's not the whole story. As always, the chink in the armor is momentum, or the lack thereof.

While there are a lot of very cool audio and video applications available for BeOS, the big names in media aren't exactly falling over themselves to deliver high-end tools. We're all very much looking forward to the coming ports of BIAS Peak and Deck, but most A/V apps for BeOS have been created by small developers working in their spare time.

The Media Kit is a unique Be creation, and is conceptually unmatched by anything provided by MacOS, Windows, or Linux (although again, Windows is getting close as DirectX continues to improve). As of now, the Media Kit remains a shining jewel of untapped potential that could have spawned a cottage industry... if history had played itself out differently.

Those of us who believe BeOS is compelling enough to use with or without massive industry backing will continue to enjoy its small and large advantages. So what if the world pays little mind? We have our personal pleasures, and sometimes that's enough.

BeView Content Archives