Takashi,
Thank you very much for this long and detail explanation.
I already tested user-defined control to enable missing hardware or expose functionalities (ex: volume ramp-up/down, or volume control on a Unicens network where ALSA driver does not expose any mixer interface).
It looks like renaming existing hardware controls to normalize a sound card API is a no go option. I may add missing capabilities but if I understand you correctly renaming exiting controls to make hardware fully transparent to the application is not an option.
In order to implement a HAL (hardware Abstraction Layer) would you recommend a plugin that would proxy every controls/PCM or does ALSA propose some other unknown API that could help ?
Cars may have pretty complex audio configuration and in the ideal world we would like to use a unique ALSA UCM config and make application completely ignorant of the actual configuration.
Fulup
On 04/07/17 02:00, Takashi Sakamoto wrote:
Hi,
On Jul 4 2017 01:50, Fulup Ar Foll wrote:
At kernel level the iotcl point onto ./sound/core/control.c and calls snd_ctl_elem_add_user(ctl, argp, 1) that itself calls snd_ctl_elem_add
Looking at this code I do not understand why the replace iotcl is refused. Nevertheless it seems more to come from some lacking data in ly ctrlinfo than because of access right (I'm testing as root)
ALSA control core in kernel land is designed to maintain two types of control element set; one is added by drivers in kernel land, another is added by userspace applications. The macro, 'SNDRV_CTL_ELEM_ACCESS_USER' is for distinction of the latter type from the former type. Both type of control element set can be handled by userspace applications in the same way (read/write/poll/ioctl with SNDRV_PCM_IOCTL_XXX), however they have different effects.
Typically, users utilize the former type of control element set to configure hardware features with helps of kernel drivers. On the other hand, the latter type of control element set has no direct relations to hardware. There's a need for userspace applications to handle any events relevant to the latter type of control element set when achieving some actual effects. At present, there's a few cases to use the latter type; e.g. softvol PCM plugin in alsa-lib utilizes the latter control element set to add alternative control element set for PCM frame resampling[1].
The issued operation, SNDRV_CTL_IOCTL_ELEM_REPLACE, is designed just for the latter type of control element set. Therefore, you got no success from this operation for the former type of control element set. When attempting to get success, you need to add the latter type of control element set in advance, then issue the operation for the added control element set. You can see a test program in alsa-lib[2] for the latter type of control element set, for your information.
But I know that implementations for the latter type of control element set has been long-abandoned. For recent years I had been fixing them but some bugs might be still left, perhaps. If you still receive some errors from this operation for the latter type of control element set, please report how to reproduce it (some programs are preferable). I'm willing to investigate and fix the bug.
[1] src/pcm/pcm_softvol.c http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_softvol.c [2] test/user-ctl-element-set.c http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=test/user-ctl-element-s...
Regards
Takashi Sakamoto