21 Jun
2005
21 Jun
'05
2:58 p.m.
At Mon, 20 Jun 2005 23:50:38 -0400,
Lee Revell wrote:
Agreed. Let's keep discussion there, then.
On Mon, 2005-06-20 at 18:47 +0200, Takashi Iwai wrote:
Yes, but it's usually also exclusive. If any processes occupy the
device, 5.1 output can't be played. This may be a problem, e.g. if
you start a video player from a web browser.
But, switching 2.0 and 5.1 on the fly during the output is impossible
in many cases, too. Thus, we have to choose either 2.0 or 5.1 as the
system configuration, and let dmix running ether 2.0 or 5.1 mode.
Of course, there might be other problems with this. (Who on the earth
wants to hear beep with 5.1 speakers? ;)
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.)
I think because the apps that want to use these (99% xine and mplayer)
already seem to do the right thing. 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.
This is a great idea, we should discuss it further on alsa-devel. In fact JACK works perfectly fine with or without
dmix, it just
complains loudly if you try to use it with the plug layer. We should
preserve this behavior: JACK will first try to get exclusive access,
then if only dmix is available, it should display a warning and
continue.
I think this is relatively OK. It's just a warning and obviously the
plug layer prevents the optimal performance with JACK. And if JACK is
started automatically, user would notice it rarely, too...
Takashi