The USB audio, the Witch and the KVM

abishai · Jun 12, 2018

I have manual KVM switch that acts as USB hub between 2 boxes (monitor can handle 2 inputs). I have USB audio, keyboard and mouse attached to KVM.

Disconnect sequence:

Code:

Jun 12 23:19:22 darkstar kernel: ugen0.2: <vendor 0x1a40 USB 2.0 Hub> at usbus0 (disconnected)
Jun 12 23:19:22 darkstar kernel: uhub5: at uhub3, port 8, addr 29 (disconnected)
Jun 12 23:19:22 darkstar kernel: ugen0.3: <vendor 0x0424 product 0x2514> at usbus0 (disconnected)
Jun 12 23:19:22 darkstar kernel: uhub8: at uhub5, port 1, addr 30 (disconnected)
Jun 12 23:19:22 darkstar kernel: ugen0.8: <Logitech Logitech H360 Headset> at usbus0 (disconnected)
Jun 12 23:19:22 darkstar kernel: uaudio0: at uhub8, port 1, addr 6 (disconnected)
Jun 12 23:19:23 darkstar kernel: pcm1: detached
Jun 12 23:19:23 darkstar kernel: uaudio0: detached
Jun 12 23:19:23 darkstar kernel: ugen0.4: <Logitech Logitech G15 Keyboard> at usbus0 (disconnected)
Jun 12 23:19:23 darkstar kernel: uhub9: at uhub8, port 2, addr 31 (disconnected)
Jun 12 23:19:23 darkstar kernel: ugen0.5: <vendor 0x046d Gaming Keyboard> at usbus0 (disconnected)
Jun 12 23:19:23 darkstar kernel: ukbd0: at uhub9, port 1, addr 32 (disconnected)
Jun 12 23:19:23 darkstar kernel: ukbd0: detached
Jun 12 23:19:23 darkstar kernel: uhid0: at uhub9, port 1, addr 32 (disconnected)
Jun 12 23:19:23 darkstar kernel: uhid0: detached
Jun 12 23:19:23 darkstar kernel: ugen0.6: <G15 Keyboard G15 Keyboard> at usbus0 (disconnected)
Jun 12 23:19:23 darkstar kernel: uhid1: at uhub9, port 4, addr 3 (disconnected)
Jun 12 23:19:23 darkstar kernel: uhid1: detached
Jun 12 23:19:23 darkstar kernel: ugen0.7: <Logitech USB Receiver> at usbus0 (disconnected)
Jun 12 23:19:23 darkstar kernel: ukbd1: at uhub5, port 2, addr 5 (disconnected)
Jun 12 23:19:23 darkstar kernel: ukbd1: detached
Jun 12 23:19:23 darkstar kernel: ums0: at uhub5, port 2, addr 5 (disconnected)
Jun 12 23:19:23 darkstar kernel: ums0: detached
Jun 12 23:19:23 darkstar kernel: uhid2: at uhub5, port 2, addr 5 (disconnected)
Jun 12 23:19:23 darkstar kernel: uhid2: detached

Connect sequence:

Code:

Jun 12 23:19:33 darkstar kernel: ugen0.2: <vendor 0x1a40 USB 2.0 Hub> at usbus0
Jun 12 23:19:33 darkstar kernel: uhub5: <vendor 0x1a40 USB 2.0 Hub, class 9/0, rev 2.00/1.11, addr 4> on usbus0
Jun 12 23:19:34 darkstar kernel: uhub5: 4 ports with 4 removable, self powered
Jun 12 23:19:35 darkstar kernel: ugen0.3: <vendor 0x0424 product 0x2514> at usbus0
Jun 12 23:19:35 darkstar kernel: uhub8: <vendor 0x0424 product 0x2514, class 9/0, rev 2.00/b.b3, addr 2> on usbus0
Jun 12 23:19:35 darkstar kernel: uhub8: MTT enabled
Jun 12 23:19:35 darkstar kernel: uhub8: 4 ports with 4 removable, self powered
Jun 12 23:19:36 darkstar kernel: ugen0.4: <Logitech Logitech H360 Headset> at usbus0
Jun 12 23:19:36 darkstar kernel: uaudio0 numa-domain 0 on uhub8
Jun 12 23:19:36 darkstar kernel: uaudio0: <Logitech Logitech H360 Headset, class 0/0, rev 2.00/1.00, addr 7> on usbus0
Jun 12 23:19:36 darkstar kernel: uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Play: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Play: 40000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Play: 32000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Play: 24000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Play: 22050 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Play: 16000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Play: 11025 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Play: 8000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Record: 44100 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Record: 40000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Record: 32000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Record: 24000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Record: 22050 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Record: 16000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Record: 11025 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: Record: 8000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
Jun 12 23:19:36 darkstar kernel: uaudio0: No MIDI sequencer.
Jun 12 23:19:36 darkstar kernel: pcm1: <USB audio> numa-domain 0 on uaudio0
Jun 12 23:19:36 darkstar kernel: uaudio0: HID volume keys found.
Jun 12 23:19:37 darkstar kernel: ugen0.5: <Logitech Logitech G15 Keyboard> at usbus0
Jun 12 23:19:37 darkstar kernel: uhub9: <Logitech Logitech G15 Keyboard, class 9/0, rev 1.10/1.03, addr 1> on usbus0
Jun 12 23:19:37 darkstar kernel: uhub9: 4 ports with 2 removable, bus powered
Jun 12 23:19:38 darkstar kernel: ugen0.6: <vendor 0x046d Gaming Keyboard> at usbus0
Jun 12 23:19:38 darkstar kernel: ukbd0 numa-domain 0 on uhub9
Jun 12 23:19:38 darkstar kernel: ukbd0: <vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 14> on usbus0
Jun 12 23:19:38 darkstar kernel: kbd2 at ukbd0
Jun 12 23:19:38 darkstar kernel: uhid0 numa-domain 0 on uhub9
Jun 12 23:19:38 darkstar kernel: uhid0: <vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 14> on usbus0
Jun 12 23:19:39 darkstar kernel: ugen0.7: <G15 Keyboard G15 Keyboard> at usbus0
Jun 12 23:19:39 darkstar kernel: hid_get_item: Number of items(991) truncated to 255
Jun 12 23:19:39 darkstar kernel: hid_get_item: Number of items(991) truncated to 255
Jun 12 23:19:39 darkstar kernel: uhid1 numa-domain 0 on uhub9
Jun 12 23:19:39 darkstar kernel: uhid1: <G15 Keyboard G15 Keyboard, class 0/0, rev 2.00/1.03, addr 15> on usbus0
Jun 12 23:19:39 darkstar kernel: hid_get_item: Number of items(991) truncated to 255
Jun 12 23:19:39 darkstar last message repeated 2 times
Jun 12 23:19:39 darkstar kernel: ugen0.8: <Logitech USB Receiver> at usbus0
Jun 12 23:19:39 darkstar kernel: ukbd1 numa-domain 0 on uhub5
Jun 12 23:19:39 darkstar kernel: ukbd1: <Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 10> on usbus0
Jun 12 23:19:39 darkstar kernel: kbd3 at ukbd1
Jun 12 23:19:39 darkstar kernel: ums0 numa-domain 0 on uhub5
Jun 12 23:19:39 darkstar kernel: ums0: <Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 10> on usbus0
Jun 12 23:19:39 darkstar kernel: ums0: 16 buttons and [XYZT] coordinates ID=2
Jun 12 23:19:39 darkstar kernel: uhid2 numa-domain 0 on uhub5
Jun 12 23:19:39 darkstar kernel: uhid2: <Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 10> on usbus0

As you may see, kernel reports devices back and Xorg picks them up. The problem is when something holds uaudio.

Code:

Jun 12 23:14:02 darkstar kernel: uaudio0: at uhub8, port 1, addr 10 (disconnected)
Jun 12 23:14:02 darkstar kernel: pcm1: unregister: channel pcm1:virtual:dsp1.vp0 busy (pid 1399)
Jun 12 23:14:02 darkstar kernel: pcm1: Waiting for sound application to exit!
Jun 12 23:14:04 darkstar kernel: pcm1: unregister: channel pcm1:virtual:dsp1.vp0 busy (pid 1399)
Jun 12 23:14:04 darkstar kernel: pcm1: Waiting for sound application to exit!
Jun 12 23:14:06 darkstar kernel: pcm1: unregister: channel pcm1:virtual:dsp1.vp0 busy (pid 1399)
Jun 12 23:14:06 darkstar kernel: pcm1: Waiting for sound application to exit!
Jun 12 23:14:08 darkstar kernel: pcm1: unregister: channel pcm1:virtual:dsp1.vp0 busy (pid 1399)
Jun 12 23:14:08 darkstar kernel: pcm1: Waiting for sound application to exit!
Jun 12 23:14:10 darkstar kernel: pcm1: unregister: channel pcm1:virtual:dsp1.vp0 busy (pid 1399)
Jun 12 23:14:10 darkstar kernel: pcm1: Waiting for sound application to exit!

Kernel stops detaching sequence, doesn't start attaching sequence (when I switch KVM back) and waits indefinitely process to exit. It's hard to kill application without keyboard and mouse. Maybe, it's possible to tell kernel evict device without any waiting? Device is absent, so probably all handles are already invalid, why wait?

Deleted member 54719 · Jun 13, 2018

The KVM might not be a complete USB passthrough. It might only pass HID and STORAGE class devices. Timing/latentcy requirements for reliable USB audio might preclude it from being handled by the KVM at their product pricepoint.

ralphbsz · Jun 22, 2018

abishai said:
Kernel stops detaching sequence, doesn't start attaching sequence (when I switch KVM back) and waits indefinitely process to exit. It's hard to kill application without keyboard and mouse. Maybe, it's possible to tell kernel evict device without any waiting? Device is absent, so probably all handles are already invalid, why wait?

If a running process has a device file like /dev/uaudio0 or /dev/pcm1 open, then the kernel can not delete (unlink, destroy) that device file, even when the underlying hardware goes away. That would simply be illegal. But the physical device has really gone away (become unreachable), so keeping the device file around is pointless. So what can the kernel do? It seems that what is implemented is one good option: wait for the process to close the device file, for example by exiting. The only problem with that theory is that the kernel has no way to tell the process to go away, so it requires a human (or script or devd or on Linux systemd and its tentacles into the audio infrastructure) to stop the program.

Another option is what is implemented for disk drives: With hot-plug (which is used for both SCSI and ATA), a disk drive simply can go away, even when a process or a file system has the device open. What most low-level drivers do is that if a device file is open when the disk goes away, they mark the device file as non-functioning, and they return error ENXIO (error device not configured) to any operation. The program running on the device (in the case of disks often a file system) need to learn that ENXIO means that the device is gone, won't come back to life, and you have to give up and close the device file. Doing a clean exit requires programming work; fortunately, in most cases unexpected errors blow up programs, so they exit, so they close the open device: ugly but functional.

I think you need to talk to the folks who implemented the FreeBSD sound infrastructure about this; I don't know whether any of them are here on the forum. Opening a kernel bug might be a good and polite way to get their attention.

abishai · Jun 22, 2018

Well, the problem doesn't require KVM. Just plug out any USB audio while it plays and you'll get devd confusion. I don't think it's good solution with the bus that supports hot plug. I was in hope that some magic knob exists..

Cath O'Deray · Mar 17, 2022

ralphbsz said:
If a running process has a device file like /dev/uaudio0 or /dev/pcm1 open, then the kernel can not delete (unlink, destroy) that device file, even when the underlying hardware goes away. … option: wait for the process to close the device file, for example by exiting. … the kernel has no way to tell the process to go away, so it requires a human (or script or devd or …) to stop the program. …

When I last checked: without manual or scripted intervention, simply attempting to sleep the computer will fail to suspend FreeBSD and it's necessary to force a stop of the computer – highly disruptive, with (in many cases) a significant risk of loss of data.

ralphbsz said:
I think you need to talk to the folks who implemented the FreeBSD sound infrastructure about this; I don't know whether any of them are here on the forum. Opening a kernel bug might be a good and polite way to get their attention.

hselasky@ please: do the cases above, and the two topics below, fall under the umbrella of 194727, or something broader?

(Is there, should there be, a meta bug with 194727 in its dependency tree?)

194727 – uaudio device gets disconnected, and hangs usb until everything using /dev/mixer* is closed

USB DAC unplugged hangs up rest of USB devices

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

forums.freebsd.org

stratacast1 said:
… works perfectly, until I switch away for a certain amount of time or unplugging the KVM device altogether. …

k.jacker said:
This is a known issue in the uaudio() driver or the usb drivers. There have been several PR … I think it‘s still not clear where the problem. …

Not able to disconnect/reconnect USB switch in Plasma

Hello, I am trying out KDE Plasma on FreeBSD. I use a USB switch to be able to switch between my desktop computer and my work laptop with the same mouse and keyboard. The USB swith is connected to a mouse, a keyboard, a USB headset and a webcam. When I switch from KDE FreeBSD on the desktop...

forums.freebsd.org

paulez said:
… switch back, I don’t get mouse and keyboard input …

✟ hselasky@ · Mar 17, 2022

grahamperrin@

Most problems with USB audio is about that user-space applications don't close the character device handles they have opened towards the kernel.

For example an application has /dev/dsp<N> or /dev/mixer<N> opened.

When you enter suspend, the kernel will detach all USB devices first, and detach can only happen when all /dev/dsp<N> and /dev/mixer<N> are closed.

pulseaudio has got some patches to deal better with this.

virtual_oss in ports may be a solution to hide this problem.

But in general applications that deal with pluggable USB devices, even when using libusb, must poll their status every second, for example by issuing a dummy IOCTL, and if they see the device is gone, then they must close the device handle and leave the device alone. This is currently the responsibility of the application and not the kernel!

Why can't the kernel deal with this? Because then we end up with a resource leak, that buggy applications never close their file handles and keep memory and DSP device units allocated. Some applications do only scan /dev/dsp<0..9>, so that means after 10 suspend and resume cycles, your USB audio device will no longer show up in the menu.

Put your effort into patching those apps that are "broken", or list them here, so that I may help you!

--HPS

Cath O'Deray · Mar 17, 2022

Thanks, I'll revisit PulseAudio.

