+ alsa, Takashi and Mark since it's a naming convention being discussed as part of this work.
On Mon, 2016-03-14 at 08:17 +0000, Lu, Han wrote: > Hi, > > > -----Original Message----- > > From: pulseaudio-discuss [mailto:pulseaudio-discuss- > > [email protected]] On Behalf Of Liam Girdwood > > Sent: Tuesday, February 23, 2016 7:13 PM > > To: General PulseAudio Discussion <pulseaudio- > > [email protected]> > > Cc: Linux Upstreaming Team <[email protected]>; han.lu > > <[email protected]> > > 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 > > > [email protected] > > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > > > > _______________________________________________ > > pulseaudio-discuss mailing list > > [email protected] > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > _______________________________________________ > pulseaudio-discuss mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss _______________________________________________ pulseaudio-discuss mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
