USB DAC unplugged hangs up rest of USB devices

stratacast1

stratacast1

I've been trying to track down an issue I'm having with FreeBSD not detecting USB inputs via my KVM switch. It works perfectly, until I switch away for a certain amount of time or unplugging the KVM device altogether.

If I switch away my input devices to my other system and my FreeBSD desktop goes to screensaver, when I switch back it no longer detects my input. The behavior is exactly the same when unplugging the device altogether. It will detect that my devices disconnect

Code: 
Aug 26 18:16:06 vmDefense kernel: ugen0.2: <vendor 0x1a40 USB 2.0 Hub> at usbus0 (disconnected)
Aug 26 18:16:06 vmDefense kernel: uhub3: at uhub0, port 3, addr 1 (disconnected)
Aug 26 18:16:06 vmDefense kernel: ugen0.3: <FiiO DigiHug USB Audio> at usbus0 (disconnected)
Aug 26 18:16:06 vmDefense kernel: uhid0: at uhub3, port 1, addr 2 (disconnected)
Aug 26 18:16:06 vmDefense kernel: uhid0: detached
Aug 26 18:16:06 vmDefense kernel: uaudio0: at uhub3, port 1, addr 2 (disconnected)

This seems to happen when I unplug all my USB devices at once, and the culprit being my USB DAC. When I unplug it, I always get this in my messages log:

Code: 
Aug 26 18:40:21 vmDefense kernel: uaudio0: at uhub3, port 1, addr 7 (disconnected)
Aug 26 18:40:21 vmDefense kernel: pcm2: unregister: channel pcm2:virtual:dsp2.vp1 busy (pid 12929)
Aug 26 18:40:21 vmDefense kernel: pcm2: Waiting for sound application to exit!
Aug 26 18:40:23 vmDefense kernel: pcm2: unregister: channel pcm2:virtual:dsp2.vp1 busy (pid 12929)
Aug 26 18:40:23 vmDefense kernel: pcm2: Waiting for sound application to exit!
Aug 26 18:40:25 vmDefense kernel: pcm2: unregister: channel pcm2:virtual:dsp2.vp1 busy (pid 12929)
Aug 26 18:40:25 vmDefense kernel: pcm2: Waiting for sound application to exit!
Aug 26 18:40:27 vmDefense kernel: pcm2: unregister: channel pcm2:virtual:dsp2.vp1 busy (pid 12929)
Aug 26 18:40:27 vmDefense kernel: pcm2: Waiting for sound application to exit!
Aug 26 18:40:29 vmDefense kernel: pcm2: unregister: channel pcm2:virtual:dsp2.vp1 busy (pid 12929)
Aug 26 18:40:29 vmDefense kernel: pcm2: Waiting for sound application to exit!
Aug 26 18:40:31 vmDefense kernel: pcm2: unregister: channel pcm2:virtual:dsp2.vp1 busy (pid 12929)
Aug 26 18:40:31 vmDefense kernel: pcm2: Waiting for sound application to exit!
Aug 26 18:40:33 vmDefense kernel: pcm2: unregister: channel pcm2:virtual:dsp2.vp1 busy (pid 12929)
Aug 26 18:40:33 vmDefense kernel: pcm2: Waiting for sound application to exit!

If my other devices were unplugged at the same time, I can't do anything and I have to reboot. But if I do my switching and my USB DAC isn't a part of the equation, we're fine. So it seems when my device goes away, those processes need to die somehow...thoughts?
 
That's a good start! I'm not entirely sure what action to write though. The existing solutions have you kill the process that's holding it. So if I unplug my USB DAC then the solution on unplug is to kill my music player entirely, but that's kind of silly
 
Can't get the rule right though
Code: 
detach 100 {
        device-name "ugen0.3";
        action "fstat /dev/dsp* /dev/mixer* /dev/audio* | tail -n +2 | awk '{print $3}' | xargs sh -c 'sudo kill -9 $0 $*'";
};

File is at `/etc/devd/usbdac.conf`

I've tried pcm2, uhid0, uaudio0 (and yes I've restarted the devd daemon
 
Any chance you are using pulseaudio?

You have to kill all programs (e.g. your browser!) that had an active audio stream when the DAC was removed or pulseaudio will hang and block the USB subsystem until you re-attach the DAC, kill said programs and re-start pulseaudio. At least thats the procedure I have to go through on my systems running Lumina DE (which uses pulseaudio by default and needs it to properly run firefox with sound...) when I remove the headphone DAC while something is actively using it through pulseaudio. Audio players (e.g. deadbeef) seem to keep an active stream open, so they have to be closed entirely or pulseaudio will hang when removing the USB DAC...

If you can, by any means try to avoid pulseaudio entirely - the bare FreeBSD sound backend and/or OSS are perfectly able to switch between audio sinks (even dynamically e.g. if you re-attach the DAC). The only reason I still "have" to use pulseaudio are lumina (hard dependency...) and firefox-esr...
 
This is a known issue in the uaudio() driver or the usb drivers. There have been several PR open for over a year about that topic. I think it‘s still not clear where the problem. If you post in one of the existing PRs with good description you can help to solve the riddle one day.
Sorry I‘m on my phone, searching for PR is no fun.
 
sko said:
Any chance you are using pulseaudio?

You have to kill all programs (e.g. your browser!) that had an active audio stream when the DAC was removed or pulseaudio will hang and block the USB subsystem until you re-attach the DAC, kill said programs and re-start pulseaudio. At least thats the procedure I have to go through on my systems running Lumina DE (which uses pulseaudio by default and needs it to properly run firefox with sound...) when I remove the headphone DAC while something is actively using it through pulseaudio. Audio players (e.g. deadbeef) seem to keep an active stream open, so they have to be closed entirely or pulseaudio will hang when removing the USB DAC...

If you can, by any means try to avoid pulseaudio entirely - the bare FreeBSD sound backend and/or OSS are perfectly able to switch between audio sinks (even dynamically e.g. if you re-attach the DAC). The only reason I still "have" to use pulseaudio are lumina (hard dependency...) and firefox-esr...
Click to expand...

Sadly that means I'll have to remove my DE (MATE) since pulseadio is a dependency. I'm eventually trying to switch to DWM though and I bet that isn't a dependency. I'd need to drop firefox for chromium which would be too hard since I rely on Firefox's container tabs very heavily...

k.jacker said:
This is a known issue in the uaudio() driver or the usb drivers. There have been several PR open for over a year about that topic. I think it‘s still not clear where the problem. If you post in one of the existing PRs with good description you can help to solve the riddle one day.
Sorry I‘m on my phone, searching for PR is no fun.
Click to expand...

I'll see if I can find that PR, since you said it's uadio related, that might help me find something.

So it seems the solution then is to just run the command that nukes all programs using my audio device before I switch over...probably not too big of a compromise
 
I've noticed people are generally blaming the application in these bug reports (namely this one PR 194727. Maybe it is, since perhaps FreeBSD handles these audio contexts differently than other OSes. I wonder what the other OSes do since FreeBSD relies on the program to properly handle the signals. Something tells me it's unlikely the application developers are thinking about which OS requires what signal for it to release the device
 
You must log in or register to reply here.
Back
Top