Hi,
I'm a maintainer of ALSA firewire stack, which supports drivers for
audio and music units in IEEE 1394 bus, including some recording
equipments such as RME Fireface series.
On Wed, Aug 18, 2021 at 04:59:50PM +0200, Philippe Bekaert wrote:
> Dear all,
>
> I am working on a new driver for the RME HDSPe cards, which eventually
> could replace the hdspm driver.
>
> These cards have a hardware mixer / matrox router, freely mixing tens
> of hardware inputs and software playbacks into tens of outputs (8192
> mixer controls on the HDSPe MADI).
>
> Right now, mixer state (cached by the driver) can be read efficiently
> in one ad-hoc ioctl call, and individual channels modified through a
> HWDEP ALSA control element with 3 parameters (input/playback index,
> output index, gain value).
>
> I understand there is a desire to get rid of ad hoc ioctls and am
> therefore looking for a more generic way to read and write huge mixer
> state.
>
> Has anyone been facing similar issues? How have you been solving it?
> Is there any “common practice” or “habits” in this community concerning
> this topic? Would it make sense to define a kind of generic huge mixer
> interface? Then, has anyone an idea or preference how it should look
> like?
>
> Looking forward to your feedback.
>
> Best regards and thanks in advance,
>
> Philippe.
I think the total number, 8192, comes from 64 physical inputs, 64 system
inputs and 64 physical outputs ((64 + 64) * 64 = 8192). Were I you, I'd
use control element set to code the control elements.
In design of ALSA control interface, several control elements can be
aggregated into one instance of 'struct snd_kcontrol'. I call it as
'control element set'. Inner the set, each element can be indicated by
numeric index value of 'struct snd_ctl_elem_id' from userspace
applications. As of release candidate of Linux kernel v5.14, the maximum
number of elements per set is limited by 1028 ('MAX_CONTROL_COUNT' macro
in 'sound/core/control.c').
One control element have limitation about the size of array for values
depending on the type of value. In your case, I assume to use
'SNDRV_CTL_ELEM_TYPE_INTEGER'. In the case, one control element can
handle 128 integer values.
When expressing the 8192 mixer coefficients, I would do:
- Adding 1 element set including 64 elements so that each element
corresponds to each physical output.
- Each element handles 128 values so that each value corresponds to
gain of 64 physical inputs and 64 system inputs per each.
Or when splitting physical inputs and system inputs:
- Adding two element sets including 64 elements per each. The elements
in first set are 'from physical inputs to physical outputs' and the
elements in second set are 'from system inputs to physical outputs'.
- Each element handles 64 values so that each value corresponds to
gain of 64 physical inputs or 64 system inputs per each.
In a point of kernel memory consumption, the first way is less than the
second way. In any cases, ALSA control application can access total 8192
values in 128 control elements.
For the usage of ALSA HwDep interface, an advanced topic stands in my
opinion; how to handle packet from 'RME Advanced Remote Control USB
(ARC USB)'. Depending on scenario, the ioctl implementation might not be
worse since it allows userspace application to control hardware directly.
But it's advanced topic, so let me avoid discussion about it unless
you are interested in it.
Regards
Takashi Sakamoto
