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