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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
