[alsa-devel] Software mixer at kernel level

[Sean McNamara]

On Mon, Feb 9, 2009 at 10:57 PM, stan <ghjeold_i_mwee at cox.net> wrote:
> Sean McNamara wrote:
>>
>> Hi,
>>
>
>>
>> However, the point about "everybody needs it" is a valid one. If I had
>> my druthers, it would be impossible for anyone in usermode to
>> initialize an ALSA pcm in a mode which does not provide software
>> mixing. We can still provide the software mixing in usermode, but my
>> reasoning is that
>>
>
> <rant>
> I disagree.  I have one of those applications that doesn't do softwae
> mixing, deliberately because I want it to have good sound (it's a brainwave
> entrainment app).  It calls functions in alsa that *can't* be accessed
> through pulse, and allows users to set the frame rate to any hardware rate
> their card supports (in pulse, one size fits all).
>
> Pulse is great for those who want its functionality, and I would love to see
> it replace dmix in alsa so that when it received a request for a function it
> doesn't support it would have the ability to step aside and allow the
> application to take over the sound device.
>
> Linux is about freedom, and I think you are wanting to restrict that freedom
> for me to use my hardware the way I want. If you want to put a switch in
> place that does that, but allows it to be turned off, great, but not hard
> wired to only behave a single way.  Wait!  We already have such a switch,
> it's called /home/.asoundrc.

Sorry, but I think you misinterpreted my suggestion.

Let me sort of imagineer the kind of functionality I was discussing in
a bit more detail, and then you can re-evaluate whether I'm trying to
restrict things in a way that you need to rant about, ok?

First, let's review how it is today.

Let's say I'm using dmix, and it's in my /etc/asound.conf as the
"default" PCM. I am happily going along, starting applications that
obey the tacit convention of opening the device named "default", which
by convention is supposed to contain whatever PCM pluggage that the
user wants.

Now let's say I open some application that, for some reason, wants to
access hw:0. As soon as I try to do this while dmix-using apps aren't
playing sound, hw:0 is now taken, and the dmix apps can no longer play
sound.

This, to me, is a very bad idea for the use case of the desktop. This
should be worked from two sides. Most importantly, we need to make
sure that desktop apps (i.e., the vast majority of apps) should be
able to use dmix or maybe even PulseAudio through the ALSA plug layer.
But an adjunct possibility would be to have a setting somewhere in
ALSA which _prevents_ applications from directly accessing hw:0 in a
way that does not use software mixing. We can then define a set of
plugins (jack, pulse, dmix, dsnoop... any others?) which safely enable
software mixing, and maybe we can have policy exceptions for
individual binaries, to support daemons.

With the changes I was referring to when I wrote my original post, the
new functionality would be thus:

1. [Prerequisite] Start PulseAudio or JACK if desired; if not, set up
dmix as the pcm.!default.
2. Set an option somewhere in the ALSA configs that says "Apps [which
are not in the exception list] may no longer hog the soundcard."
3. Apps that want to play nice with the desktop will access
dmix/pulseaudio/JACK using the "safe" ALSA subset and will open the
"default" device, and not hw:0.
4. An app that wants to open a direct PCM (ignoring the "default"
device) tries to access hw:0 while the other apps are temporarily
quiet. alsa-lib immediately returns an error, whether or not the
device is in use.
5. The apps designed to use software mixing continue on their way uninterrupted.

We could also have a distro-supplied hook which displays a GUI when an
app tries to directly access hw:0. It will be disallowed regardless of
whether the device is busy or not, if the configuration bit is set.

This behavior has the benefit of increasing the reliability of apps
which _do_ use software mixing, because it ensures they will never be
blocked by an app that directly accesses "hw:x". For desktop software
that _should_ be compatible with software mixing but is not, it has
the side-effect of bringing them into the limelight as ones that the
community should try to fix, if possible, to live with the safe subset
and open "default" instead of "hw:x". But as you can see, it in no way
entails that you will no longer be able to open a direct hw PCM.

I guess I can see how you /could/ interpret my original post as
implying some sort of draconian prevention of direct PCM access (with
no way around it), but please, let's be charitable: this is the FOSS
world, and wherever there is need for a bit-flip on points of
disagreement, there usually is one.

The change I've recommended here is merely air code, but its intention
is to suggest one way of making the desktop sound experience more
reliable, _not_ to close off paths for very special use cases like
brainwave entrainment. I'm sure you already realize the consequences
of hogging the "hw:x" devices, so it goes without saying that your app
can't work well in a desktop environment using sounds from many
programs at once. But that's a design decision you have planned for
and accepted, and as such, your program is not designed to be desktop
software on the order of Firefox, Rhythmbox, Pidgin, Evolution,
Phonon, and so on. Since your requirements are so very different, we
can not ignore either the desktop use case or your own special use
case. But that doesn't mean our hands are tied in terms of trying to
make the desktop experience better.

How many times have users wondered why their
Pidgin/Skype/Rhythmbox/Flash stuff won't play sound after they fire up
Audacity, or Second Life? This _is_ a problem with the applications
and not ALSA, but unless we try to encourage use of software mixing,
the issues don't seem to be getting addressed.

Anyway, back on topic to the OP, this matter of "firmer" software
mixing is the only valid point I could salvage from their idea, so
hopefully you'll take me with a grain of salt for talking through his
issue to its logical conclusion :)

Thanks,

Sean

>
> You are welcome to do whatever you want on your system, but don't assume
> that everyone wants what you want.
> </rant>
>