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

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Mon Dec 11 14:21:23 UTC 2017

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.
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.

More information about the pulseaudio-discuss mailing list