[pulseaudio-discuss] ASoC and pulseaudio

[Lu, Han]

Hi,

> -----Original Message-----
> From: pulseaudio-discuss [mailto:pulseaudio-discuss-
> bounces at lists.freedesktop.org] On Behalf Of Liam Girdwood
> Sent: Tuesday, February 23, 2016 7:13 PM
> To: General PulseAudio Discussion <pulseaudio-
> discuss at lists.freedesktop.org>
> Cc: Linux Upstreaming Team <linux at endlessm.com>; han.lu
> <han.lu at linux.intel.com>
> Subject: Re: [pulseaudio-discuss] ASoC and pulseaudio
> 
> 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
> 

We can fix this from driver level and user space level:
(1) to reporting more information from driver. 
ALSA sound cards have 3 names. longname, shortname and drivername. e.g.
from soc-core.c :-

	snprintf(card->snd_card->shortname, sizeof(card->snd_card->shortname),
		 "%s", card->name);
	snprintf(card->snd_card->longname, sizeof(card->snd_card->longname),
		 "%s", card->long_name ? card->long_name : card->name);
	snprintf(card->snd_card->driver, sizeof(card->snd_card->driver),
		 "%s", card->driver_name ? card->driver_name : card->name);

We can additionally set the long_name and driver_name in ASoC if they were not set. 

The naming scheme could be :-

a) shortname is current machine driver name i.e. "byt-rt5640"
b) longname is DMI boardname + 1 i.e. "Minnowboard Max: byt-rt5640"
c) driver name is platform driver name  i.e. "baytrail-pcm-audio"

(2) to enable UCM to support "include" parsing, so each codec will have its own UCM file to define all the use cases for the codec only, and the codec UCM file can be included and the codec use cases can be referenced by different machine driver UCM files.

I'll try to work out RFC patches to implement the features above.

BR,
Han

> 
> 
> > _______________________________________________
> > pulseaudio-discuss mailing list
> > pulseaudio-discuss at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> 
> 
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss