On Sat, 2016-02-20 at 12:22 -0600, Pierre-Louis Bossart wrote:
> 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.
Fwiw, I've not had any problems using PA and UCM together on my BDW +
RT286 based development platforms. The problem we have atm is matching
and quirks as Pierre describes.
> >
> > 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.
>
Fwiw, we have been looking at providing some fixes for naming and
quirks. We should probably schedule the work now.
For naming we have the problem of duplication in the driver name e.g.
cat /proc/asound/cards
0 [bytrt5640 ]: byt-rt5640 - byt-rt5640
byt-rt5640
The driver name actually has three strings iirc and we could
differentiate here (by adding DMI name, plus any others?? ) to help UCM
and PA deal with any quirks.
UCM also does not currently support #include. The intention is to
provide a method to define mixer settings on a codec per codec basis and
the these could be #included into a machine UCM file. The machine UCM
file would also define settings for any quirks and would #include any
codec UCM files that were needed. PA would load the machine UCM file
(based on improvements to the driver naming above) intead of the generic
UCM file that is loaded atm.
Liam
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
