Hi Lina, On Mon, Jul 01, 2024 at 01:04:41AM +0900, Asahi Lina wrote: > Hi, > > I'm reverse engineering and implementing support for the RME Digiface > USB, which is an ADAT interface with a non-class-compliant interface > (probably similar to other RME interfaces like the MADIface, but I don't > have any others to test). The basic audio streaming works fine with an > entry in quirks-table.h and a format quirk to set the system sample rate > in quirks.c. Now I need to figure out how to implement the mixer controls. > > Currently I have the snd-usb-audio driver claiming only interface #0 > (streaming) and I use a Python script to control the mixer/settings > directly with libusb (control transfers and interface #1). This works > fine and there's some prior art for this in the firewire world (for > example, snd-dice doesn't do any mixer control stuff and you have to use > ffado-mixer to control everything from userspace) but I assume it's not > really the best way to go? I'm the developer of the Scarlett2 driver. Doing as much as possible through ALSA mixer controls has worked well in my experience; as you say, being able to do save/restore with alsactl is useful. > The problem is that the device has a 66x34 matrix mixer, with up to 2048 > cross points enabled at once. Exposing each cross point as an ALSA mixer > control (similar to how mixer_scarlett2.c does it) would mean 2244 > controls just for the mixer... which seems like a bit too much. Note that mixer controls may have more than one value. So I think you could have 66 controls with 34 values or 34 controls with 66 values or 1 control with 2244 values. > On top of that there is also VU meter feedback for all the > inputs/outputs, as well as general fader controls for each output and > global output configs and status. I'm not sure about the VU meters, but > everything else sounds like it would map fine to normal mixer controls. I handle the VU meter feedback in the Scarlett2 driver with a read-only volatile control that contains multiple values (see scarlett2_meter_ctl). Regards, Geoffrey. > Is there some recommended way to expose this kind of matrix mixer > interface to userspace? I think for something like this you pretty much > have to rely on device-specific tools to make the UX manageable, so > maybe hwdep... but at least exposing everything as an ALSA control would > have the advantage of supporting save/restore with something like > alsactl. So I don't really know what's the way to go here. > > System settings/general status/output faders go via control transfers, > while interface #1 has an interrupt IN endpoint (streaming state > feedback, not very useful) and two bulk endpoints (matrix mixer control > out, VU meter data in). There's another pair of bulk endpoints in > interface #2 which I'm guessing are for firmware updates (I haven't > looked at that part). So in principle it's not crazy to expose all the > system controls/output faders as mixer controls in ALSA and leave > interface #1 entirely unclaimed so a userspace program can directly > configure the matrix mixer and access VU meter levels. There is a global > mixer enable bit (controlled via ctl transfer), so if that is exposed as > an ALSA control and disabled by default the interface will operate as a > 1:1 in/out interface without needing any custom userspace to configure > the mixer. > > There's one other quirky thing: it also needs a way to set the sample > rate as a mixer control, because you need to be able to configure the > rate even when the PCM device is not open (since that affects > stand-alone mixer operation). I imagine the right logic here would be to > have a selector control for the system sample rate, and automatically > change it and lock it when the PCM is opened with a given rate? > > Any thoughts welcome ^^ > > ~~ Lina
