ALSA: Zoom H4n não funciona como fonte de áudio USB no PC

Question

Era uma vez, eu tive que conectar meu gravador de campo Zoom H4n no meu PC principal e fazer com que ele aparecesse como outra fonte de áudio dentro do Audacity para gravação ao vivo. Funcionou muito bem. Em algum momento nos últimos meses, no entanto, isso parou de funcionar. O H4n "aparece" ( alsamixer o vê), mas os PCMs não funcionam.

Quando você conecta o H4n a um soquete USB, o H4n é ligado, mas ainda não é enumerado. Uma pequena interface do usuário aparece no dispositivo perguntando como você deseja que o H4n se conecte ao PC - como um dispositivo de bloco USB (para recuperar gravações de áudio do cartão SD) ou como um dispositivo de áudio USB. Selecione áudio USB, selecione uma taxa de amostragem de 48 KHz e, em seguida, selecione Conectar.

Após pressionar Connect, o H4n é totalmente inicializado e journalctl -f imprime o seguinte:

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.

Do acima, o dispositivo parece enumerar duas vezes; Não sei por que isso acontece (leva cerca de oito segundos para o H4n inicializar completamente). Uma vez totalmente inicializado, no entanto, nenhum PCM parece funcionar. arecord diretamente do dispositivo é excluído com um erro genérico de E / S. O pequeno monitor de volume ao vivo em pavucontrol que normalmente aparece embaixo dos dispositivos de entrada está ausente para o H4n.

O Audacity fica especialmente confuso, pois o H4n aparece várias vezes nas entradas disponíveis, mostrando:

• front-mic 0
• microfone traseiro 0
• line-mic 0
• front-mic 1
• microfone traseiro 1
• line-mic 1

O que parece um absurdo; o H4n é estritamente um dispositivo USB estéreo.

Eu não acho que o Pulseaudio é o culpado porque, antes de postar isso, fiz o seguinte teste:

• Efetue logout da área de trabalho do X11.
• Alterne para o console de texto; faça o login como root.
• Mate o daemon Pulseaudio; verifique se não reapareceu.
• chmod -x /usr/sbin/alsactl (impede que o sistema reescreva possivelmente insano asound.state na reinicialização).
• Excluir /var/lib/alsa/asound.state . Juntamente com o acima, isso força o sistema ALSA de volta aos "padrões de fábrica" na próxima inicialização.
• Reinicialize.
• Não faça login no X11. Alterne para o console de texto; faça o login como root.
• chmod +x /usr/sbin/alsactl (corrija esse backup).
• Confirme se o Pulseaudio não está em execução.
• Ligue o H4n.

Portanto, com as configurações de "padrão de fábrica" do ALSA e o Pulseaudio longe de ser visto, o problema persiste.

Caso seja importante, há um Oculus Rift conectado ao sistema, mas nunca é usado no Linux.

E, só para tornar as coisas mais estranhas, quando eu conecto o mesmo H4n no meu laptop Thinkpad (rodando o mesmo kernel), ele funciona perfeitamente. Ambas as máquinas são sistemas Debian Sid ("unstable").

Todas e quaisquer sugestões são apreciadas.

Editar 2018.09.03:

Após verificar novamente os journalctl logs no meu laptop, descubro que o H4n também enumera lá duas vezes, com mensagens quase idênticas. Portanto, a dupla enumeração em si não parece ser o problema.

Editar 2018.09.04:

Depois de desconectar o Oculus Rift e a webcam da Logitech, há uma melhora ligeira . Em vez de ser interrompido imediatamente, arecord consegue capturar com sucesso cerca de 1-2 segundos de áudio, mas depois trava por vários segundos, relata duas leituras curtas (a primeira sempre tem 96 amostras) e então o programa é abortado / O erro.

Eu tentei carregar o módulo do kernel usbmon e capturar a atividade do barramento, mas meu USB-fu não parece estar pronto para a tarefa de obter informações terrivelmente úteis dos logs. Com certeza parece que algo está ficando preso nas camadas USB em algum lugar. Eu tenho mais um possível culpado de hardware para tentar eliminar.