Hi, This is more of a query than it is a bug report, simply because I'm not entirely sure of the correct approach here. The GoXLR (and GoXLR Mini) both have a 'magic' request that's performed before audio output is activated, similar to the MBox2 quirk, currently we have a userland tool that uses libusb to forcibly detach the device from ALSA, perform the magic, then perform a USB reset the device to return it back. Once 'initialised' the userland tool then sends and receives the necessary URBs to configure the device to make it actually usable. The problem I'm running into is that sending the uninitialised device (it's impossible to open the audio channels) through to higher level audio servers (pulseaudio and pipewire) is causing them to reject it, and don't seem to be picking it back up even after the USB reset has occurred. Generally (for example) restarting pipewire will solve the issue. So here's my quandary, I can provide a simple kernel patch to correctly initialise the device and activate the audio channels prior to it being used which would solve all the problems, however, the device itself wont be usable until the userland code kicks in to actually configure it. From a 'kernel' perspective I suspect this wouldn't be ideal. Alternatively I could provide a patch that initialises and configures a basic profile (this would move into the potentially hundreds of lines of code region, and it wouldn't be possible to configure default mic inputs due to the nature of the device and messaging), and in most cases these defaults will be immediately replaced by the userland code. The final option is to message the downstream services to get them to better handle a 'faulty' device that is unceremoniously ripped away and returned working, Which is something I'd struggle to be able to directly contribute to, so may not actually get fixed. So I'm asking for some kind of feedback on what the best approach would be here, I'm happy to contribute and maintain a basic quirk to activate audio, and let userland do the configuration, but would rather hear your opinions. All the best, Craig McLure