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