Bug 98481 - Microsoft LifeCam Studio fails to work when microphone enabled
Summary: Microsoft LifeCam Studio fails to work when microphone enabled
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
Depends on:
Reported: 2015-05-17 09:10 UTC by Dainius Masiliūnas
Modified: 2015-06-02 14:43 UTC (History)
3 users (show)

See Also:
Kernel Version: 4.0
Tree: Mainline
Regression: No

lsusb output (62.00 KB, text/plain)
2015-05-17 09:54 UTC, Dainius Masiliūnas
Kernel log (170.00 KB, text/plain)
2015-05-17 10:05 UTC, Dainius Masiliūnas
ALSA info (35.54 KB, text/plain)
2015-05-17 15:46 UTC, Dainius Masiliūnas
Second kernel log (151.64 KB, text/plain)
2015-05-17 16:04 UTC, Dainius Masiliūnas
ALSA info without usbtv (34.95 KB, text/plain)
2015-05-17 18:30 UTC, Dainius Masiliūnas
Third kernel log (150.64 KB, text/plain)
2015-05-17 18:59 UTC, Dainius Masiliūnas
Fix patch (1022 bytes, patch)
2015-05-19 08:49 UTC, Takashi Iwai
Details | Diff

Description Dainius Masiliūnas 2015-05-17 09:10:44 UTC
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:
(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.
Comment 1 Dainius Masiliūnas 2015-05-17 09:54:58 UTC
Created attachment 177111 [details]
lsusb output

Attached the output of lsusb -vvvv for this webcam. It reports two frequencies, 48k and 96k.
Comment 2 Dainius Masiliūnas 2015-05-17 10:05:55 UTC
Created attachment 177121 [details]
Kernel log

Attached the full journal entry for the boot when I had snd_usb_audio left enabled.
Comment 3 Raymond 2015-05-17 13:08:04 UTC
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
Comment 4 Dainius Masiliūnas 2015-05-17 13:37:04 UTC
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
Comment 5 Raymond 2015-05-17 14:46:05 UTC
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
Comment 6 Raymond 2015-05-17 14:51:11 UTC
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
Comment 7 Dainius Masiliūnas 2015-05-17 15:46:42 UTC
Created attachment 177131 [details]
ALSA info
Comment 8 Dainius Masiliūnas 2015-05-17 16:04:01 UTC
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).
Comment 9 Raymond 2015-05-17 16:49:35 UTC
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


chmap -Dhw:CARD=usbtv -s capture query

chmap -Dhw:CARD=StudioTM -s capture query

chmap -Dhw:CARD=PCH -s capture query
Comment 10 Dainius Masiliūnas 2015-05-17 18:30:35 UTC
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.
Comment 11 Dainius Masiliūnas 2015-05-17 18:59:29 UTC
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.
Comment 13 Dainius Masiliūnas 2015-05-18 14:52:52 UTC
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.
Comment 14 Dainius Masiliūnas 2015-05-19 07:56:09 UTC
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.
Comment 15 Takashi Iwai 2015-05-19 08:48:44 UTC
OK, I'm going to queue the patch below.  Please let me know if anything is wrong with it.  Thanks.
Comment 16 Takashi Iwai 2015-05-19 08:49:06 UTC
Created attachment 177341 [details]
Fix patch
Comment 17 Dainius Masiliūnas 2015-05-19 08:51:03 UTC
Yes, this is correct and exactly what I applied to my testing kernel.
Comment 18 Vittorio Gambaletta (VittGam) 2015-05-22 19:25:28 UTC

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:


Comment 19 Takashi Iwai 2015-06-02 14:43:49 UTC
The fix was queued.  Let's close.

Note You need to log in before you can comment on or make changes to this bug.