I'm trying to get FFMPEG to pull both audio from my webcam. It works fantastically, when it does, but is intermittent. I am using the following command:

ffmpeg -report -y -f alsa -channels 1 -ar 16000 -i hw:2,0 outputA.wav

I have narrowed the issue down to FFMPEG being unable to sometimes open the microphone. The report looks fine until it hangs here:

Successfully parsed a group of options. Opening an input file: hw:2,0.

Then I have to ctrl-c twice to get back to the command line.

Before running ffmpeg, the output of arecord -l yields:

**** List of CAPTURE Hardware Devices **** card 2: U0x46d0x807 [USB Device 0x46d:0x807], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0

...but during the running of ffmpeg it shows, ... Subdevices: 0/1 ..., implying that the device is unavailable (as ffmpeg should be using it)... but it reads this way whether or not it successfully begins the recording.

I can force it to hang more often by playing a music file in omxplayer, but it doesn't require this to hang. As you might suspect, sound output on a completely separate device should not affect input on another device, so this particular trigger yields many ?!?!?!'s.

I'm a bit of a noob. Any help would be appreciated.

1 Answer 1


After some digging, I found a solution. I noticed that I could start FFMPEG, wait a moment, kill the process when it was hanging, then immediately start it again with success--indicating a delay of some kind. I started looking into USB suspend settings, because that's where I'd start on a windows-based machine. It turns out, that it wasn't interactions with the sound driver, but rather, my suspicions were correct. The interaction with omxplayer is unknown--perhaps just some fluke of audio-driver-polling.

Some links that were very helpful in my search:

I opened a console and navigated into the usb device directory /sys/bus/usb/devices/, and (after identifying my device) manually edited some power settings. While the changes seemed logical, they did not immediately fix the problem, nor persist beyond reboot. The modprobe method did not work, so manually editing the boot parameters was discovered and pursued. I ultimately corrected the issue by disabling USB suspend via the kernel boot arguments at /boot/cmdline.text , adding usbcore.autosuspend=-1, unplugging the device, rebooting, then plugging it back in.

Now FFMPEG doesn't even flinch. It consistently records the audio stream without any hesitation. It appears that FFMPEG was indeed hooking into the device via the drivers, but the device wasn't ready because its power was suspended. The resulting mismatch silently disagreed with FFMPEG's device opening process, unable to spit out any usable debug data.

Given that this is a boot/kernel-level change, I suspect I will not run into this particular problem again. Thanks for looking and I hope this helps someone else with an identical or similar problem!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.