20 Jun
2005
20 Jun
'05
2:47 p.m.
At Sat, 18 Jun 2005 20:59:11 -0400,
Ivica Ico Bukvic wrote:
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.
I agree with the necessity of a ready-to-use setup for end users.
But, I'm not sure whether asoundrc is the right place for this role.
Obviously, we need a "central station" for all apps. This set-up
should work with all apps without blocking or any unconfortable
behavior.
The set-up is, however, not only the choice of the soundcard, but it
includes eventually the choice and set-up of devices. For example,
the default I/O should support 5.1 output or SPDIF if user wants (I'm
wondering why no one mentions about them.)
So, what is the intuitive interface for configuring such a thing?
The simplest would be a list of available cards and possible
"presets". The system-configurator (it's pretty distro-dependent)
lets users choose one of them for the default.
IMO, this information should be in a common format. Then, for
example, qjackctl can retrieve the info, list the possible
cards/devices and pass certain start up options according to the
selected item. You can configure WINE setup with it. You can choose
a proper device with xmms...
Well, this is a bit different topic from what Ico suggested above.
OK, returning to the original topic.
I don't quite understand what (1) would bring. Once dmix is set per
default and sound servers use it, I don't think there is problems
regarding sound server and exclusiveness any longer -- except for
JACK.
Then (2), it's more about with JACK: I think the scenario above would
work indeed. We don't have a plugin to do such a job yet, but it
should be easy to create. Suppose a new plugin which have a
configuration like below:
pcm.!default {
type sequential
pcms [ "dmix" "jack" ... ]
}
so that it will try to open dmix, jack, etc sequentially until it
succeeds. Then non-JACK apps can work seamlessly, too, without
changing configuration.
Of course, there may be still bugs in ALSA <-> JACK conversion or
whatever. But it can be technically solved.
Takashi