On Thu, 2016-02-18 at 11:16 +0200, Tanu Kaskinen wrote: > On Thu, 2016-02-18 at 11:24 +0530, Arun Raghavan wrote: > > On Wed, 2016-02-17 at 16:27 +0100, Carlo Caione wrote: > > > Hi, > > > In our daily work we are seeing more and more laptops coming in with > > > SoC audio (ASoC). In the most recent case, we are working with a new > > > consumer laptop based on Intel Cherry Trail. As you probably know to > > > have audio working on these laptops / codecs a fairly lengthy hw > > > specific mixer configuration is needed. > > > The problem we are facing is how to ship a single PA / ALSA package > > > containing a working configuration for several of those laptops and we > > > were wondering what is the most correct / upstream-friendly way to do > > > that. > > > > > > I'm already excluding here some trivial workarounds like: shipping a > > > different PA package for each hw or using an hw-tailored script to > > > load the correct ALSA configuration. > > > > > > The first solution we came up with is just to write a profile-set > > > configuration file loaded by udev for each cards / laptop with the > > > correct mixer configuration already embedded in the path configuration > > > files. This looks a bit like an overkill when you have to change tens > > > of controls most of which just one time (once you have setup the codec > > > selecting the main path is usually just matter of changing a few > > > controls to change the output / input path). > > > > With PA 8.0, you have the ability to ship distro overrides via .d > > directories, etc. And we have the ability to have includes already, so > > maybe this is one way to solve this problem. > > The .d overrides can currently only be used with daemon.conf and > client.conf, though, so that feature isn't particularly useful for hw > configuration for now. > > > > Another possibility is to use UCM and let PA create automatically from > > > that profile and path configuration files. This looks promising but we > > > were a bit worried about the UCM support in PA and how stable/adopted > > > is UCM itself. > > > > > > So, what is the suggested way to accomplish this and in general how PA > > > is trying to address this problem? I expect in the future to see many > > > more ASoC coming into the laptops world, how will the community make > > > it so that you install a distro and then sound "just works"? > > > > If you are able to express what you need with UCM, it should be fine > > for your use case. ChromeOS uses it, and our support is meant to just > > work. > > > > The idea thus far has been to collate UCM configuration that works with > > mainline kernel in a single ALSA repository, so that'd be the right > > place to put such config. > > We lack hardware volume support with UCM, though. I promised last year > to Liam to implement it, maybe I should actually start doing something > about that... Software volume of course works fine too, but if > PulseAudio doesn't do hw volume control, the UCM file has to take that > into account and set the hw volume to a fixed value, which is not good > for interoperability with e.g. ChromeOS. UCM supports "PlaybackVolume" and "CaptureVolume" properties. These only allow modifying volume via a single control, but changing more than that would likely require UCM-side changes. I did implement support for these a while back: https://cgit.freedesktop.org/~arun/pulseaudio/commit/?h=b2g&id=7d3a9f47 7cd2be83fd72bc25adf95bd49d1eb91f I can potentially update that if it looks broadly useful. Cheers, Arun
