Was wondering if anyone has had trouble connecting external microphone inputs to Intel NUC devices running Resin OS. I have plugged in a USB microphone that an application instantiated on a Chrome browser through the startup script will use for speech input. When I run arecord --list-devices
in the main terminal, the microphone does not show up. However, when I run lsusb
, I can see that the USB mic has been successfully plugged in (device shows up as Texas Instruments).
The exact model of our device is a Gigabyte Mini-PC GB-BXi5-4200, which is similar enough to a Intel NUC that we can use a Resin OS image generated from that.
Any help would be great! Thanks!
Hi @mandicai,
Have you tried any other microphones or any other way of accessing the audio device? I’m wondering if it’s something specific to that mic type that is causing it to not be recognized by ALSA.
I know we’ve done some samples with USB microphones in the past, e.g. https://github.com/resin-io-playground/applause-o-meter. So it might be worth kicking around a few other samples like that.
Finally, you might want to log into the host OS and look at the udev logs. You can first enable more verbose logging with udevadm control --log-priority=info
after which you can run udevadm monitor --environment
. That will show kernel level events when connecting or disconnecting the USB microphone which can help tell if it’s being properly detected as an audio device.
Hey @mccollam!
Thank you so much for your response! We’ve managed to get some more information by downloading Pulseaudio (apt-get install pulseaudio
), starting Pulseaudio with pulseaudio -D --system
, and pactl info
to see information about the pulseaudio server, default sink, default source, etc. and pactl list
to see sound modules, source devices, sink devices, etc.
Something odd that we had to do was adduser root pulse-access
in order for pactl
to list information; otherwise, it said Connection failure: access denied.
It looks like the SINK and SOURCE devices were idle, and then suspended (based on the states that pactl list
printed out). When we ran parecord -d <devicename> test.wav
(which sets a device to record from and stores the audio in the test.wav file), we were able to get their states back to RUNNING atleast.
We are still having issues with getting Chrome and Firefox to recognize microphone inputs in the browser, however.
Update, the test.wav
file that was generated by parecord -d <devicename> test.wav
doesn’t have any sound, so it doesn’t look like any audio was captured by Pulseaudio.
Hi @mandicai,
Have you been able to try this out with another USB microphone or similar? I ask because I’ve been trying to reproduce this here but so far all of my USB audio devices work properly. E.g.
root@f07e799:/# arecord --list-devices
**** List of CAPTURE Hardware Devices ****
card 1: USB [Jabra SPEAK 410 USB], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
root@f07e799:/#
when I plug in my Jabra microphone. I wonder if there is potentially something different about the USB audio device you are using that might be causing issues.