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

[Bastian, Waldo]

Is this targetted at 0.9.16?

Cheers,
Waldo
-- 
Intel Corporation - Hillsboro, Oregon
Ultra Mobility Group - Platform Software Architecture
Tel: +1 503 264 6237 - Mobile: +1 503 703-7327

> -----Original Message-----
> From: pulseaudio-discuss-bounces at mail.0pointer.de [mailto:pulseaudio-
> discuss-bounces at mail.0pointer.de] On Behalf Of Lennart Poettering
> Sent: Friday, June 19, 2009 10:08 AM
> To: PulseAudio Discussion List
> Subject: [pulseaudio-discuss] [ANNOUNCE] [PACKAGERS] New mixer logic in PA
> 
> 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/p
> aths
> 
> 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/p
> aths/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/p
> rofile-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