18 Jun
2005
18 Jun
'05
10:59 p.m.
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/