I started hacking on this today, and I see two options for fixing the kernel side:ġ. I've tried this with deadbeef and firefox, which I think at least firefox uses pulseaudio. Logs surrounding killind the processes holding onto the deviceĪpr 20 17:47:26 pooter kernel: pcm7: Waiting for sound application to exit!Īpr 20 17:47:28 pooter kernel: pcm7: detachedĪpr 20 17:47:28 pooter kernel: uaudio0: detachedĪpr 20 17:47:29 pooter kernel: ugen2.2: at usbus2Īpr 20 17:47:29 pooter kernel: uhid1 on uhub2Īpr 20 17:47:29 pooter kernel: uhid1: on usbus2Īpr 20 17:47:29 pooter kernel: uaudio0 on uhub2Īpr 20 17:47:29 pooter kernel: uaudio0: on usbus2 However, the new issue that comes along with this is the PID will still result in errors waiting for the sound application to exit, and even if you go in and manually kill the processes the sound for that device actually will not work anymore until next reboot.Īpr 20 17:46:07 pooter kernel: ugen2.2: at usbus2 (disconnected)Īpr 20 17:46:07 pooter kernel: uhid1: at uhub2, port 3, addr 1 (disconnected)Īpr 20 17:46:07 pooter kernel: uhid1: detachedĪpr 20 17:46:07 pooter kernel: uaudio0: at uhub2, port 3, addr 1 (disconnected)Īpr 20 17:46:07 pooter kernel: pcm7: unregister: channel pcm7:virtual:dsp7.vp0 busy (pid 57285)Īpr 20 17:46:07 pooter kernel: pcm7: Waiting for sound application to exit!Īpr 20 17:46:07 pooter pulseaudio: module-oss.c: SNDCTL_DSP_GETOPTR: Bad file descriptorĪpr 20 17:46:07 pooter syslogd: last message repeated 2 timesĪpr 20 17:46:09 pooter kernel: pcm7: unregister: mixer busyĪpr 20 17:46:09 pooter kernel: pcm7: Waiting for sound application to exit!Īpr 20 17:46:11 pooter kernel: pcm7: unregister: mixer busyĪpr 20 17:46:11 pooter kernel: pcm7: Waiting for sound application to exit! Previously the whole USB bus would hang and require a hard reset, but not any longer. I'm definitely seeing some progress in this. I'll move the audio-devices around and post back, maybe that'll give a hint what's the cause. This one works fine with suspend/resume on FreeBSD 12.0-RELEASE. I have another computer with a different audio device using if_uaudio.ko, a Asus Impressario BluRayDrive with Xonar audio.
I wonder if this is specific to a Intel processor/chipset generation, as almost every new generation of Intel processors/chipsets comes with a new set of bugs. I already posted that on the forums in november 2018: This is on USB 2.0 native on Intel Broadwell CPU. dev/ttyv0 is flooded with "Waiting for mixer." and "Waiting for sound application to exit" Only solution is to ssh into the machine and kill cmus (no -9 needed) and usb keyboard and mouse, etc will come back to life and suspend/resume will finish. I tried to disconnecting the audio device when USB stalls, but that doesn't help
#Obs studio disconnecting drivers#
In FreeBSD 12.0-RELEASE, the stalled usb drivers will stall before suspending has finished. When I was on FreeBSD 11.2, the system would suspend, but USB hung up when resumed. Audio device is a 9 year old HRT MusicStreamer II+. I've had the same issue since FreeBSD 11.2-RELEASE with if_uaudio.ko and audio/cmus. Toktay kdeinit5 1049 2610 /dev 97 crw-rw-rw- mixer2 rw /dev/mixer2 Toktay kdeinit5 1049 2608 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1 Toktay kdeinit5 1049 2564 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1 Toktay kmix 1113 15 /dev 97 crw-rw-rw- mixer2 rw /dev/mixer2 Toktay kmix 1113 14 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1
Toktay kmix 1113 13 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1 Toktay pulseaudio 1117 40 /dev 97 crw-rw-rw- mixer2 rw /dev/mixer2 Toktay pulseaudio 1117 30 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1 Toktay pulseaudio 1117 20 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME Pcm2: Waiting for sound application to exit! Since I am trying to configure this machine as my primary desktop machine this is a show stopper for me. I installed iFreeBSD fujitsu 11.2-RELEASE with kde5 to my fujitsu 920 minipc.
0 kommentar(er)
