search

GoXLR-on-Linux / goxlr-utility

An unofficial GoXLR App replacement for Linux, Windows and MacOS
MIT License
635 stars 36 forks source link

Have to restart pipewire after login to get goxlr to work #123

Open wutscher opened 10 months ago

wutscher commented 10 months ago

Every time i log in i have to restart pipewire with systemctl --user restart pipewire to get the devices to function properly. It would be nice to have an automated or built in solution for this.

OS: Arch linux (kernel 6.4.12-arch1-1) Utility Version: 0.12.6 GoXLR Type: Mini audio: pipewire with wireplumber

FrostyCoolSlug commented 10 months ago

This one is unfortunately a tricky problem to solve, as it's likely more of a pipewire issue than a utility issue.

The GoXLR when it's 'freshly' powered on requires a proprietory USB command to be sent to it to activate the interface and it's channels.

So what happens is the following: 1) The ALSA usb-audio driver picks up the GoXLR and loads it 2) The utility starts, it detatches the usb-audio driver (taking it away from ALSA) and takes control of the device 3) The utility sends the initialisation packets to get the GoXLR started 4) The utility will then issue a USB Reset command for the device. 5) The kernel will detatch and reattach the device, the ALSA usb-audio driver picks up the GoXLR and loads it.

From there everything functions normally.

My best guess is that pipewire is tripping up between 1 and 2, it starts loading the card profile and the card is yanked away before it's fully setup, to the point where even after the reset at 4/5 it's not able to pick the card up again.

The best I can really do to attempt to mitigate this would be to add a brief pause before initialisation, and hope that pipewire can get everything ready to handle the impending reset. There's also the possible option of adding the initialisation into the usb-audio driver as a device quirk, which would remove the need for the utility to do any of that, but that's a somewhat more difficult proposition.

FrostyCoolSlug commented 10 months ago

So I've spent some time testing this, and it seems the actual issue is occurring between 3 and 4..

During the teardown after the initialisation packets are handled, I release the interface and reset the device, from what I can tell, during the nanoseconds between the two commands ALSA / pipewire try a re-grab on the device, and the reset is breaking it.

From testing, I learned that I can keep hold of the interface until the reset is completed, then when I release it gets handed back to ALSA clean, and pipewire seems to pick it up correctly.

Could you grab the relevant artifact from the bottom of this test build, install it, and test it for me please? Let me know if the behaviour is better.

Thanks!

wutscher commented 10 months ago

I've just tried out the patched version, but the behavior stayed the same. I tested it 4 times to make sure but the behavior is consistent. Steps i took:

StephanDaaboul commented 9 months ago

Hello, I am also having the same issue in Debian 12 and I have to manually restart pipewire and open the web app for the devices to get initialized and usable by any audio application. Are there any logs or information I could share to help find the issue?

FrostyCoolSlug commented 9 months ago

