Ttyjfyk

Once upon a time, I was abe to plug in my Zoom H4n field recorder into my main PC and have it appear as another audio source inside Audacity for live recording. Worked great. Sometime in the last few months, however, this stopped working. The H4n "appears" (alsamixer sees it), but the PCMs don't work.

When you plug the H4n into a USB socket, the H4n powers up, but does not yet enumerate. A small UI appears on the device asking how you want the H4n to connect to the PC -- as a USB block device (for retrieving audio recordings from the SD card), or as a USB audio device. I select USB audio, select a sample rate of 48KHz, then select Connect.

After pressing Connect, the H4n fully initializes, and journalctl -f prints out the following:

Sep 01 16:27:56 exiguous kernel: usb 3-4: new high-speed USB device number 15 using xhci_hcd
Sep 01 16:27:56 exiguous kernel: usb 3-4: New USB device found, idVendor=058f, idProduct=6254, bcdDevice= 1.00
Sep 01 16:27:56 exiguous kernel: usb 3-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Sep 01 16:27:56 exiguous kernel: hub 3-4:1.0: USB hub found
Sep 01 16:27:56 exiguous kernel: hub 3-4:1.0: 4 ports detected
Sep 01 16:27:56 exiguous kernel: usb 3-4.2: new full-speed USB device number 16 using xhci_hcd
Sep 01 16:27:56 exiguous kernel: usb 3-4.2: New USB device found, idVendor=1686, idProduct=0045, bcdDevice= 0.00
Sep 01 16:27:56 exiguous kernel: usb 3-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 01 16:27:56 exiguous kernel: usb 3-4.2: Product: H4
Sep 01 16:27:56 exiguous kernel: usb 3-4.2: Manufacturer: ZOOM Corporation
Sep 01 16:27:56 exiguous mtp-probe[2543]: checking bus 3, device 16: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4.2"
Sep 01 16:27:56 exiguous mtp-probe[2543]: bus: 3, device: 16 was not an MTP device
Sep 01 16:27:56 exiguous systemd-udevd[2542]: Process '/usr/sbin/alsactl -E HOME=/run/alsa restore 4' failed with exit code 99.
Sep 01 16:27:56 exiguous rtkit-daemon[798]: Supervising 4 threads of 1 processes of 1 users.
Sep 01 16:27:56 exiguous rtkit-daemon[798]: Successfully made thread 2561 of process 1576 (n/a) owned by '1000' RT at priority 5.
Sep 01 16:27:56 exiguous rtkit-daemon[798]: Supervising 5 threads of 1 processes of 1 users.
Sep 01 16:27:56 exiguous rtkit-daemon[798]: Supervising 5 threads of 1 processes of 1 users.
Sep 01 16:27:56 exiguous rtkit-daemon[798]: Successfully made thread 2564 of process 1576 (n/a) owned by '1000' RT at priority 5.
Sep 01 16:27:56 exiguous rtkit-daemon[798]: Supervising 6 threads of 1 processes of 1 users.
Sep 01 16:28:01 exiguous pulseaudio[1576]: W: [alsa-source-USB Audio] alsa-util.c: Got POLLNVAL from ALSA
Sep 01 16:28:01 exiguous pulseaudio[1576]: W: [alsa-sink-USB Audio] alsa-util.c: Got POLLNVAL from ALSA
Sep 01 16:28:01 exiguous pulseaudio[1576]: W: [alsa-source-USB Audio] alsa-util.c: Could not recover from POLLERR|POLLNVAL|POLLHUP with snd_pcm_prepare(): No such device
Sep 01 16:28:01 exiguous pulseaudio[1576]: W: [alsa-sink-USB Audio] alsa-util.c: Could not recover from POLLERR|POLLNVAL|POLLHUP with snd_pcm_prepare(): No such device
Sep 01 16:28:01 exiguous kernel: usb 3-4.2: USB disconnect, device number 16
Sep 01 16:28:02 exiguous kernel: usb 3-4.2: new full-speed USB device number 17 using xhci_hcd
Sep 01 16:28:02 exiguous kernel: usb 3-4.2: New USB device found, idVendor=1686, idProduct=0045, bcdDevice= 0.00
Sep 01 16:28:02 exiguous kernel: usb 3-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 01 16:28:02 exiguous kernel: usb 3-4.2: Product: H4
Sep 01 16:28:02 exiguous kernel: usb 3-4.2: Manufacturer: ZOOM Corporation
Sep 01 16:28:02 exiguous mtp-probe[2589]: checking bus 3, device 17: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4.2"
Sep 01 16:28:02 exiguous mtp-probe[2589]: bus: 3, device: 17 was not an MTP device
Sep 01 16:28:02 exiguous systemd-udevd[2588]: Process '/usr/sbin/alsactl -E HOME=/run/alsa restore 4' failed with exit code 99.
Sep 01 16:28:02 exiguous rtkit-daemon[798]: Supervising 4 threads of 1 processes of 1 users.
Sep 01 16:28:02 exiguous rtkit-daemon[798]: Successfully made thread 2608 of process 1576 (n/a) owned by '1000' RT at priority 5.
Sep 01 16:28:02 exiguous rtkit-daemon[798]: Supervising 5 threads of 1 processes of 1 users.
Sep 01 16:28:02 exiguous rtkit-daemon[798]: Supervising 5 threads of 1 processes of 1 users.
Sep 01 16:28:02 exiguous rtkit-daemon[798]: Successfully made thread 2610 of process 1576 (n/a) owned by '1000' RT at priority 5.
Sep 01 16:28:02 exiguous rtkit-daemon[798]: Supervising 6 threads of 1 processes of 1 users.
Sep 01 16:29:30 exiguous rtkit-daemon[798]: Supervising 5 threads of 1 processes of 1 users.
Sep 01 16:29:30 exiguous rtkit-daemon[798]: Successfully made thread 2658 of process 1576 (n/a) owned by '1000' RT at priority 5.
Sep 01 16:29:30 exiguous rtkit-daemon[798]: Supervising 6 threads of 1 processes of 1 users.

From the above, the device appears to enumerate twice; I'm not sure why this happens (it takes about eight seconds for the H4n to fully boot up). Once it's fully booted, however, none of PCMs appear to actually work. arecord directly from the device konks out with a generic I/O error. The little live volume monitor in pavucontrol that normally appears underneath input devices is missing entirely for the H4n.

Audacity gets especially confused, as the H4n appears several times in the available inputs, showing:

• front-mic 0


• rear-mic 0


• line-mic 0


• front-mic 1


• rear-mic 1


• line-mic 1

Which seems nonsense; the H4n is strictly a stereo USB device.

I don't think Pulseaudio is the culprit because, prior to posting this, I ran the following test:

• Log out of X11 desktop.


• Switch to text console; login as root.


• Kill Pulseaudio daemon; verify it didn't respawn.


• 
  chmod -x /usr/sbin/alsactl (prevents system from re-writing possibly insane asound.state at reboot).


• Delete /var/lib/alsa/asound.state. Coupled with the above, this forces the ALSA system back to "factory defaults" at next boot.


• Reboot.


• 
  Do not login to X11. Switch to text console; login as root.


• 
  chmod +x /usr/sbin/alsactl (fix that back up).


• Confirm Pulseaudio is not running.


• Plug in H4n.

So, with "factory default" ALSA settings and Pulseaudio nowhere to be seen, the problem persists.

In case it matters, there is an Oculus Rift plugged in to the system, but is never used under Linux.

And, just to make things weirder, when I plug the very same H4n into my Thinkpad laptop (running the same kernel), it works perfectly fine. Both machines are Debian Sid ("unstable") systems.

Any and all hints appreciated.

Edit 2018.09.03:

After double-checking journalctl logs on my laptop, I find that the H4n also enumerates there twice as well, with almost identical messages. So the double-enumeration itself does not appear to be the problem.

Edit 2018.09.04:

After unplugging the Oculus Rift and the Logitech Web cam, there is slight improvement. Rather than hanging immediately, arecord manages to successfully capture about 1-2 seconds of audio, but then hangs for several seconds, reports two short reads (the first always being 96 samples long), and then the program aborts with a generic I/O error.

I tried loading the usbmon kernel module and capturing bus activity, but my USB-fu doesn't appear to be up to the task of getting terribly useful information out of the logs. It sure feels like something is getting stuck in the USB layers somewhere. I have one more possible hardware culprit to try and eliminate.

Edit 2019.04.11:

Based on a couple off-hand comments in some discussion fora suggesting that Intel's X99 chipset might be the problem (!?), I tried an experiment: Rather than plug the H4n directly in to the USB ports on the motherboard, I instead tried plugging it in to a port on an external USB hub. (The "hub" is actually a Corsair Polaris MM800 RGB mouse pad with a single "extension" port; you're intended to plug your mouse in to it).

Doing so causes the H4n to operate correctly. The strange list of inputs still appears in Audacity, but I can successfully record audio by selecting "front mic 0". Pulseaudio and OBS also handle it correctly.

I'm happy that I now have a workaround, but I can't imagine why this should work, nor why direct motherboard ports wouldn't.