On Mon, Jul 01, 2024 at 04:17:11PM +0200, Takashi Iwai wrote: > As Geoffrey already suggested, the matrix size can be reduced since > each kcontrol element can be an array, so the number of controls can > be either column or row size of the matrix, which is well manageable. Additionally, a snd_kcontrol structure can provide multiple control elements by its 'count' member. I call it 'control element set'. It can reduce allocation in kernel space. If the hardware in this case provides software interface to access to all source coefficients to one destination at once, it is suitable in the case. For example, assuming the matrix mixer has 34 destination and 66 sources, they can be expressed by 34 control elements with 66 array elements. A single snd_kcontrol structure can provide them, as long as they have the same nature. The control elements are identified by index value. Once I talked with Philippe Bekaert about the issue, then we found another issue about the way to distinguish both each control elements and the array members. The usage of ALSA control interface heavily relies on the name of control elements, while a single snd_kcontrol structure provides one name and all of the controls provided by it have the same name. We've investigated to use TLV (Type-Length-Array) function of ALSA control core to provide channel information about the sources and destinations, but no further work yet[1]. I think it better to have another care that in this case we have restriction for the size of array; e.g. 128 array elements for integer (long) type of value. The restriction is not the matter in your case. > The VU meter can be provided as volatile read-only controls, too. > > So from the API-wise POV, it'll be a most straightforward > implementation. As a side note, the design of software interface for recent hardware requires floating point values for this kind of data, while it is not supported in ALSA control core and its userspace interface. > OTOH, if you need more efficiency (e.g. the control access is way too > much overhead), it can be implemented freely via a hwdep device and > your own ioctls or mmaps, too. But this is literally h/w dependent, > and the API becomes too specific, no other way than using own tool, as > a drawback. [1] https://github.com/PhilippeBekaert/snd-hdspe/issues/13 Regards Takashi Sakamoto
