Hi,
On Thu, Aug 06, 2020 at 07:12:14PM -0500, Pierre-Louis Bossart wrote:
On Thu, Aug 06, 2020 at 10:30:36AM -0500, Pierre-Louis Bossart wrote:
What I was trying to describe in my earlier answer is a different need to have an atomic update of *multiple* controls.
If e.g. a DSP or hardware engine exposes two separate filters for left and right channels, and the coefficients for those filters are modified with separate controls, it would be really nice to have the capability of writing these controls separately, but have a 'commit' mechanism so that these updated coefficients are used at the same time by the left and right filters.
For the pair of left and right filters, the simplest solution is to unify the two control elements into single one, as you know. The array of two values can be passed to your driver by single system call and ALSA control core surely calls driver code under lock acquisition against any operation for control element.
(After posting the above message, I realized that the above method is not good in the case since the coefficients data is array type of data. The aggregation seems not to be well...)
I am not worried about other applications, the issue is that a transaction on a bus or IPC is assumed to have an immediate effect. In the case of multiple values, it'd really be desirable to defer the effect of write transactions until they are all complete. I am not making this up, this sort of capabilities is described in standards and I am not aware of any support from the ALSA control framework for a global commit operation. We have mechanisms to synchronize triggers on PCM devices with the snd_pcm_link(), synchronization of control changes is a miss IMHO.
I attempt to arrange several points in your messages:
1. passing vendor-dependent data blob or metadata via ALSA control interface without any data abstraction 2. control ioctl request to handle multiple 'struct snd_ctl_elem_value' to corresponding control elements at once. 3. introduce traditional 'asynchronous I/O' operation to element write operation in system call level.
I'm in conservative place in a point of changes in kernel land. At present, my answers for the above is:
1. It's impossible for standard ALSA control applications such as amixer(1) to handle the vendor-dependent data blob or metadata. Therefore the functionality is not necessarily to be implemented with ALSA control interface. The functionality is itself unfriendly to the existent userspace applications. 2. Any kernel patch is welcome. But I'm happy if you have enough care of my proposal of limitation removal for the number of members in value array[1]. 3. It seems to be problematic for both of ALSA control core and userspace applications since any attempt for asynchronous I/O in system call level is not necessarily successful in history of Linux kernel development (or standardization by Austin). I don't know the future.
Summary, I recommend you to use ALSA hwdep interface for the functionality in your device, instead of ALSA control interface. You can see some drivers have implementation for userspace applications to execute request and wait for response; e.g. snd-fireworks.
But I note that the summary comes from my conservative place and there is space for further discussion.
[1] https://github.com/takaswie/presentations/blob/master/20181021/contents.md#l...
Thanks
Takashi Sakamoto