[alsa-devel] [RFC][PATCH 0/2] ALSA: control: limit life time of user-defined element set

[Takashi Sakamoto]

Hi,

On Sep 5 2016 01:37, Takashi Iwai wrote:
> On Sun, 04 Sep 2016 17:38:20 +0200,
> Clemens Ladisch wrote:
>>
>> Takashi Sakamoto wrote:
>>> ALSA control core allows applications to add arbitrary element sets to an
>>> instance of control device, while removal of the element sets is voluntarily
>>> done by some applications. This is not convenient to certain situations.
>>
>> This was originally designed for softvol, where the user-defined element
>> should behave as much as possible as a hardware control.
>>
>>> My large concern is whether there's any applications to open a file descriptor
>>> just to add any element sets.
>>
>> alsactl restore
>
> Yes, and this is actually 99% of use cases for now: restoring the
> persistent softvol element at the boot time.

Aha. I didn't realize alsactl calls library APIs to add control element 
sets. I was just aware of PCM softvol plugin. Thanks for your notification.

> A similar idea to implement a process-bound user-space kctl has popped
> up a few times in the past, but it's never realized, since no one
> could find it really useful / demanded.

For my information, if possible, would you please show pointers to the 
proposals?

> You may say that it can be used for some application-specific volume or
> such, but what would be it exactly?

I have a plan for a daemon program in user land. It allows ALSA 
applications to control DSP configurations of audio and music units on 
IEEE 1394 bus, via ALSA control character device.

Currently, drivers for the units are in ALSA firewire stack[1], while 
they support no control elements, just support packet streaming 
functionality, because we can achieve it in user land. For example, 
there're already some Python 3 scripts in hinawa-utils[2] to configure 
the units from user space via firewire character device, with a help of 
libhinawa[3].

When detecting some audio and music units on IEEE 1394 bus, the daemon 
program adds some element sets and start listening to them. If ALSA 
control applications changes state of elements in the element sets, the 
daemon catches the event and configure these units by hardware-specific 
ways.

Currently, this idea is just for audio and music units on IEEE 1394 bus. 
But I think we can utilize it for USB audio devices with vendor-specific 
features, without adding more vendor-dependent codes to kernel land.

> Once when we have a real use case, I'm not against adding such a
> change.  But of course as long as it doesn't break the current way of
> softvol usage with the persistent user kctl.

Apparently, this patch breaks the combination of 'PCM softvol plugin' 
and 'alsactl restore'. I think it better to add a new flag such as 
'SNDRV_CTL_ELEM_ACCESS_USER_BOND_TO_FD' to perform automatic removal.

[1] 
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/firewire
[2] https://github.com/takaswie/hinawa-utils/
[3] https://github.com/takaswie/libhinawa/


Regards

Takashi Sakamoto