[linux-audio-dev] Re: What Parts of Linux Audio Simply Work Great?

[Takashi Iwai]

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