Re: [alsa-devel] UCM extensions

[Jaroslav Kysela <perex@perex.cz>]

Dne 06. 11. 19 v 14:51 Jaska Uimonen napsal(a):
> On Wed, 2019-11-06 at 14:10 +0100, Jaroslav Kysela wrote:
>> Dne 06. 11. 19 v 12:50 Kai Vehmanen napsal(a):
>>> Hi Jaroslav,
>>>
>>> On Tue, 5 Nov 2019, Jaroslav Kysela wrote:
>>>
>>>> 	I make some internal ucm code cleanups in alsa-lib and added
>>>> three
>>>> major extensions to allow more complex configurations which we
>>>> require for the
>>>> SOF kernel driver.
>>>
>>> looks very good and pragmatic way to tackle some of the issues you
>>> hit
>>> with current UCM.
>>>
>>> E.g. the If block would be also sufficient to tackle the recent
>>> HDMI codec
>>> driver change (with a single UCM file) -- i.e. use existence of the
>>> hdac-hdmi driver controls to select which enable-sequences to run.
>>> Hmm, I
>>> like this better than trying to select a whole different UCM file
>>> based on
>>> which drivers are used.
>>>
>>> And same usage pattern can be applied to other mixer control name
>>> changes
>>> (like you already did for the HDA mic control).
>>>
>>> That of course leads to the question do we soon need mechanisms to
>>> choose between more than two conditions (e.g. if mixer controls
>>> have
>>> changed multiple times in recent kernels, so covering for this
>>> in UCM would need a Switch, If-Else, or similar). But yeah, one can
>>> always define another UCM, so keeping-it-simple might be the right
>>> choice here.
>>
>> I already implemented the nested If (so you may use another If in
>> the
>> True/False blocks).
>>
>> Also 'String' (equal, substring) and 'RegexMatch' conditions were
>> added.
>>
>> For the substitution, I added ${CardComponents}, too. The driver
>> might pass
>> another component description strings to the user space for a better
>> identification - there is snd_component_add() kernel function for
>> this.
>>
>>>> 	I added everything to keep the interface backward compatible,
>>>> so the
>>>> current applications should not observe any different behavior.
>>>> The
>>>> applications like pulseaudio should use the 'hw:CARD_INDEX'
>>>> specifier for the
>>>> open call in the future and snd_use_case_parse_ctl_elem_id()
>>>> helper for the
>>>> element control names.
>>>
>>> This sounds good as well. Some testing with common versions of
>>> e.g. Pulseaudio is probably in order to sanity check how this
>>> works.
>>
>> Yep, I will do more testing.
>>
>> Do you have any progress with the pulseaudio volume UCM extension?
>> Could you
>> send me a link to the repository again? Thank you.
>>
> If you mean the ucm hw volume support:
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/189
> This is my fixes on top of Arun's original patch.
> 
> This is working pretty well for me, for example I have mute leds
> working in X1 with this. Unfortunately Pulseaudio community is pretty
> loaded with reviews, so no comments yet.
> 
> My problem is also that some distributions are using pulseaudio v11.1
> so backporting is little bit nasty... My personal branch if for some
> reason someone want's to test in v11.1:
> https://gitlab.freedesktop.org/juimonen/pulseaudio/tree/lenovo_test
> (This branch has also couple of backports to support automatic routing
> between profiles -> ucm use cases)

Thanks, I see the misunderstanding between PlaybackVolume/PlaybackSwitch and 
PlaybackMixerID . The PlaybackVolume/PlaybackSwitch is for control API 
(snd_ctl_...) while PlaybackVolumeId is for selem API. The same is for the 
capture direction. It seems that PA uses the selem API, thus 
PlaybackVolumeId/CaptureVolumeId should be used (and defined in the ucm 
configuration files).

Also, the zero index for sid worries me, too:

	SELEM_INIT(sid, e->alsa_name);

My machine:

$ amixer -D hw:PCH | grep Headphone
Simple mixer control 'Headphone',0
Simple mixer control 'Headphone',1

We should also define and handle the dependency for mixer controls (Master -> 
Headphone) later in UCM and PA should handle this, too.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel