I think that the core question is do Windows and OS X users have to know anything about "sound servers" to get multiple applications to talk to the soundcard? The answer is obviously no.
The second question is do Windows and OS X users have to know a bit more about audio in order to use it for pro-audio purposes? In this case the answer is yes and no--sometimes they do, sometimes they don't. So far, core audio has gone the farthest to make the two uses virtually indistinguishable. If this is the case and if we are to learn something from this, then I believe it is time for Linux to provide similar out-of-box experience when it comes to audio i/o. On the other hand, I tend to always disable sound servers when using Jack, not only because using Jack via plug introduces latency, but also because I do not want to hear "you got mail!" message in the middle of my performance. Ultimately, what I believe should be done is (and this may be something that is already possible via some undocumented feature in .asoundrc): 1) to have alsa at install-time (and by default) generate asym-like plug for the 1st soundcard (including .!default.pcm or whatever its name is) on the machine which would talk to just about any sound server there is (including OSS emulation). With time the asym will get enough exposure (incorporating it into Alsa's default install scripts would inadvertently speed-up this process) that the developers will realize pointlessness of designing/maintaining various sound servers. 2) to have an option for any plug in Alsa (including asym) to have a flag or an option that would: a) enable such device, in the case it cannot talk to the soundcard, to continue accepting i/o connections by talking to the /dev/null or whatever (a dummy device perhaps?). This way the sound servers (and later, once the servers get hopefully phased out, simply sound events played from various apps) would not complain about the inability to connect to the soundcard. b) make specifically jack's direct connections to the hardware take precedence by bypassing such plug devices with appropriately enabled aforementioned flag. This way pro-audio people, when they would try to start-up the jackd, it would appear to be seamless. Now, there is still a concern of what if some audio app tries to connect directly to the audio hardware (Alsa's hw:0, just like jackd would), but those could be weeded-out in time (and most of them usually offer an option of selecting which device should connect to, anyways). Only with such a solution would the audio experience on Linux desktop be on par with Windows and/or OS X, if not better. I am cc-ing Takashi, just to see how feasible this would be. Takashi, I would greatly appreciate your thoughts on this matter. Many thanks! Best wishes, Ivica Ico Bukvic, composer & multimedia sculptor http://meowing.ccm.uc.edu/~ico/
