[alsa-devel] ioctl(fd, SNDRV_CTL_IOCTL_ELEM_REPLACE, ... not working from userspace ?

[Fulup Ar Foll]

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-set.c
> 
> 
> Regards
> 
> Takashi Sakamoto
>