From: "Takashi Sakamoto" <o-takashi@sakamocchi.jp>
To: "Asahi Lina" <lina@asahilina.net>,
alsa-devel@alsa-project.org, linux-sound@vger.kernel.org
Cc: "Takashi Iwai" <tiwai@suse.com>, "Jaroslav Kysela" <perex@perex.cz>
Subject: Re: Handling complex matrix mixers in ALSA
Date: Mon, 01 Jul 2024 09:06:43 +0900 [thread overview]
Message-ID: <e0ed11c2-a4bf-40ec-95ad-fa61d95987c7@app.fastmail.com> (raw)
In-Reply-To: <48beda37-1795-4d48-987d-1e2582cb3a18@asahilina.net>
Hi,
I'm a maintainer of both ALSA firewire stack and Linux firewire subsystem. As
long as I know, there is neither consensus nor specific userspace API/structure
to the issue , therefore each developer selects each way within current
implementation of ALSA control core and userspace interface.
On Mon, Jul 1, 2024, at 01:04, Asahi Lina wrote:
> 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.
>
> 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.
>
> 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.
In my opinion, expose of such many control elements would not be necessarily
convenient to users, especially to who eager to use GUI for such matrix mixer.
Additionally, initialization for all of configurable elements in device would sometimes
require conditional operation somehow (e.g. dependency on sampling rate or
any mode of digital interfaces).
If you have no need to share one of the USB endpoints for any configurable
elemenets between kernel/userspace, it is a simple way to implement such
confuguration application as userspace application, as you did with Python 3 and
libusb.
Anyway, if you eager to change ALSA control core and its interface to userspace
for the purpose, we go for more discussion about it. We share the same interest.
P.S. for devices supported by drivers in ALSA firewire stack, I write some service
programs in userspace to utilize ALSA control "user-defined control element set".
You can find the implementation of protocol to configure RME Fireface
400/800/UCX/808 in it, as well as any DICE-based models:
* https://github.com/alsa-project/snd-firewire-ctl-services/
Regards
Takashi Sakamoto
next prev parent reply other threads:[~2024-07-01 0:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-30 16:04 Handling complex matrix mixers in ALSA Asahi Lina
2024-07-01 0:06 ` Takashi Sakamoto [this message]
2024-07-01 2:45 ` Geoffrey D. Bennett
2024-07-01 14:17 ` Takashi Iwai
2024-07-02 0:46 ` Takashi Sakamoto
2024-07-12 9:48 ` Asahi Lina
2024-07-13 1:35 ` Takashi Sakamoto
2024-07-04 8:55 ` Mark Hills
2024-07-04 16:06 ` Arun Raghavan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e0ed11c2-a4bf-40ec-95ad-fa61d95987c7@app.fastmail.com \
--to=o-takashi@sakamocchi.jp \
--cc=alsa-devel@alsa-project.org \
--cc=lina@asahilina.net \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox