Created attachment 299575 [details] alsa-info Hello, I’m the owner of a GoXLR : https://www.tc-helicon.com/product.html?modelCode=P0CQK . It is a usb sound mixer that is not supported officially with Linux. The main issue is that the GoXLR is a multi inputs / multi outputs device, but it is not seen as one. It works great under Windows thanks to a driver. With Linux, it is seen as a single usb sound device with a single multichannel output. Right now, I managed with other people to separate those channels with pulseaudio or jack or even pipewire. For exemple, Front Left and Front Right are the stereo output named "System". Rear left and rear right are another stereo output named "Game". There are other outputs, and it is the same mechanism for the inputs. But I’ve seen that a few usb devices do have quirks for them to behave as expected, without the need of configuration with pulse or pipewire. But from what I understand, it’s only to disable subdevices or reorder outputs. Am I wrong ? Is it possible to add a quirk for a device like the GoXLR and change the multichannel output into multiple subdevices with alsa ? Thanks a lot if you can help me and the others owners.
Well, that's how the devices is implemented in the hardware level; it has only one stream that maps multi-channels. So in the hardware level, there are no multi-streams, but Windows and others also do split/merge multi-streams in software. That said, basically it'll be rather a question how to implement in the user-space side.
(In reply to Takashi Iwai from comment #1) > Well, that's how the devices is implemented in the hardware level; it has > only one stream that maps multi-channels. So in the hardware level, there > are no multi-streams, but Windows and others also do split/merge > multi-streams in software. > > That said, basically it'll be rather a question how to implement in the > user-space side. Hi, Thanks a lot for you answer. Does this mean it is now doable right now with a quirk in the kernel or too complicated ? Would it require a specific module to make this work ? Do you know another device which works the same way that I could compare with ? It is possible to implement it in the user-space side. I did it with pipewire (via a loopback device), other people did with jack, and I used pulseaudio before. If it’s not possible on to handle the device in the kernel, would it be possible with alsa (userspace) ? Having the streams separated is in fact the first step (and the most needed one). It would be great if we could control the device (the GoXLR doesn’t use an hid device for the buttons). So even if we manage the in/outputs in userspace, we would still miss another part. Sorry if my questions seem dumb. But I’m really starting from nothing here.
The split of streams won't be done in the kernel side. As the hardware provides only one stream, it cannot be split. It's possible to split the stream in alsa-lib plugin, too (e.g. dshare plugin). But PA or PW won't use it in anyway, and they'll need the own setup.
We may create an UCM profile with dshare PCM devices for this card. Please, create an issue in https://github.com/alsa-project/alsa-ucm-conf/issues with the URL to the alsa-info output.
(In reply to Jaroslav Kysela from comment #4) I did create an issue on pipewire and someone told me it wasn’t possible with a ucm profile : https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1787 . Are you telling me it is ?
UCM is evolving and I think that we can describe this hardware in the UCM configuration now. There may be some issues with the dshare / dsnoop plugins but we can try.
The issue is opened : https://github.com/alsa-project/alsa-ucm-conf/issues/121 Thanks again for your support.
IMO, dsnoop/dshare don't fit well with PA or PW. PA/PW have own buffer management, and the split could be handled more directly there? And, certainly we can provide some better information about the channels. Currently the chmap provides only the fixed channel positions and nothing about the physical connection or such are provided.
(In reply to Takashi Iwai from comment #8) > IMO, dsnoop/dshare don't fit well with PA or PW. PA/PW have own buffer > management, and the split could be handled more directly there? It depends. We may optimize dsnoop/dshare for the cases, when they are open from one task (PID). The rest of code (samples copy) is quite similar. From the UCM perspective, we should allow to describe this use case. If we hide this in a PCM device name - the UCM applications are not forced to implement this on it's own. > And, certainly we can provide some better information about the channels. > Currently the chmap provides only the fixed channel positions and nothing > about the physical connection or such are provided. Yes. I agree. But: 1) hw may not pass this information 2) users should be allowed to override this (custom configs)