Re: Handling complex matrix mixers in ALSA

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

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