[pulseaudio-discuss] [alsa-devel] Per board ucm files on x86?

[Takashi Iwai]

On Mon, 11 Dec 2017 15:21:23 +0100,
Pierre-Louis Bossart wrote:
> 
> 
> 
> On 12/11/2017 07:40 AM, Takashi Iwai wrote:
> > On Mon, 11 Dec 2017 13:30:35 +0100,
> > Hans de Goede wrote:
> >> Hi All,
> >>
> >> This weekend I've created a modified ucm config based on:
> >>
> >> https://github.com/plbossart/UCM/tree/master/chtrt5645
> >>
> >> For a board which has a single speaker connected to the
> >> left channel (standard mono speaker setup) and a stereo
> >> headphone jack with working jack detection.
> >>
> >> I've been unable to come up with a ucm file which allows
> >> selecting between a "Stereo Speaker + Headphone" vs
> >> "Mono Speaker + Headphone" output profile.
> >>
> >> https://github.com/plbossart/UCM/tree/master/byt-rt5640
> >> has "Mono Speaker", "Stereo Speaker" and "Headphone"
> >> profiles but does not auto-switch between Headphone
> >> and speaker based on jack detection, I've been unable to
> >> allow selecting either stereo or mono speaker while
> >> keeping auto-switching to/from the headphones.
> >>
> >> But thinking more about this I don't think that having
> >> "Stereo Speaker + Headphone" and "Mono Speaker + Headphone"
> >> profiles is the answer. Profiles make sense on machines with
> >> a bunch of outputs where we don't no what the user is going
> >> to plug in, but in this case the stereo vs mono speaker
> >> distinction is a clear property of the device, which we
> >> should IMHO autodetect based on the device-model.
> >>
> >> So I think we need a way to have different ucm files per board,
> >> so instead of loading /usr/share/ucm/chtrt5645/*.conf on my
> >> device, alsa should try to load /usr/share/ucm/chtrt5645-<boardname>/*.conf
> >>
> >> Specifically I'm thinking about using udev + hwdb (dmi string)
> >> matching to set an ALSA_UCM_NAME udev property.
> >>
> >> If the consensus is that this is a good idea I can take a shot
> >> at writing patches for this (in my spare time mostly), the
> >> downside of this approach is it would cause a dependency on
> >> libudev for the alsa ucm code.
> > You don't need to patch, I guess.  The recent code should set a string
> > generated from DMI as the longname of the card, and alsa-lib UCM
> > parser prefers the longname to the driver name field.  That is,
> > /usr/share/ucm/$LONGNAME/$LONGNAME.conf would be read at first, then
> > /usr/share/ucm/$DRIVER/$DRIVER.conf is used as fallback.
> >
> The long name is really awful at times, I've seen PulseAudio try to
> load UCM profiles of boards with over 40 characters with multiple
> repeats.

Yes, it's often ugly.  We can have some mapping in a table in UCM side
to shorten the name string, too.

> Also from a maintainability perspective we need the include mechanism
> and I don't think it was ever merged - or what I saw wasn't very
> useful.

I guess the inclusion should work in alsa-lib conf syntax as is.
It can be included in a form <$PATH>


Takashi