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

[pl bossart]

Hi Lennart,
this might be a silly question but how would you handle transitions
between speakers and headset profiles. When the user plugs or unplugs
their headsets, you would need to change profiles or you would still
not use the correct control. Not clear to me how the jack detection is
propagated all the way to this mixer logic? I see mention of udev to
set the PULSE_PROFILE_SET but the comment hints at a per card
behavior, not headset plug-unplug. Thanks for your feedback.
Cheers,
Pierre

On Fri, Jun 19, 2009 at 12:08 PM, Lennart
Poettering<lennart at poettering.net> wrote:
> 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
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>