[pulseaudio-discuss] ASoC and pulseaudio

[Pierre-Louis Bossart]

r
On 02/17/2016 09:27 AM, 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).
> 
> 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"?

Not an easy problem. I generated a set of UCM files for baytrail-based platforms and I was planning on doing the same for CHT now that there are a set of commercially available devices. 
There are however a set of limitations that are known already, e.g. the UCM file matches the machine driver name, so if there are any quirks inside the driver we'd need to add a DMI-based info to the card name and also build UCM files based on an include mechanism, otherwise it's going to be copy/paste hell
Adding Liam to make sure he sees this thread.