Hello!
On 08/06/2015 04:22 AM, Joel Roth wrote:
> [...]
> What dmix doesn't do (and pulseaudio does) is provide a
> separate volume control for each application.
... a feature that I use once per year; then it is quite useful. ;-)
I find ALSA provides really lots of useful tools, such as:
* the plug-in "dmix", already mentioned;
* the plug-in "jack", can divert audio from/to a JACK server;
* the "loop-back device", constructs a virtual ALSA sound card;
* the plug-in "route", can up- and down-mix multichannel audio
and re-order channels;
* the plug-in "ladspa", can pass audio through algorithms
such as filters, delays or distortions.
There are more, but they all have in common these problems:
a there are no simplistic configuration tools, actually there
are no configuration tools at all, the user interface is the
structured text-based configuration file ~/.asoundrc
b the configuration file user documentation is badly structured,
casually written and limited to few, punctual examples.
These problems have existed for ages now; as for problem #2,
many unofficial efforts have been made to improve this, there are
many tutorials and examples online. Still, I find it undeniable
that the official documentation is far from optimal.
As for problem #1, I personally feel that the lack of user
interface (tools and documentation) of the ALSA built-in
solutions has been and is the primary motivator for developments
like Pulseaudio.
Other problems I feel worth mentioning:
c In my experience, setups based on .asoundrc tend to be static,
they get written, tinkered with and optimized until they reliably
work, then the configuration file is left alone because "it just
works".
d Since the setup in asoundrc is static in nature, dynamically
assigning a multichannel routing, for example through an
interactive volume control, to a specific application is
something I would not immediately know how to accomplish.
e Some applications can not use pcm entries defined by plug-ins,
they want ALSA playback/capture interfaces (I think ALSA calls
these "devices"). I encountered that problem when trying to
route iceweasel output to JACK: with a pcm based on the "jack"
plug-in it refused to accept that as default playback pcm;
with a loop device defined as the default (suggested by [1])
it works reliably.
f OTOH, working with "loop" devices ("virtual sound cards")
for redirection, the number and ordering of these devices
is decided at loading time of the snd-aloop kernel module;
I am not aware that this could be reconfigured dynamically.
Kind regards,
T.
Links:
[1] alsa.opensrc.org. "Jack and Loopback device as Alsa-to-Jack
bridge". URL:
http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge