Bug 194727 - uaudio device gets disconnected, and hangs usb until everything using /dev/mixer* is closed
Summary: uaudio device gets disconnected, and hangs usb until everything using /dev/mi...
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Hans Petter Selasky
URL:
Keywords:
: 239730 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-10-31 23:11 UTC by Tobias Berner
Modified: 2022-10-05 01:02 UTC (History)
24 users (show)

See Also:


Attachments
Patch for pulseaudio port (10.03 KB, patch)
2020-04-01 18:36 UTC, Hans Petter Selasky
no flags Details | Diff
mixer patch (2.15 KB, patch)
2020-10-11 20:37 UTC, Ivan Rozhuk
no flags Details | Diff
FreeBSD 13.0-CURRENT #75 main-c572-g82397d791 failed to suspend (170.27 KB, image/jpeg)
2021-01-08 03:35 UTC, Graham Perrin
no flags Details
Pulseaudio fix for detachable devices. (9.67 KB, patch)
2022-05-25 08:24 UTC, Hans Petter Selasky
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Berner 2014-10-31 23:11:43 UTC
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.
Comment 1 Hans Petter Selasky freebsd_committer 2014-11-01 07:48:47 UTC
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
Comment 2 Tobias Berner 2014-11-01 10:28:58 UTC
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
Comment 3 Cory Smelosky 2015-12-16 04:50:49 UTC
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?  \
Comment 4 Hans Petter Selasky freebsd_committer 2015-12-16 15:56:46 UTC
Hi,

Yes, mixer apps must close their handles when they detect the device is gone!

--HPS
Comment 5 Ivan 2018-06-22 17:49:57 UTC
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.
Comment 6 Hans Petter Selasky freebsd_committer 2018-06-22 20:50:42 UTC
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
Comment 7 Ivan 2018-06-23 20:30:26 UTC
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
Comment 8 Hans Petter Selasky freebsd_committer 2018-06-24 08:10:09 UTC
kmix is a process in KDE5. Why not just fix it?

