Bug 98481

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.