Hi I'm using a pair of KEF X300A speakers, which get recognized by the uaudio driver. Sporadically get: uaudio0: at uhub4, port 2, addr 3 (disconnected) pcm0: unregister: channel pcm0:virtual:dsp0.vp0 busy (pid 2204) pcm0: Waiting for sound application to exit! pcm0: unregister: channel pcm0:virtual:dsp0.vp0 busy (pid 2204) pcm0: Waiting for sound application to exit! pcm0: unregister: channel pcm0:virtual:dsp0.vp0 busy (pid 2204) pcm0: Waiting for sound application to exit! [... -- closing/killing the concerning the application] pcm0: Waiting for sound application to exit! pcm0: unregister: mixer busy pcm0: Waiting for sound application to exit! pcm0: unregister: mixer busy [repeat at infinitum] The usb-stack seems to be completly hung at this point (usbconfig&friends hang) -- until I close everything else that has /dev/mixer* open. Then the device seems to reattach and gets usable again.
Hi, This is correct behaviour from the kernel. We need to trace down these apps and make them disconnect the mixer device when the USB AUDIO device detaches. Possibly same with pulseaudio. Do you know which mixer APP this is? XFCE? --HPS
Hi 2204 was mplayer. The one I had to kill to get the stack unhung was kdeinit. So I guess it is a problem in kde. mfg Tobias
Is this expected behaviour when entering sleep, however? Apps have stopped but not freed the pcm device. Looks like i'll be running fuser before acpiconf. ;) Would it make more sense to _eventually_ give up and and send EPIPE or similar? \
Hi, Yes, mixer apps must close their handles when they detect the device is gone! --HPS
This is illogical. USB supports hot plug, so kernel must handle it without stucking. I use audio with KVM b/w Linux. Windows and FreeBSD and I can't even kill mixer as entire USB waits indefinitely. My observations with FF playing youtube video 1. Windows - active playback resumes after FF restart 2. Linux - active playback resumes after FF restart 3. FreeBSD needs reset button.
Hi, Applications must close their handles upon detecting failures, like detach. Else device numbers will be used up pretty quickly. This is a known issue. One solution is perhaps to use audio/virtual_oss, which proxy access to /dev/dsp and possibly in the future /dev/mixer aswell, so that these FreeBSD specific artifacts are hidden. --HPS
Interesting solution indeed! However, looks like I'm out of luck as several processes attached to mixer. abishai@darkstar:~ % fstat /dev/dsp* /dev/mixer* USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME abishai kmix 3325 13 /dev 198 crw-rw-rw- mixer1 rw /dev/mixer1 abishai kmix 3325 14 /dev 198 crw-rw-rw- mixer1 rw /dev/mixer1 abishai kdeinit5 3277 2188 /dev 198 crw-rw-rw- mixer1 rw /dev/mixer1 abishai kdeinit5 3277 2189 /dev 198 crw-rw-rw- mixer1 rw /dev/mixer1
kmix is a process in KDE5. Why not just fix it? --HPS
One solution here is that the sound driver waits a bit and then kills the process in question with SIGPIPE.
I'm not sure what will happen if kmix is killed. Will it be restarted somehow? I guess this needs a better fix.
(In reply to Hans Petter Selasky from comment #9) I think that in FreeBSD we have an ability to revoke a file descriptor. Can we use it to disassociate anything that userland has open from the device that we want to let go?
The problem is that the application, in this case a desktop application will stop working, because it will never detect that the mixer device is gone. --HPS
(In reply to Hans Petter Selasky from comment #10) I've made a simple script that kills all processes that hold descriptor, they are just quit, so I need to restart them. I don't think this is kmix only issue, users of other DE probably have another mixer. I can see that Linux has more general purpose solution Maybe, pulseaudio handles this like OSS proxy you've suggested ? Then, proxy solution is the only right, as this is seamless for userland.
Hello, I have the very same issue. I am a newbie on freebsd. I installed iFreeBSD fujitsu 11.2-RELEASE with kde5 to my fujitsu 920 minipc. I have currently no sound. Since I am trying to configure this machine as my primary desktop machine this is a show stopper for me. Is there a way to circumvent this issue.. pcm2: Waiting for sound application to exit! pcm2: unregister: mixer busy pcm2: Waiting for sound application to exit! pcm2: unregister: mixer busy pcm2: Waiting for sound application to exit! pcm2: unregister: mixer busy pcm2: Waiting for sound application to exit! pcm2: unregister: mixer busy pcm2: Waiting for sound application to exit! pcm2: unregister: mixer busy pcm2: Waiting for sound application to exit! pcm2: unregister: mixer busy pcm2: Waiting for sound application to exit! pcm2: unregister: mixer busy pcm2: Waiting for sound application to exit! pcm2: detached pcm2: <USB audio> on uaudio0 pcm0: <Intel Haswell (HDMI/DP 8ch)> at nid 3 on hdaa0 pcm1: <Realtek ALC671 (Rear Analog)> at nid 33 and 24 on hdaa1 pcm2: <USB audio> on uaudio0 root@fujitsu:~ # fstat /dev/dsp* /dev/mixer* USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME toktay pulseaudio 1117 20 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1 toktay pulseaudio 1117 30 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1 toktay pulseaudio 1117 40 /dev 97 crw-rw-rw- mixer2 rw /dev/mixer2 toktay kmix 1113 13 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1 toktay kmix 1113 14 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1 toktay kmix 1113 15 /dev 97 crw-rw-rw- mixer2 rw /dev/mixer2 toktay kdeinit5 1049 2564 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1 toktay kdeinit5 1049 2608 /dev 62 crw-rw-rw- mixer1 rw /dev/mixer1 toktay kdeinit5 1049 2610 /dev 97 crw-rw-rw- mixer2 rw /dev/mixer2
(In reply to Hans Petter Selasky from comment #1) Many applications fail to disconnect from mixer when required. How is it "correct behaviour from the kernel" for the kernel to only behave correctly (keep USB and suspend working) when applications also behave correctly? These audio playback applications are not normally granted permission to obstruct kernel facilities. The virtual_oss behaves very well indeed, but must the kernel remain so fragile that virtual_oss is the only application I should grant permission to access /dev/dsp ? (In reply to Hans Petter Selasky from comment #9) "One solution here is that the sound driver waits a bit and then kills the process in question with SIGPIPE." This is much more acceptable than putting the system into an unrecoverable state when attempting to sleep (compare the established behavior of killing any processes which refuse to quit during full shutdown).
I've had the same issue since FreeBSD 11.2-RELEASE with if_uaudio.ko and audio/cmus. Audio device is a 9 year old HRT MusicStreamer II+. When I was on FreeBSD 11.2, the system would suspend, but USB hung up when resumed. In FreeBSD 12.0-RELEASE, the stalled usb drivers will stall before suspending has finished. I tried to disconnecting the audio device when USB stalls, but that doesn't help 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. /dev/ttyv0 is flooded with "Waiting for mixer..." and "Waiting for sound application to exit" This is on USB 2.0 native on Intel Broadwell CPU. I already posted that on the forums in november 2018: https://forums.freebsd.org/threads/weird-xhci-crash-freeze-after-resume-from-suspend.68277/ 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. Though that's just a guess. I have another computer with a different audio device using if_uaudio.ko, a Asus Impressario BluRayDrive with Xonar audio. This one works fine with suspend/resume on FreeBSD 12.0-RELEASE. I'll move the audio-devices around and post back, maybe that'll give a hint what's the cause. -Matthias
I'm seeing a similar-but-not-really issue on my aarch64 box (MACCHIATObin). After watching YouTube for some minutes, with an old ASUS Xonar uaudio0 (recognized as "C-Media Electronics Inc. USB Advanced Audio Device"), suddenly for a couple seconds the audio starts crackling and muting, and then stops, and in a few seconds USB input (!) stops working. Specifically USB mouse and keyboard. USB Ethernet keeps working fine. I can even start playing music over SSH, headphones are silent but the progress bar keeps going. I can unplug the audio card and it detaches fine. But USB input is dead, even after `usbconfig reset` there are no events on libinput, no input on the vt console either.
(In reply to Greg V from comment #17) update: a different USB soundcard seems fine so far
*** Bug 239730 has been marked as a duplicate of this bug. ***
I am seeing similar messages when trying to sleep my laptop running 12.1 with USB attached speakers. It wasn't a problem on 12.0, although I am not sure if the difference is the upgrade of the OS, or of the packages.
There has been no kernel changes in this area for a long time. Likely some applications which keep the device open. --HPS
A commit references this bug: Author: hselasky Date: Wed Mar 4 17:23:21 UTC 2020 New revision: 358629 URL: https://svnweb.freebsd.org/changeset/base/358629 Log: Implement a detaching flag for the sound(4) subsystem to take appropriate actions when we are trying to detach an audio device, but cannot because someone is using it. This avoids applications having to wait for the DSP read data timeout before they receive any error indication. Tested with virtual_oss(8). Remove some unused definitions while at it. PR: 194727 MFC after: 1 week Sponsored by: Mellanox Technologies Changes: head/sys/dev/sound/pcm/dsp.c head/sys/dev/sound/pcm/mixer.c head/sys/dev/sound/pcm/sound.c head/sys/dev/sound/pcm/sound.h
A commit references this bug: Author: hselasky Date: Wed Mar 11 08:24:51 UTC 2020 New revision: 358877 URL: https://svnweb.freebsd.org/changeset/base/358877 Log: MFC r358629: Implement a detaching flag for the sound(4) subsystem to take appropriate actions when we are trying to detach an audio device, but cannot because someone is using it. This avoids applications having to wait for the DSP read data timeout before they receive any error indication. Tested with virtual_oss(8). Remove some unused definitions while at it. PR: 194727 Sponsored by: Mellanox Technologies Changes: _U stable/12/ stable/12/sys/dev/sound/pcm/dsp.c stable/12/sys/dev/sound/pcm/mixer.c stable/12/sys/dev/sound/pcm/sound.c stable/12/sys/dev/sound/pcm/sound.h
A commit references this bug: Author: hselasky Date: Wed Mar 11 08:25:34 UTC 2020 New revision: 358878 URL: https://svnweb.freebsd.org/changeset/base/358878 Log: MFC r358629: Implement a detaching flag for the sound(4) subsystem to take appropriate actions when we are trying to detach an audio device, but cannot because someone is using it. This avoids applications having to wait for the DSP read data timeout before they receive any error indication. Tested with virtual_oss(8). Remove some unused definitions while at it. PR: 194727 Sponsored by: Mellanox Technologies Changes: _U stable/11/ stable/11/sys/dev/sound/pcm/dsp.c stable/11/sys/dev/sound/pcm/mixer.c stable/11/sys/dev/sound/pcm/sound.c stable/11/sys/dev/sound/pcm/sound.h
A commit references this bug: Author: hselasky Date: Wed Mar 11 08:26:12 UTC 2020 New revision: 358879 URL: https://svnweb.freebsd.org/changeset/base/358879 Log: MFC r358629: Implement a detaching flag for the sound(4) subsystem to take appropriate actions when we are trying to detach an audio device, but cannot because someone is using it. This avoids applications having to wait for the DSP read data timeout before they receive any error indication. Tested with virtual_oss(8). Remove some unused definitions while at it. PR: 194727 Sponsored by: Mellanox Technologies Changes: _U stable/10/ stable/10/sys/dev/sound/pcm/dsp.c stable/10/sys/dev/sound/pcm/mixer.c stable/10/sys/dev/sound/pcm/sound.c stable/10/sys/dev/sound/pcm/sound.h
A commit references this bug: Author: hselasky Date: Wed Mar 11 08:26:53 UTC 2020 New revision: 358880 URL: https://svnweb.freebsd.org/changeset/base/358880 Log: MFC r358629: Implement a detaching flag for the sound(4) subsystem to take appropriate actions when we are trying to detach an audio device, but cannot because someone is using it. This avoids applications having to wait for the DSP read data timeout before they receive any error indication. Tested with virtual_oss(8). Remove some unused definitions while at it. PR: 194727 Sponsored by: Mellanox Technologies Changes: _U stable/9/sys/ stable/9/sys/dev/sound/pcm/dsp.c stable/9/sys/dev/sound/pcm/mixer.c stable/9/sys/dev/sound/pcm/sound.c stable/9/sys/dev/sound/pcm/sound.h
Created attachment 212945 [details] Patch for pulseaudio port This patch solve all problems with DSP device detach and pulseaudio on recent -stable and -current. Please test!
Added gnome @ freebsd . org : Please approve my Pulseaudio patch. Thank you!
(In reply to Hans Petter Selasky from comment #27) Nice. I've been able to detach a USB soundcard, click on the built-in Realtek one in pavucontrol and playback seamlessly continued on the built-in soundcard. Pulse did show these messages when detaching: E: [oss] module-oss.c: Mixer shutdown. E: [oss] module-oss.c: SNDCTL_DSP_GETOPTR: Bad file descriptor and dmesg: uaudio0: at uhub2, port 22, addr 2 (disconnected) pcm8: unregister: channel pcm8:virtual:dsp8.vp0 busy (pid 27294) pcm8: Waiting for sound application to exit! pcm8: detached uaudio0: detached BTW, I'm preparing a merge request for upstream pulseaudio with our patches and new meson patches, should I include this?
Yes, please include this!
(In reply to Hans Petter Selasky from comment #30) https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/277
I'm definitely seeing some progress in this. Previously the whole USB bus would hang and require a hard reset, but not any longer. 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. Logs surrounding the time of disconnect Apr 20 17:46:07 pooter kernel: ugen2.2: <FiiO DigiHug USB Audio> at usbus2 (disconnected) Apr 20 17:46:07 pooter kernel: uhid1: at uhub2, port 3, addr 1 (disconnected) Apr 20 17:46:07 pooter kernel: uhid1: detached Apr 20 17:46:07 pooter kernel: uaudio0: at uhub2, port 3, addr 1 (disconnected) Apr 20 17:46:07 pooter kernel: pcm7: unregister: channel pcm7:virtual:dsp7.vp0 busy (pid 57285) Apr 20 17:46:07 pooter kernel: pcm7: Waiting for sound application to exit! Apr 20 17:46:07 pooter pulseaudio[57285]: [oss] module-oss.c: SNDCTL_DSP_GETOPTR: Bad file descriptor Apr 20 17:46:07 pooter syslogd: last message repeated 2 times Apr 20 17:46:09 pooter kernel: pcm7: unregister: mixer busy Apr 20 17:46:09 pooter kernel: pcm7: Waiting for sound application to exit! Apr 20 17:46:11 pooter kernel: pcm7: unregister: mixer busy Apr 20 17:46:11 pooter kernel: pcm7: Waiting for sound application to exit! Logs surrounding killind the processes holding onto the device Apr 20 17:47:26 pooter kernel: pcm7: Waiting for sound application to exit! Apr 20 17:47:28 pooter kernel: pcm7: detached Apr 20 17:47:28 pooter kernel: uaudio0: detached Apr 20 17:47:29 pooter kernel: ugen2.2: <FiiO DigiHug USB Audio> at usbus2 Apr 20 17:47:29 pooter kernel: uhid1 on uhub2 Apr 20 17:47:29 pooter kernel: uhid1: <FiiO DigiHug USB Audio, class 0/0, rev 1.10/0.01, addr 1> on usbus2 Apr 20 17:47:29 pooter kernel: uaudio0 on uhub2 Apr 20 17:47:29 pooter kernel: uaudio0: <FiiO USB DAC-E10> on usbus2 I've tried this with deadbeef and firefox, which I think at least firefox uses pulseaudio. 12.1-STABLE r360136
Observing similar behaviour, at r360105. Accidentally unplugged then replugged hub with a USB audio interface: May 2 20:28:46 nazar kernel: ugen0.11: <Focusrite Scarlett 2i2 USB> at usbus0 (disconnected) May 2 20:28:46 nazar kernel: uaudio1: at uhub2, port 3, addr 22 (disconnected) May 2 20:28:46 nazar kernel: pcm3: unregister: channel pcm3:virtual:dsp3.vr0 busy (pid 12814) May 2 20:28:46 nazar kernel: pcm3: Waiting for sound application to exit! May 2 20:28:55 nazar kernel: pcm3: unregister: channel pcm3:virtual:dsp3.vr0 busy (pid 12814) May 2 20:28:55 nazar kernel: pcm3: Waiting for sound application to exit! ... usbconfig no longer works: # usbconfig list load: 1.25 cmd: usbconfig 1407 [USB config SX lock] 6.56r 0.00u 0.00s 0% 2600k ^C # and the USB Ethernet dongle plugged into the hub did not reattach. Once I exited the program that had the audio device open (obs-studio) the audio interface and USB Ethernet re-attached.
In past I try to fix this: https://reviews.freebsd.org/D11140 This patch works for mixer but as I remember have issues with dsp.
Created attachment 218672 [details] mixer patch This is patch for mixer to allow USB stack continue work on opened usb sound dev unplug. It helps in most cases, except sound dev unpluged then dsp is open. I did not test for race, as HPS pointed in https://reviews.freebsd.org/D11140
Again, please fix the applications, to close the sound/mixer device upon ioctl/read/write failure. --HPS
Am I understand correctly, that virtual_oss is an option for applications that doesn't behave well? (i.e. virtual_oss acts as proxy before the real hardware and handles ioctl r/w failures) Do I need to apply this patches if I use 12.1-RELENG before the try?
Ivan: Yes - virtual_oss is an option, and it now also has an rc.d script. --HPS
(In reply to Hans Petter Selasky from comment #38) Thanks for virtual_oss! What happen with virtual_oss and sound output then devices unplugged and then connected again?
Audio is simply resumed. --HPS
(In reply to Hans Petter Selasky from comment #38) I've installed virtual_oss and it works as you described. Now I can KVM in and out without devd being upset. Thanks! I have a question though: is it possible to restore vol/pcm values of underlying hardware? It starts with pcm/vol 75:75 after reconnect.
Ivan, What config changes did you have to make when setting up virtual_oss? I have tried the virtual_oss route (both simply running it from the CLI & the rc script) and I get similar behavior as before. What I tried: virtual_oss -C2 -c2 -r 96000 -b 24 -s 768 -R /dev/null -P /dev/dsp7.4 -d dsp
(In reply to courtney.hicks1 from comment #42) I use default settings. Probably, you had something attached to your real hardware before virtual_oss started.