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