--HPS
Comment 9 Hans Petter Selasky freebsd_committer 2018-06-24 08:18:19 UTC
One solution here is that the sound driver waits a bit and then kills the process in question with SIGPIPE.
Comment 10 Hans Petter Selasky freebsd_committer 2018-06-24 08:30:42 UTC
I'm not sure what will happen if kmix is killed. Will it be restarted somehow? I guess this needs a better fix.
Comment 11 Andriy Gapon freebsd_committer 2018-06-24 09:12:58 UTC
(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?
Comment 12 Hans Petter Selasky freebsd_committer 2018-06-24 09:28:08 UTC
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
Comment 13 Ivan 2018-06-24 18:26:07 UTC
(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.
Comment 14 benibilme 2018-10-27 19:07:32 UTC
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
Comment 15 Theron Tarigo 2019-01-16 06:52:08 UTC
(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).
Comment 16 Matthias Oestreicher 2019-04-25 17:57:14 UTC
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
Comment 17 unrelentingtech 2019-07-24 22:32:40 UTC
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.
Comment 18 unrelentingtech 2019-08-04 13:24:55 UTC
(In reply to Greg V from comment #17)
update: a different USB soundcard seems fine so far
Comment 19 Hans Petter Selasky freebsd_committer 2019-08-09 07:34:30 UTC
*** Bug 239730 has been marked as a duplicate of this bug. ***
Comment 20 Allan Jude freebsd_committer 2020-01-17 03:22:01 UTC
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.
Comment 21 Hans Petter Selasky freebsd_committer 2020-01-17 09:34:20 UTC
There has been no kernel changes in this area for a long time. Likely some applications which keep the device open.

--HPS
Comment 22 commit-hook freebsd_committer 2020-03-04 17:23:54 UTC
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
Comment 23 commit-hook freebsd_committer 2020-03-11 08:25:00 UTC
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
Comment 24 commit-hook freebsd_committer 2020-03-11 08:26:03 UTC
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
Comment 25 commit-hook freebsd_committer 2020-03-11 08:27:06 UTC
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
Comment 26 commit-hook freebsd_committer 2020-03-11 08:27:08 UTC
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
Comment 27 Hans Petter Selasky freebsd_committer 2020-04-01 18:36:44 UTC
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!
Comment 28 Hans Petter Selasky freebsd_committer 2020-04-01 18:39:55 UTC
Added gnome @ freebsd . org : Please approve my Pulseaudio patch.

Thank you!
Comment 29 unrelentingtech 2020-04-02 16:27:55 UTC
(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?
Comment 30 Hans Petter Selasky freebsd_committer 2020-04-02 16:53:14 UTC
Yes, please include this!
Comment 31 unrelentingtech 2020-04-03 13:11:02 UTC
(In reply to Hans Petter Selasky from comment #30)

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/277
Comment 32 courtney.hicks1 2020-04-21 00:58:01 UTC
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
Comment 33 Ed Maste freebsd_committer 2020-05-03 01:12:01 UTC
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.
Comment 34 Ivan Rozhuk 2020-10-11 20:28:04 UTC
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.
Comment 35 Ivan Rozhuk 2020-10-11 20:37:18 UTC
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
Comment 36 Hans Petter Selasky freebsd_committer 2020-10-12 07:01:44 UTC
Again, please fix the applications, to close the sound/mixer device upon ioctl/read/write failure.

--HPS
Comment 37 Ivan 2020-10-12 11:34:45 UTC
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?
Comment 38 Hans Petter Selasky freebsd_committer 2020-10-12 13:05:26 UTC
Ivan:

Yes - virtual_oss is an option, and it now also has an rc.d script.

--HPS
Comment 39 Ivan Rozhuk 2020-10-12 13:19:59 UTC
(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?
Comment 40 Hans Petter Selasky freebsd_committer 2020-10-12 13:21:16 UTC
Audio is simply resumed.

--HPS
Comment 41 Ivan 2020-10-12 16:30:57 UTC
(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.
Comment 42 courtney.hicks1 2020-10-15 02:32:13 UTC
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
Comment 43 Ivan 2020-10-16 07:51:30 UTC
(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.
Comment 44 unrelentingtech 2020-11-15 20:25:43 UTC
So while hotplug-unplug has been working reliably with pulse (with my version), this is still an issue with suspend. (Oddly, depending on which bus I plug the device into, it's either the waiting to exit message loop or a silent hang.)

Userspace does not have the ability to respond at all when the detach is happening because of suspend!

Now, the workaround is (of course) kldunload snd_uaudio in /etc/rc.suspend and kldload snd_uaudio in /etc/rc.resume. But having to do that is not great.
Comment 45 Hans Petter Selasky freebsd_committer 2020-11-15 21:48:36 UTC
Greg: How are those pulseaudio patches doing? I still don't see them upstream?

--HPS
Comment 46 unrelentingtech 2020-11-16 01:08:21 UTC
(In reply to Hans Petter Selasky from comment #45)
No response so far. Pulse isn't very active these days. (Looks like PipeWire is the future, but it lacks an OSS backend currently.)
Comment 47 Hans Petter Selasky freebsd_committer 2020-11-16 08:27:45 UTC
Could we try to get those patches in ports, at least?
Comment 48 Ivan Rozhuk 2020-12-21 04:17:21 UTC
Update diff: https://reviews.freebsd.org/D11140
Same in git: https://github.com/rozhuk-im/freebsd/commit/74d5727357dfcd11df5ab27cb2a517f6d6ee5d28

this only for mixer, if dsp open - usb will hang.
Comment 49 Graham Perrin freebsd_committer 2021-01-08 03:35:34 UTC
Created attachment 221375 [details]
FreeBSD 13.0-CURRENT #75 main-c572-g82397d791 failed to suspend

Might this bug benefit from a broader title? 

In this photograph: 

* the failure to suspend did not involve disconnection

----

See also: bug 202275

> USB SX lock hang involving sound devices

– and bug 220949

> When the only USB soundcard is disconnected, defunct 
> /dev/dsp0 is left, kernel warnings, programs hang
> 
> …
> 
> … The solution is not just straight forward, due to mmap() use. See also.
> 
> https://reviews.freebsd.org/D11140

>> ⚙ D11140 OSS: allow unplug soundcars without apps close devices

I don't doubt the complexity but essentially – wishing for improvements to the FreeBSD sleep/wake story: 

* I'd like a simple press on a button to not require forethought to audio, sound, pause, playback or USB

– the power button, preset to suspend. Thanks.
Comment 50 Graham Perrin freebsd_committer 2021-01-08 03:44:55 UTC
(In reply to Theron Tarigo from comment #15)

> … virtual_oss behaves very well …

The failure to suspend at comment 49 did involve virtual_oss. 

Virtual OSS Control (audio/virtual_oss_ctl) might have been running. 

----

(In reply to Matthias Oestreicher from comment #16)

> … Only solution is to ssh into the machine and …

This is useful – thanks – I'll keep a note of your comment separate from my computer.
Comment 51 Ed Maste freebsd_committer 2021-02-13 20:40:24 UTC
(In reply to Hans Petter Selasky from comment #36)
> Again, please fix the applications, to close the sound/mixer device upon 
> ioctl/read/write failure.

This needs to be done, of course, but I think avg@'s suggestion in comment #11 is also reasonable; the kernel shouldn't be at the mercy of a buggy application.

> 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.

That is in effect already the case though, the system does not operate correctly until the offending application is terminated and restarted anyhow.
Comment 52 Hans Petter Selasky freebsd_committer 2021-02-13 20:56:48 UTC
I'm sorry to say, that trying to fix the kernel side will eventually lead to a kernel memory leak. You can't allow user-space to hold kernel resources forever.

For example when watching videos on Facebook with Firefox, sometimes audio stops working, because too many audio devices are opened, due to a user-space bug not caring to close the file handles.

--HPS
Comment 53 Maciej Pasternacki 2021-04-09 22:19:47 UTC
I have this problem and as a workaround I added a file in /etc/syslog.d/ that kills pulseaudio on message match. It might be overkill (pun not intended) for heavy users of pulseaudio, but I'm using it only for web browser and I don't really care if it dies when I switch KVM.

Here's the snippet:

:msg, contains, "Waiting for sound application to exit!"
kern.* |while read _ ; do pkill pulseaudio || : ; done
Comment 54 Graham Perrin freebsd_committer 2021-05-14 06:28:22 UTC
From <https://forums.freebsd.org/threads/80412/>: 

> … the circumstances puzzle me, because it's sometimes necessary to 
> force off the computer after:
> 
> *   _not_ knowingly listening, or speaking, to anything 
>     (not knowingly using any audio device)
> 
> *   _not_ knowingly disconnecting any device.
Comment 55 deciusmagnus 2021-07-27 17:41:13 UTC
I just got this error in dmesg. I cannot use the USB port where the USB card was inserted. The usbconfig utility appears to hang now. On other OSes I can unplug the current device and plug another device in the same port.
Comment 56 Hans Petter Selasky freebsd_committer 2021-07-28 18:03:34 UTC
Which kernel are you using?

procstat -akk

will reveal where it is hanging. Just look for "usb", "pcm" or "mixer".

--HPS
Comment 57 Theron Tarigo 2021-07-30 00:57:42 UTC
I started hacking on this today, and I see two options for fixing the kernel side:

1. allow pcm_unregister to forcibly close and destroy the device file.  The kernel already does something like this for block storage devices removed while in use.  Applications may respond badly but it's better than what we have now, and pulseaudio and virtual_oss should already handle this.

2. unhook uaudio instance destruction from device detach.  This allows the pcm device to persist independently of the usb device, ready to clean up when it can.

(2) seems the better option, as it provides the opportunity to reattach pcm device when the USB device is reattached, or after resume from suspend.  However I'm unsure how to proceed with this option.  Are there any other drivers capable of persisting independently of their bus devices' detaching to use as an example?

As for the kernel resource "leak": I'm well aware option (2) leads right into this.  However unless implemented incorrectly these resources are still tied to a user process: recovery of the exhausted resource by action taken from within userspace (killing the offending and leaky application, as we already do for low memory, too many tabs playing audio, etc.) remains sufficient.
Comment 58 Tomasz "CeDeROM" CEDRO 2021-10-17 18:59:10 UTC
Hey there :-) This happens for me when PulseAudio is running and I detach USB audio. I need to kill PA deamon by hand, then handle gets free, then device detaches, then I can start again PA or its being started by my WM (Enlightenment) :-)
Comment 59 Alexander Vereeken 2021-10-31 09:44:53 UTC
(In reply to Tomasz "CeDeROM" CEDRO from comment #58)

On some environments you can try to avoid using pulseaudio in the first place.

Open /usr/local/etc/pulse/client.conf and uncomment autospawn and set it to no.
Comment 60 Yuri Victorovich freebsd_committer 2022-05-25 05:14:08 UTC
I just got the same on 13.1-STABLE:
May 24 22:00:28 yv kernel: pcm6: Waiting for sound application to exit!
May 24 22:00:28 yv kernel: pcm6: unregister: mixer busy
May 24 22:00:28 yv kernel: pcm6: Waiting for sound application to exit!
May 24 22:00:28 yv kernel: pcm6: unregister: mixer busy
May 24 22:00:28 yv kernel: pcm6: Waiting for sound application to exit!
May 24 22:00:28 yv kernel: pcm6: unregister: mixer busy
Comment 61 Hans Petter Selasky freebsd_committer 2022-05-25 06:58:59 UTC
This is a bug in pulseaudio.

It _needs_ to close all file handles when devices are going away!
Comment 62 Yuri Victorovich freebsd_committer 2022-05-25 07:18:05 UTC
(In reply to Hans Petter Selasky from comment #61)


> This is a bug in pulseaudio.
> 
> It _needs_ to close all file handles when devices are going away!

But there are a lot of applications and only one kernel. Instead of fixing all applications - kernel should just fail all file descriptors that interface the device that went away. Applications would see the system call failures and handle this accordingly.


Yuri
Comment 63 Hans Petter Selasky freebsd_committer 2022-05-25 07:21:11 UTC
Yuri:

And then pulseaudio will keep on using a dead mixer device forever?

--HPS
Comment 64 Ivan Rozhuk 2022-05-25 07:23:44 UTC
(In reply to Yuri Victorovich from comment #62)

https://reviews.freebsd.org/D11140
This fixes mixer issue, but after that you will see same for dsp device.

I agree that kernel must return some error and allow USB stack to unplug device.
Comment 65 Hans Petter Selasky freebsd_committer 2022-05-25 07:24:23 UTC
> But there are a lot of applications and only one kernel.

Most applications I use run on top of virtual_oss, and devices going away and coming back has never been a problem. I usually disable pulseaudio.

--HPS
Comment 66 Ivan Rozhuk 2022-05-25 07:25:08 UTC
(In reply to Hans Petter Selasky from comment #63)

This is pulse deal, I use gtk-mixer and it does not have problem than mixer is gone.
Comment 67 Hans Petter Selasky freebsd_committer 2022-05-25 07:31:37 UTC
> I agree that kernel must return some error and allow USB stack to unplug device.

The kernel already returns an error on all mixer IOCTL's in the detaching state.

All pulseaudio has to do is to poll a dummy mixer IOCTL every 4 seconds or so, if it fails, it must close(mixer_fd) .

D11140 is not a real solution, because pulseaudio will still go on using the old mixer fd, and so the mixer becomes unusable anyway for the client.

Do I have to write up a patch for pulseaudio myself?

--HPS
Comment 68 Ivan Rozhuk 2022-05-25 07:58:38 UTC
(In reply to Hans Petter Selasky from comment #67)

Than some one do: umount -f /mnt/... then it unmounted, no matter what some app keep some fd open.
Or then user removes usb flash drive and insert another - OS does not stick with: "fd is open, come back later".

I do not care pulse or any other apps, my issue that USB stack is unusable after usb sound adapter disconnected without all apps closes fd.
Comment 69 Yuri Victorovich freebsd_committer 2022-05-25 07:59:55 UTC
(In reply to Hans Petter Selasky from comment #63)

> And then pulseaudio will keep on using a dead mixer device forever?

My understanding is that file descriptors of dead devices remain alive while applications have them open. If kernel would kill such file descriptors and fail any attempts to reopen devices again (if devices are still present) - pulseaudio won't be able to use a dead mixer forever. In case it would keep trying to reopen a failed device in a loop - this is a bug in pulseaudio.

But currently pulseaudio just waits on dead device descriptors because they appear alive to it.
Comment 70 Hans Petter Selasky freebsd_committer 2022-05-25 08:24:53 UTC
Created attachment 234198 [details]
Pulseaudio fix for detachable devices.

Yuri,

I agree that there is a problem. Now I've made a patch for the pulseaudio port. Can you test and see if your problem is gone and I will put it into ports ASAP.

--HPS
Comment 71 Hans Petter Selasky freebsd_committer 2022-05-25 08:30:36 UTC
> If kernel would kill such file descriptors ...

Only applications can fully kill file descriptors! It is not possible for the kernel to kill file descriptors in a non-blocking fashion.

> I do not care pulse or any other apps, my issue that USB stack is unusable after usb sound adapter disconnected without all apps closes fd.

This is the expected behaviour. Remember that the OSS support in pulseaudio was written when detachable audio devices didn't yet exist. So how can you expect it to work accordingly?

I'm saying again, the problem is not the kernel, but in user-space. The kernel cannot kill file descriptors like you think, no matter what. It's always the applications responsibility to clean up that as long as it is running, but the kernel can probably kill misbehaving applications after a while.

--HPS
Comment 72 commit-hook freebsd_committer 2022-05-25 09:01:04 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=3bc8803e5c4a96b60ffe5fa6887e2b73e0df7756

commit 3bc8803e5c4a96b60ffe5fa6887e2b73e0df7756
Author:     Hans Petter Selasky <hselasky@FreeBSD.org>
AuthorDate: 2022-05-25 08:39:40 +0000
Commit:     Hans Petter Selasky <hselasky@FreeBSD.org>
CommitDate: 2022-05-25 08:58:56 +0000

    audio/pulseaudio: Fix for detachable USB audio devices.

    Make sure the pulseaudio OSS module does not keep the mixer device opened
    forever. Instead open and close the mixer device for every access. Also
    fix some bad code mixing get- and set- volume while at it.

    Reported by: several
    PR: 194727
    Approved by: pi (implicit)

 audio/pulseaudio/Makefile                          |   2 +-
 .../files/patch-src_modules_oss_module-oss.c       | 256 ++++++++++++++++++++-
 2 files changed, 255 insertions(+), 3 deletions(-)
Comment 73 Ivan 2022-05-25 09:03:56 UTC
I switched to virtualoss several years ago and have absolutely no problems since. I extensively KVM in and out without any issues.
Comment 74 Ivan Rozhuk 2022-05-25 15:11:09 UTC
(In reply to Hans Petter Selasky from comment #71)

> I'm saying again, the problem is not the kernel, but in user-space. The kernel cannot kill file descriptors like you think, no matter what. It's always the applications responsibility to clean up that as long as it is running, but the kernel can probably kill misbehaving applications after a while.


Idea is to leave descriptor associated data in kernel (until app close it) but do not block USB stack detaching/attaching operations.
I done this for mixer but dsp code is too complex for me for do same patch.

Again: I do not care apps, issue in USB stack detaching/attaching operations.
I have USB hub with mouse, keyboard and usb sound stick. Some times it lost USB link and I can not close apps because my mouse and keyboard does not reattach, they wait for USB detaching USB sound stick.
This is very annoying.
Comment 75 deciusmagnus 2022-05-25 18:39:21 UTC
(In reply to Hans Petter Selasky from comment #71)
My complaint, and I think others have expressed this, is that a misbehaving application should not prevent me from using the USB port the sound card was inserted previously. A misbehaving application should not have the level of control of the system. While PulseAudio is having an issue, the handling of this situation needs to be more robust.
Comment 76 Hans Petter Selasky freebsd_committer 2022-05-25 21:26:45 UTC
(In reply to Hans Petter Selasky from comment #71)
> My complaint, and I think others have expressed this, is that a misbehaving 
> application should not prevent me from using the USB port the sound card was 
> inserted previously. A misbehaving application should not have the level of 
> control of the system. While PulseAudio is having an issue, the handling of 
> this situation needs to be more robust.

Hi,

The only responsibility of the kernel is to garbage collect memory and resources which are not freed when a user-space application exits.

For example if you open a shared FIFO and don't read the data which is written there, the writer will eventually be blocked as the internal buffer it has is used up!

The same with USB. If you get any handle on a USB device, and don't free it when the device vanishes, the kernel will wait enumerating further devices, because it not only wants the memory back it also wants to free up unit numbers for coming character device nodes.

I'm not willing to leak memory as a compromise for faulty applications. But I could be willing to implement a kill after timeout sysctl, that if an application using USB resources does not free up its handles and such, it gets automagically killed, like out of memory, OOM.

What do you think about that?

Applications and the kernel are in a symbiosis and must "talk" to each other correctly for things to work in the end. It's like a protocol.

Audio applications may need realtime priority for example, to process audio in time, but if they are broken, they may go looping and use 100% CPU and lock your system anyway.

Again, if your application leaks file descriptors, and you think it is a bug, I would fix the application and not the kernel.

--HPS
Comment 77 deciusmagnus 2022-05-25 22:22:37 UTC
(In reply to Hans Petter Selasky from comment #76)
I would agree to not leaking is important and I also agree PulseAudio has an issues, but so does the kernel.

The only thing to be negatively impacted in this situation, is the misbehaving application. I don't really care how that is dealt with, but when I unplug a USB device from a port, I would expect that port to be available for other devices; this has been my experience with other operating systems.

I understand proper communication between an application and kernel is vital, but the kernel is the one in power here and I trust it, more so than an application, to manage certain resources. I would say that a misbehaving application being able to keep a USB port from being used is a problem of resource management on the kernel's part. Either automatically kill the application or do what a kernel can do to make sure an application can't let this happen; a misbehaving application is already not handling an exceptional situation and the kernel can automatically do what it needs as far as I'm concerned.
Comment 78 Yuri Victorovich freebsd_committer 2022-05-25 23:04:07 UTC
(In reply to Hans Petter Selasky from comment #70)

> I agree that there is a problem. Now I've made a patch for the pulseaudio port.

It seems that both pulseaudio and kernel have problems.

Without pulseaudio some other program would cause this again.

Both should be fixed.



Yuri
Comment 79 Theron Tarigo 2022-06-05 22:32:20 UTC
When an application has a memory leak, that kernel-provided memory resource is tied up until the application cleans up or dies, but memory allocation continues to function.
When an application keeps a file open on a filesystem which no longer exists (physically removed/force unmounted), kernel resources for descriptor management are tied up until the application cleans up or dies, but filesystem mounting continues to function.
When an application keeps a block device open after the device is destroyed, kernel resource are tied up until the application cleans up or dies, but block device attachment continues to function.

It seems clear that USB audio is the odd one out here, compared to these three existing features of the kernel's resource management.

How is block device detachment (despite inability to immediately destroy the file descriptor) implemented?  Trying to find this in the sources is where I last got stuck when trying to solve the USB audio problem myself.
Comment 80 Theron Tarigo 2022-06-06 06:16:02 UTC
(In reply to Theron Tarigo from comment #79)
Right, I've worked out what's the usual pattern for bus device vs. character device decoupling.  Remaining work is to untangle master dsp device from its channels and its clone and mixer devs - I suppose they will enter a state of being effectively independent dummy devices waiting to be closed once the bus device that tied them together is destroyed.