(I never got my head around what happened after the well-publicised up-streaming; <https://forums.freebsd.org/posts/517608>.)

Cath O'Deray · Mar 20, 2022

hselasky@ said:
… When you enter suspend, the kernel will detach all USB devices first, and detach can only happen when all /dev/dsp<N> and /dev/mixer<N> are closed.

audio/pulseaudio has got some patches to deal better with this. …

Nice!

My /usr/local/etc/pulse/client.conf no longer includes non-standard autospawn=no (the line is commented out).

The script that I use to sleep my computer (condensed from <https://forums.freebsd.org/posts/531858>):

Code:

#!/bin/sh
while mount | grep Transcend 2>&1; do
   zpool export Transcend
   sleep 5
done
zpool offline august gpt/cache-august
zpool offline august gpt/duracell
sync
sysctl hw.snd.default_unit=1
while fstat | grep -e dsp -e mixer 2>&1; do
   fstat | grep -e dsp -e mixer | cut -w -f 3 | while read pid;
      do kill -15 "$pid"
   done
done
/usr/sbin/acpiconf -s3

The first run resulted in failure to suspend, it was necessary to force off the computer:

Most remarkable before this failure, if I recall correctly:

/usr/local/bin/pulseaudio had spawned, however Firefox without a media.cubeb.backend preference was silent during playback at e.g. <https://www.ted.com/talks/james_geary_metaphorically_speaking>.

Code:

root@mowa219-gjp4-8570p-freebsd:~ # zpool status -x
  pool: august
 state: ONLINE
status: One or more devices has been taken offline by the administrator.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Online the device using 'zpool online' or replace the device with
        'zpool replace'.
  scan: scrub repaired 0B in 02:44:47 with 0 errors on Sun Dec 12 06:14:24 2021
config:

        NAME                STATE     READ WRITE CKSUM
        august              ONLINE       0     0     0
          ada0p3.eli        ONLINE       0     0     0
        cache
          gpt/duracell      OFFLINE      0     0     0
          gpt/cache-august  OFFLINE      0     0     0

errors: No known data errors
root@mowa219-gjp4-8570p-freebsd:~ # zpool status -x
all pools are healthy
root@mowa219-gjp4-8570p-freebsd:~ # zpool iostat -v
                      capacity     operations     bandwidth
pool                alloc   free   read  write   read  write
------------------  -----  -----  -----  -----  -----  -----
august               655G   257G     96     25  1.87M   381K
  ada0p3.eli         655G   257G     96     25  1.87M   381K
cache                   -      -      -      -      -      -
  gpt/duracell      96.0M  15.3G      0      0  1.35K   268K
  gpt/cache-august      0  28.8G      0      0  1.35K     81
------------------  -----  -----  -----  -----  -----  -----
root@mowa219-gjp4-8570p-freebsd:~ #

Persistent L2ARC dropped from hot (160 GiB uncompressed) to cold (zero), which is a real drag, but I don't mind on this occasion, because:

all subsequent sleeps (with the suspend.sh script) succeeded ☑

✟ hselasky@ · Mar 20, 2022

Can you check that these changes are in our FreeBSD pulsaudio port?

FreeBSD support: meson build, import downstream patches, more improvements (!277) · Merge requests · PulseAudio / pulseaudio · GitLab

This MR brings some downstream patches from FreeBSD Ports here (most importantly "detect: fix/improve FreeBSD support" — audio does not play...

gitlab.freedesktop.org

I remember I made some specific pulseaudio patches, but totally lost track of them.

Cath O'Deray · Mar 20, 2022

hselasky@ said:
Can you check that these changes are in our FreeBSD pulsaudio port? …

Merged 2021-01-18: I suspect not.

Via <https://freedesktop.org/software/pulseaudio/releases/>:

pulseaudio-14.2.tar.gz 2021-01-16 modules/module-devd-detect.c not present
pulseaudio-14.99.1.tar.gz 2021-05-17 modules/module-devd-detect.c present

<https://www.freshports.org/audio/pulseaudio/#distinfo> we're at 14.2, and I see no superior version number at <https://cgit.freebsd.org/ports/log/audio/pulseaudio>.

In any case: I'm glad that PulseAudio seems to no longer prevent sleep (for me, with the custom script on 14.0-CURRENT). I'll retry without the script …

Cath O'Deray · Mar 20, 2022

After I connected a USB headset, it was:

usable with OSS
not found by PulseAudio

– please, is this expected?

Code:

% pkg info -x pulseaudio
linux-c7-pulseaudio-libs-10.0_3
pulseaudio-14.2_3
pulseaudio-module-xrdp-0.6
pulseaudio-qt-1.3
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #7 main-n253861-92e6b4712b5-dirty: Sat Mar 19 02:40:21 GMT 2022     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-
NODEBUG amd64 1400053 1400053
%

✟ hselasky@ · Mar 21, 2022

I think you need to restart the application for it to be detected by pulseaudio.

Cath O'Deray · Mar 21, 2022

hselasky@ said:
I think you need to restart the application for it to be detected by pulseaudio.

After the headphones were not detected in audio/plasma5-plasma-pa (integral to the system tray of Plasma), I opened PulseAudio Volume Control (audio/pavucontrol). Not detected.

Cath O'Deray · Mar 21, 2022

Good news, non-detection of the USB headset (by PulseAudio Volume Control) was not reproducible.

Unfortunately, this recurred:

grahamperrin said:
… failure to suspend, it was necessary to force off the computer: …

– and persisted (three successive failures), so I reverted to autospawn=no in /usr/local/etc/pulse/client.conf.

FreeBSD bug 262713 – audio/pulseaudio: ~~update to 14.99.1 or greater~~ update to 15.0

cederom · Mar 24, 2022

HotPlug / Devd would be nice feature in PulseAudio and Bluetooth Headset using virtual_oss. Until now I had to restart PA by hand on each Bluetooth attach/detach.

Another extremely useful feature that comes from real life would be DEVD detection of Bluetooth connected devices - then devd could launch virtual_oss and reload PulseAudio. That would chainload all necessary actions just by connecting a Bluetooth headset

The USB audio, the Witch and the KVM

Deleted member 54719

Guest