How OS X solves this problem may be instructive. [most facts below are probably right, I'm sure I got a few wrong ...] In the System Preferences->Sound menu, a user can choose the default audio input and audio output device. In the CoreAudio API, this choice becomes the current value of kAudioHardwarePropertyDefaultInputDevice and kAudioHardwarePropertyDefaultOutputDevice. Consumer-oriented apps use those Defaults, as a rule; content-creation apps usually have their own Preferences that let you select the audio devices for the app. CoreMIDI works this way too. So, the underlying system is "pro", but there are provisions in the API to handle the mindset of both pro and consumer worlds. Finally, note that Apple solved the legacy problem by emulating Sound Manager (OS 9 audio API). Until Tiger, QuickTime actually used Sound Manager. Many other apps still do. If Linux followed this model, one would write emulators over jack for all of the consumer audio APIs being used in jack, to accommodate the installed base, and have the emulations work well enough to convince distros to just ship jack as the bottom layer, and use its emulated APIs. Then, you can start evangelizing direct jack calls to all application developers, consumer and pro alike. Yes, this takes a lot of work, and is not in the direct path of solving pro audio problems. Just like I've spent 5 years on pushing RTP MIDI through the standards process because I felt someone had to do it, I think the Linux audio API problem only gets solved if someone decides to dedicate 5 years of their life to doing it. That's how long a systems project takes to have an impact on the world. Good luck. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---