As a professional composer and musician using linux, i’d add a couple of things to this thread.
Ben Loftis makes some good points in his post, and hits the nub of any discussion about professional sound.
1.) A central mixer is essential. I’ve gone the route he described in the past, using an app’s built in mixer just to try and have a central mix core into which i can add any number of apps. Now i use a little app called non-mixer, as it’s the only mixer i’ve found which does the job as a standalone for what i do. (As a writer of orchestral and film music, my port requirements are in the hundreds, not the tens, and many professional audio and midi apps are written for “headbangers”, excluding my unique requirements, and lacking the extensibility to use many more tracks, ports, etc.)
2.) Jack, for all its strengths and weaknesses, is ideal (more or less) for professional audio use. It seeks to fulfill the requirements for a multiapp working environment, and does so at low latency. Those that know will appreciate the value of this, recording not only from live sources, but building scores, tunes, etc… with software tools inside the box, and hardware tool outside. (Synths, samplers, blah blah blah)
3.) Extending what is a domestic API may well seem like a good idea, but it’s basic flaw is in user requirements, those of domestic users, where generous buffers and high latency are essential for great playback of movies and tunes, versus the time essential low latency requirements of the professional user. Pulseaudio, for all it’s strengths and weaknesses, and i assume this is akin to the Haiku API, is built for domestic users, and there are many trainwrecks in fora as the discussions rage on about the “worth” of pulseaudio versus jack, or indeed directly using alsa. It’s FUD to assume that a domestic API will satisfy the needs of a professional user, and this FUD is often spread by well meaning devs who think they know what professional requirements might be, although they have no experience in that field.
4.) This also applies to Video playback, and as someone who writes to image, all too often the sync between audio and video devices is less than optimal, because the sound api doesn’t neccessarily sync to the framerate in vid. Jack has a common Transport API that can be implemented in both audio and video apps, and in the linux world, Xine is one of these Jack Transport capable apps, able to show vid synced via jack transport with any other jack transport capable app. A domestic api lacks this sync, or framework for syncing, and renders itself more or less useless for such sync required work.
5.) MIDI is the hairy red headed step sister of any professional working environment, and all too often, this protocol is poorly done, not only at app level, but at server, or framework level in APIs. Jack at least attempts to rectify this in some way, with JackMidi, a sample accurate midi framework that syncs by default with JackAudio using as it does timestamped events, and doing so within a specified period, as for audio. Any consideration of a professional grade sound/vid/midi API should, by default, include the required components to deliver sample accurate MIDI, and without jitter, or uncertain timing. There are many users, professional and domestic alike that use midi, yet all too often it’s “tacked on afterwards” as an afterthought, rather than considered as part of the whole professional API, and integrated at initial development, by developers whose vision is of a studio with a desk/console, and that’s…professional. It’s just one part of a much wider picture, and you’re more likely to see a film score, or recording studio setup, in the 21st century, on a box, with a widescreen. Large console studios are still viable, of course, but there’s a lot of users working with a software mixer, and plugins, at a paid level. A colleague of mine has a large console and Protools rig, yet his editing work for the last 2 years has been on a computer, using another DAW, because it does the job. He’s on Windows, poor soul, but he makes a valid point when he says it’s cheaper and quicker to edit this way, than crank up the desk and PT rig, to the same finished product standard. (Which makes yet another case for a central software mixer as part of any professional sound API)
6.) With the rise of smaller devices, like phones, handhelds of some description, netbooks, laptops, and so on, there is a trend to build to these small devices, as a default, and considerations in design, and implementation seem to be heading in this direction. That’s fine for the 6 to 24 track engineer (some may be a little more using a powerful laptop for example), but as designs change, it’s also a trend that limitations are imposed to cater for these devices, and by the nature of those limitations, the larger setup users are being slowly excluded. I urge anyone building apps or sound APIs not to forget many users are still using desktop computers or server farms to render their material, and this doesn’t look like changing soon. A Haiku professional sound API should be just as valid, and easy to use for a multi box user, as it may be for a laptop or netbook user, imho.
7.) Finally, no limitations. If you think a user will never use more than 100 audio ports, or 50 midi ports, you’re wrong, and profoundly so. My regular template, and this is also true for my colleagues doing the same work, is at least 400 audio tracks, and 128 midi ports. I have a friend in the UK who writes for bigger work than I, using 600-900 midi tracks, over 250 midi ports, and a farm of boxes running samplers to feed his main daw. If you think there’s “enough”, then double it, then triple it, then use no limitations at all. 
A few thoughts if you chaps are considering a professional API from a user who does this for a living.
Good luck.
Alex.
