When the integrated microphone on the Microsoft LifeCam Studio is enabled and both are attempted to be used at the same time, the webcam itself fails to start. Blacklisting snd_usb_audio forces the microphone to be off and thus allows the webcam to work, but obviously that means the microphone is useless and no other USB microphones can be used. When both are enabled, the log outputs messages such as: cannot get freq at ep 0x82 ALSA lib pcm_dsnoop.c:614:(snd_pcm_dsnoop_open) unable to open slave uvcvideo: Failed to query (GET_DEF) UVC control 2 on unit 4: -32 (exp. 2). uvcvideo: Failed to query (GET_DEF) UVC control 2 on unit 4: 0 (exp. 2). ALSA lib pcm.c:7980:(snd_pcm_set_params) Channels count (1) not available for CAPTURE: Incorrect argument ALSA lib pcm.c:7956:(snd_pcm_set_params) Broken configuration for CAPTURE: no configurations available ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map uvcvideo: Failed to set UVC probe control : -32 (exp. 26). This issue might be related to bug #95961 as well. It has also been discussed in other bug trackers, but without a solution, see: https://bugs.launchpad.net/ubuntu/+source/guvcview/+bug/1033146 https://sourceforge.net/p/linux-uvc/mailman/message/29645043/ (It is not a Flash bug, because in my case I'm not running Flash at all.) As per http://www.ideasonboard.org/uvc/#footnote-13 I am already using the FIX_BANDWIDTH quirk, but enabling it does not affect this issue. I'm running the latest mainline kernel (kernel-ml from elrepo) on CentOS 7.1.
Created attachment 177111 [details] lsusb output Attached the output of lsusb -vvvv for this webcam. It reports two frequencies, 48k and 96k.
Created attachment 177121 [details] Kernel log Attached the full journal entry for the boot when I had snd_usb_audio left enabled.
any reason to use dsnoop instead of hw device ? Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 3 bDelay 1 frames wFormatTag 1 PCM AudioStreaming Interface Descriptor: bLength 14 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 1 bSubframeSize 2 bBitResolution 16 bSamFreqType 2 Discrete tSamFreq[ 0] 48000 tSamFreq[ 1] 96000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0100 1x 256 bytes bInterval 4 bRefresh 0 bSynchAddress 0
I'm testing this on WebRTC through Mozilla Firefox. This is the relevant portion of its code, I believe: http://mxr.mozilla.org/mozilla-esr31/source/media/webrtc/trunk/webrtc/modules/audio_device/linux/audio_device_alsa_linux.cc#1842
can you record with arecord -Dhw:0 -f S16_LE -c 1 -r48000 test.wav arecord -Dhw:0 -f S16_LE -c 1 -r48000 -period_time=10000 -buffer-time=40000 test.wav
you have to post output of alsa-info.sh ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map it is not clear which device use route
Created attachment 177131 [details] ALSA info
Created attachment 177141 [details] Second kernel log I tried running those commands, and the results are quite interesting. In all cases it records the audio fine, but the video stream (tested through qv4l2) behaves differently depending on when the audio recording was started: 1) If the video recording started before the audio recording, then when the audio recording is stopped the video recording freezes. I believe it's at this point that the logs output "Set Capture Format: Input/Output error". 2) If the video recording started after the audio recording, the video recording is corrupted; it looks and behaves very much like a vertically stretched OpenGL texture (like the top left corner of this image: http://romain.vergne.free.fr/teaching/IS/imgs05/texture-mode03.jpg ) This only happens when recording the audio and video off the same webcam. When the audio is being recorded from another device, the video stream is always good and doesn't stop prematurely. I also did some more testing on Firefox: when both the webcam and its microphone are allowed to be used, then only the audio gets through, no video; when only the webcam is allowed to be used, then it shows the video correctly; when the webcam is allowed to be used, and a sound source other than the webcam microphone is selected, again only the audio gets through. I attached the kernel log of this session. Looks like the ALSA lib warnings don't happen every time, because there are none in the log this time. They are probably from an unrelated issue (sometimes Firefox gives me a lot of duplicate choices instead of one choice per device, and I think the ALSA lib warnings appear then).
card 2: usbtv [usbtv], device 0: USBTV Audio [USBTV Audio Input] Subdevices: 1/1 Subdevice #0: subdevice #0 seem your usbtv does not has chmap http://git.alsa-project.org/?p=alsa-lib.git;a=blob_plain;f=test/chmap.c;hb=HEAD chmap -Dhw:CARD=usbtv -s capture query chmap -Dhw:CARD=StudioTM -s capture query chmap -Dhw:CARD=PCH -s capture query
Created attachment 177151 [details] ALSA info without usbtv Well, even though usbtv is a USB sound device, it has no bearing on the issue at hand. Just to be certain, I unplugged it and retested, and the results are exactly the same. Here's the ALSA log without usbtv attached.
Created attachment 177161 [details] Third kernel log And here's the kernel log from the third session, so usbtv wouldn't be distracting. I also paid special mind to the timestamps, and there's something interesting there. At 20:54:50-20:55:00 is a 10-second freeze after login, when the mouse is active but nothing reacts to it. Looks like it's related to the webcam as it doesn't seem to happen without it, and thus related to bug #95961 (it's true that during it, as in that bug, the webcam LED blinks before turning off; in my case I use GDM autologin so it doesn't freeze at the login screen, but shortly after logging in). At 21:11:07 and 21:11:53 were my tests of what happens when I record video first and the audio afterwards. Looks like the only message output then is the "cannot get freq at ep 0x82". At 21:12:17 and 21:13:08 were my tests of what happens when I record the audio first (this is what results in video stream corruption). In that case three messages are logged: cannot get freq at ep 0x82 uvcvideo: Failed to set UVC probe control : -32 (exp. 26). Set Capture Format: Input/Output error The last one is from Xsession-errors, so it's probably coming from qv4l2. At 21:14:14-21:14:19 was my test in Firefox, where I started WebRTC and selected to allow both the webcam and its microphone, and when it failed I quit the browser. Here the messages are two sets of: cannot get freq at ep 0x82 QDBusConnection for control created "/Mixers/PulseAudio__Capture_Streams_1/stream_0" At 21:14:54-21:15:02 I repeated the same test, but after the first failure to turn on the webcam, I told Firefox to retry (which results in only the audio going through). Here we have the same thing as above, though there are two sets of the QDBusConnection message and one of "uvcvideo: Failed to set UVC probe control : -32 (exp. 26)." This is consistent with my previous test at 21:12:17. Looks like Firefox in this case detects that the webcam is showing a corrupt picture and thus refuses to continue.
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/log/sound/usb?qt=grep&q=lifecam
Yes, that might help with this issue. I'll try and compile a kernel with that patch adapted to the LifeCam Studio's USB ID and report back whether it helped.
All right, I tested a kernel with that patch applied and adjusted for the Studio's PCI ID, and it works! In all scenarios the webcam now works as expected. So all along this issue was pretty much a duplicate of bug #95961 :) So please add the PCI ID of 045e:0772 to the quirk list and this will be solved. Though it also makes me wonder, could that quirk be made accessible as a module option? That way any other devices with the same issue could be tested easier, without the need to recompile.
OK, I'm going to queue the patch below. Please let me know if anything is wrong with it. Thanks.
Created attachment 177341 [details] Fix patch
Yes, this is correct and exactly what I applied to my testing kernel.
Hi, The LifeCam HD-3000 has the same problem. I've submitted a patch to add its USB ID to the relevant mailing lists and recipients: http://thread.gmane.org/gmane.linux.kernel.stable/136999 Cheers, Vittorio
The fix was queued. Let's close.