[pulseaudio-discuss] [ANNOUNCE] [PACKAGERS] New mixer logic in PA

[Lennart Poettering]

Heya,

just a quick heads-up on the new ALSA mixer handling logic in PA which
I merged a few days ago, for packagers and other interested folks:

Previously PA was picking one ALSA (simple) mixer element to control
and then was sticking to it for all hardware volume/mute
handling. Usually that was the 'Master' element for output and
'Capture' for input. This had many drawbacks, among them:

a) we needed to rely on alsactl to fully initialize the ALSA mixer by
   default correctly, so that we can get away with controlling only
   one of them.

b) we were limited to the features of the mixer element we chose,
   i.e. it's granularity and range

c) often enough we picked the wrong control, for example on headphone
   setups where the controls we picked didn't actually do what we
   expected it would be doing.

d) ALSA tends to split up multichannel controls into seperate fake
   stereo pairs, which PA couldn't make use of.

e) no support for input port/output port selection, i.e. line-in
   vs. mic or speaker out vs. headphones and so on

f) on laptops like thinkpads no way to handle the builtin external hw
   volume control combined with the maste volume.

The new logic tries to more comprehensively control ALSA mixers. We
don't want to want to expose all features of an ALSA mixer, but we do
want to control more elements than we previously did. So what the new
stuff odes is this:

It is possible to define a "mixer path" which basically is a list of
mixer elements PA should control, with a bit of information how to
control them. Only one mixer path can be active at a time. Elements in
the path may be used for the following functions:

switches:
- can be declared to be used as "mute" switch
- can always be set to off, or to on
- can be exposed as a configurable option in the UI
- can be ignored

volumes:
- can be declared to be integrated in one big volume slider
- can always bet set to minimal or 0dB olume
- can be ignored

enumerations:
- can be exposed as a configurable option in the UI
- can be ignored

How does such a path definition look like?

This directory knows all currently defined paths:

http://git.0pointer.de/?p=pulseaudio.git;a=tree;f=src/modules/alsa/mixer/paths

An interesting example is for example the definition for a "Mic" path:

http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/modules/alsa/mixer/paths/analog-input-mic.conf

What you see there is basically that the Mic and Capture volume
sliders are merged and all other capture sources are switched off.

What does "merging" volume sliders mean? If a volume slider in ALSA
has dB information then PA can multiply the two volume factors
and get a result factor of it. When we need to set a volume we start
from the beginning in the path and try to set the first slider to the
target dB value or the next closest value higher than it. Then we
divide our target volume by what we just set and apply that to the
next element in the mixer path and so on. WHich basically means that
the "largest part" of the volume adjustment happens on the most
outermost mixer control and the remaining controls are configured to
something next to 0dB. If the first mixer control does not have dB
information we will expose it and only it, since going through the
path won't help.

Enuemrations and switches that are marked for "exposing in the UI"
will be made available as "ports" on a sink/source. If multiply mixer
paths are found valid for a device they too will be exposed as
"ports". If multiple paths and multiple exposed options exist then
this will create a list of all possible combinations. This can get
quite large if too many are exposed. So don't do it. For all cards I
have here I never head more than 8 ports in the end, most only 2 or
0. And that's how it should be.

Ports are currently not exposed in pavucontrol/g-v-c but this will
hopefully change soon.

So what does all of this give us?

- we control a full set of volume sliders/mute switches not just one
- we can control the surround channel volume sliders properly
- we can select output/input port properly
- since the configuration happens in files this is easy to extend
- we have larger granularity and range of the hw volume sliders.
- issues a-f pointed out above are all fixed

On top of all of these path definitions, I also made the profile
definition configurable. The predefined ones are found here:

http://git.0pointer.de/?p=pulseaudio.git;a=tree;f=src/modules/alsa/mixer/profile-sets

These files basically list the ways how an ALSA device may be opened,
i.e. which device string to use ("front:xxx" vs "surround51:xxx"
vs. "spdif:xxx"), which channel mappings and mixer paths apply then
and so on.

There is one default profile set which should work for almost all
consumer devices. At least on the 10 consumer devices I tested this
with it worked fine and exposed exactly the feature set I wanted to
have exposed.

However, for some devices it makes sense to define your own profile
sets. The folks from Caiaq borrowed me a Native Instruments Audio 8 DJ
to define one for this device which can also be used as an example for
further definitions. Which profile set to use is defined via udev
rules. I'd be interested to merge support for more exotic devices like
this one into the PA, I am happy to take patches. Generally if you
don't have such a per-device profile set your device will be treated
as normal consumer device. So even if you lack this your devices will
at least basically work.

So much about all this new complexity. Feel free to browse through
the git repo dirs linked abvoe and read through the files, they
contain a few comments to lighten up things a bit beyond what I wrote
in this mail.

I expect that the default profile we now have in git might need tweaks
and fixes for some card. The point of this mail is to make you and the
distributors aware that this whole stuff is now available and can be
even be updated without recompiling PA.

I only have access to 10 cards here or so, I am relying on you folks
to make sure the current default profile works for as many cards as
possible.

Questions?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4