Might be worth looking at the pipewire logs (I'm not entirely sure how to get them), and see if there's a reason it's not reattaching the device, I don't think there's anything more on the util side I can do.

wutscher commented 9 months ago

I just checked my pipewire logs using journalctl --user -b -u pipewire and found these entries in the time between boot and me restarting pipewire. They don't mean much to me, but maybe you can see something here

Oct 01 16:48:03 archinator systemd[1174]: Started PipeWire Multimedia Service.
Oct 01 16:48:05 archinator pipewire[1509]: [0:04:42.321662928] [1509] ERROR IPAModule ipa_module.cpp:172 Symbol ipaModuleInfo not found
Oct 01 16:48:05 archinator pipewire[1509]: [0:04:42.321674217] [1509] ERROR IPAModule ipa_module.cpp:292 v4l2-compat.so: IPA module has no valid info
Oct 01 16:48:05 archinator pipewire[1509]: [0:04:42.321700985] [1509]  INFO Camera camera_manager.cpp:284 libcamera v0.1.0
Oct 01 16:48:05 archinator pipewire[1509]: spa.alsa: '_ucm0001.goxlr_stereo_out:GoXLRMini,0,2,3': playback open failed: No such device
Oct 01 16:48:05 archinator pipewire[1509]: ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for GoXLRMini
Oct 01 16:48:05 archinator pipewire[1509]: mod.adapter: 0x55954277c490: can't get format: No such device
Oct 01 16:48:05 archinator pipewire[1509]: mod.adapter: usage: node.name=<string>
Oct 01 16:48:05 archinator pipewire[1509]: ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for GoXLRMini
Oct 01 16:48:05 archinator pipewire[1509]: spa.alsa: '_ucm0001.goxlr_stereo_out:GoXLRMini,0,0,1': playback open failed: No such device
Oct 01 16:48:05 archinator pipewire[1509]: mod.adapter: 0x559542793210: can't get format: No such device
Oct 01 16:48:05 archinator pipewire[1509]: mod.adapter: usage: node.name=<string>
Oct 01 16:48:05 archinator pipewire[1509]: ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for GoXLRMini
Oct 01 16:48:05 archinator pipewire[1509]: spa.alsa: '_ucm0001.goxlr_stereo_in:GoXLRMini,0,4,5': capture open failed: No such device
Oct 01 16:48:05 archinator pipewire[1509]: mod.adapter: 0x559542793210: can't get format: No such device
Oct 01 16:48:05 archinator pipewire[1509]: mod.adapter: usage: node.name=<string>
Oct 01 16:48:05 archinator pipewire[1509]: ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for GoXLRMini
Oct 01 16:48:05 archinator pipewire[1509]: spa.alsa: '_ucm0001.goxlr_stereo_in:GoXLRMini,0,2,3': capture open failed: No such device
Oct 01 16:48:05 archinator pipewire[1509]: mod.adapter: 0x559542793210: can't get format: No such device
Oct 01 16:48:05 archinator pipewire[1509]: mod.adapter: usage: node.name=<string>
Oct 01 16:48:05 archinator pipewire[1509]: ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for GoXLRMini
Oct 01 16:48:05 archinator pipewire[1509]: spa.alsa: '_ucm0001.goxlr_stereo_in:GoXLRMini,0,0,1': capture open failed: No such device
Oct 01 16:48:05 archinator pipewire[1509]: mod.adapter: 0x559542793210: can't get format: No such device
Oct 01 16:48:05 archinator pipewire[1509]: mod.adapter: usage: node.name=<string>
FrostyCoolSlug commented 9 months ago

Thanks, yeah this seems to indicate what I expected, pipewire isn't handling the disappearance and reappearance of the device properly, by the time it gets to loading the UCM profile, the device is already gone, and it' not retrying when the device reappears.

I'm honestly not entirely sure the best way to solve this, outside of submitting a kernel patch to make the detach unnecessary.

I'll do some testing and see what I can come up with.

Thanks.

FrostyCoolSlug commented 8 months ago

I've opened an issue with the ALSA devs Here as to the best way to approach this. I ask that you please don't comment specifically on that issue unless you have some additional information until some feedback has been provided.

The probability is that we're going to need to create a bug report with the Pipewire devs to deal with this scenario correctly, there's no real reason why it shouldn't automatically 'fix' itself when the USB reset happens, and the logs imply it's not correctly dropping then reestablishing the device correctly, but this is a tricky thing to fix.

FrostyCoolSlug commented 8 months ago

As a separate thing, could I ask that you open an issue on the pipewire bug tracker for this? As hard as I try, I'm unable to reproduce the issue on my install (Pipewire 0.3.83, Kernel 6.5.5-1-MANJARO), the device always comes back without fail for me even when power cycled.

FrostyCoolSlug commented 7 months ago

One thing which might work as a solution, given that the majority of these problems occur due to the mini being powered on during system boot, I could introduce a systemd service which runs the goxlr-initialiser binary as root prior to the desktop environment being launched. This should get the GoXLR into a 'working' state in advance of pipewire and the utility starting up...

Thinking about this more, it might be possible to handle it directly on device hotplug via udev and systemd, so it doesn't reach the ALSA level until the initialisation stage has been handled..

Is anyone here on this thread happy to help with some testing?

wutscher commented 7 months ago

I'd be happy to help. Just need some instructions on what to do.