Dne 08. 04. 21 v 15:18 Takashi Iwai napsal(a):
> On Thu, 08 Apr 2021 14:05:02 +0200,
> Mark Brown wrote:
>>
>> On Thu, Apr 08, 2021 at 01:21:52PM +0200, Jaroslav Kysela wrote:
>>
>>> Yes, it's for UCM, but even if we don't consider this purpose, the kernel API
>>> should return some reasonable information rather than very generic (or empty)
>>> strings which are used in the native ALSA utilities for example. So, I think
>>> that we should allow to "fix" this info also from the user space rather than
>>> to extend the existing API.
>>
>> Half the point with UCM was supposed to be to rewrite the control names
>> we get from the devices into standard things that are useful for
>> userspace, having to remap things for UCM doesn't sound right.
>
> I guess the question here is how to identify the proper profile for a
> certain platform and how to get it passed over the whole system.
> Theoretically, the rename of the card name or mixer name strings could
> be done in user-space side, too (e.g. mapping in alsa-lib or
> whatever), so I don't think it mandatory to make them variable via
> sysfs, if it's meant only for the consistency reason.
There are two things to consider (please, don't concentrate to UCM here):
1) the card identification
2) the user experience
Actually, the generic ASoC drivers are too much generic and they didn't
provide a solid information about the hardware.
Two examples:
rpi with PCM5100A DAC (not hifiberry):
# cat /proc/asound/cards
0 [sndrpihifiberry]: RPi-simple - snd_rpi_hifiberry_dac
snd_rpi_hifiberry_dac
SOF SoundWire driver:
# cat /proc/asound/cards
0 [sofsoundwire ]: sof-soundwire - sof-soundwire
Intel Soundwire SOF
# amixer -c 0 info
Card hw:0 'sofsoundwire'/'Intel Soundwire SOF'
Mixer name : 'Intel Kabylake HDMI'
Components : 'HDA:8086280b,80860101,00100000 cfg-spk:4 cfg-amp:2 hs:rt711
spk:rt1308 mic:rt715'
As you can see, the information for both drivers is quite inaccurate and users
(including me) may want some flexibility to change those strings to something
else. It may resolve some UCM problems, but it's just one small piece of the
issue.
Another issue is when the udev driver loader can change some parameters which
modifies the driver behaviour and sound device structure for the given card
(as discussed in another thread).
When we have a common standard layer for the plug-and-play handling (udev), we
should concentrate to allow changing / refining of this information there.
Those strings are not used for anything else than the user space. So from my
view, there's no reason to create another mechanism to handle the overrides.
It should be a safe, fast, flexible and _optional_ solution. The udev can
alter the sysfs attributes directly without any hassle with the file
modifications or looking for another way to pass / store this information
somewhere.
I evaluated the other possibilities like store the overwrites to a file, udev
environment (per device) and they are not so easy or create extra dependencies
(alsa-lib -> libudev).
> Didn't we discuss in the past about the possibility to store the
> profile name in the card component string?
It's already possible to extract any information from the components string.
The current UCM is very flexible, but it does not allow to use a missing
information.
The main questions is: Can we make those strings writable or not? What
prevents us to not allow that?
Jaroslav
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
