The same here (logitech C270), the log shows this messages endlessly:

Dec 11 16:27:47 localhost kernel: [  850.163234] ALSA clock.c:227 2:3:4: cannot set freq 48000 to ep 0x86
Dec 11 16:27:47 localhost kernel: [  850.301479] ALSA clock.c:242 current rate 290 is different from the runtime rate 48000
Dec 11 16:27:54 localhost kernel: [  856.725148] ALSA clock.c:236 2:3:4: cannot get freq at ep 0x86
Dec 11 16:28:00 localhost kernel: [  863.262097] ALSA clock.c:236 2:3:4: cannot get freq at ep 0x86
Dec 11 16:28:07 localhost kernel: [  869.803244] ALSA clock.c:236 2:3:4: cannot get freq at ep 0x86
Dec 11 16:28:13 localhost kernel: [  876.446201] ALSA clock.c:227 2:3:4: cannot set freq 48000 to ep 0x86
Dec 11 16:28:20 localhost kernel: [  882.920137] ALSA clock.c:236 2:3:4: cannot get freq at ep 0x86
Dec 11 16:28:26 localhost kernel: [  889.501132] ALSA clock.c:236 2:3:4: cannot get freq at ep 0x86
Dec 11 16:28:33 localhost kernel: [  896.068198] ALSA clock.c:227 2:3:4: cannot set freq 48000 to ep 0x86
Dec 11 16:28:33 localhost kernel: [  896.206172] ALSA clock.c:242 current rate 290 is different from the runtime rate 48000
Dec 11 16:28:40 localhost kernel: [  902.632171] ALSA clock.c:227 2:3:4: cannot set freq 48000 to ep 0x86

More info about my configuration:

Linux localhost 3.1.0-1.2-desktop #1 SMP PREEMPT Thu Nov 3 14:45:45 UTC 2011 (187dde0) i686 athlon i386 GNU/Linux

Bus 001 Device 002: ID 046d:0825 Logitech, Inc. Webcam C270

I should have added: this is a regression, the same webcam worked fine under 11.4.

I have recompiled 3.1.0-1.2-desktop with this patch and now the webcam works again. I hope this simple solution finds its way into the next 12.1 kernel release.

I'm having the same problem. Temporarily, I can fix this with turning off/on the webcam mic in pulse volume control. (Switch profile to "Off")

I'm hoping the permanent fix is implemented soon.

Same here on Logitech C200 webcam. 
Is a bit intermittent, tends to work ok if you do a video test first on the camera, ie Skype options video test video, then if you leave it again come back later it goes back to playing back at high speed. 
Sort of ties in with the "many webcams suffer from a race condition that may crash them upon resume" comment in the link above (Here is the patch: http://article.gmane.org/gmane.linux.usb.general/52027)

This is not restricted to openSUSE, I have seen other forum where the same issue has been raised, some fixed with a patch to the kernel, others not.

For all of you, there is a fast workaround. Install the latest stable kernel from here:

https://build.opensuse.org/project/show?project=Kernel%3Astable

currently It is 3.1.5-1-desktop

OS 12.1 Kernel Update

http://forums.opensuse.org/forums/english/other-forums/community-fun/general-chit-chat/471837-os-12-1-kernel-update.html

After an update it is resolved.

(In reply to Slobodan Kalenic from comment #7)
> OS 12.1 Kernel Update
> 
> http://forums.opensuse.org/forums/english/other-forums/community-fun/general-
> chit-chat/471837-os-12-1-kernel-update.html
> 
> After an update it is resolved.

The problem seems to have recurred -- see <https://bugzilla.kernel.org/show_bug.cgi?id=35922>.  I'm getting "chipmunk" audio with a Logitech C270 webcam with kernel-default-4.13.12-1.1.x86_64 on openSUSE Tumbleweed.  Should I open a new bug for the openSUSE Tumbleweed project or just reopen this one and change the product?

Reopen If you ask me

In the absence of any further replies, I am boldly reopening and reassigning this bug to Tumbleweed.

Could you attach the lsusb output?

Created attachment 759975 [details]
Output of lsusb -v

(In reply to Tristan Miller from comment #12)
> Created attachment 759975 [details]
> Output of lsusb -v

Oliver, these devices should all have RESET_RESUME quirk. Any idea why the issue recurred on this device?

The original patches have been superseeded in:

commit e387ef5c47ddeaeaa3cbdc54424cdb7a28dae2c0
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Thu Jul 19 12:39:14 2012 +0200

    usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams

Created attachment 761727 [details]
switch the quirk on explicitely

That is a testable hypothesis. Try this test patch.

Closing due to lack of response.

(In reply to Jiri Slaby from comment #16)
> Closing due to lack of response.

There was no response to the NEEDINFO request from the reporter, but I was also experiencing the problem.  I might be able to test the patch if someone can provide me with or point me to further instructions.  For instance, what package is the patch for -- kernel-default?  Can I just fork kernel-default on OBS, apply the patch, compile the kernel, and install the resulting RPM with zypper?

(In reply to Tristan Miller from comment #17)
> Can I just fork kernel-default
> on OBS, apply the patch, compile the kernel, and install the resulting RPM
> with zypper?

Yes, I did it in:
https://build.opensuse.org/project/monitor/home:jirislaby:bnc736093

I've been on holiday or business trips recently (and still am) but will do some testing in a week or two after I get back.  (I don't have the webcam with me and so can't do it right now.)

I am no longer able to reproduce the problem using kernel-default-4.17.3-1.7.x86_64 (that is, the official kernel, not the one in home:jirislaby).  Audio recorded in guvcview sounds normal.  Unless the reporter is still around and is still experiencing the problem, perhaps this bug can be closed.

ok, thanks.

I'm experiencing this problem again with kernel-default-5.13.0-1.2.x86_64 on openSUSE Tumbleweed.  (Possibly the problem never really went away, though it's difficult to reproduce as it happens randomly and rarely.)

Is there a more recent patch I can test?  (And does anyone know how I can reliably reproduce the problem?)

This fell through the cracks, reassigning to the proper kernel-bugs.

Tristan, it has been a while. Is it still broken with the latest TW kernel?

(In reply to Miroslav Beneš from comment #23)
> This fell through the cracks, reassigning to the proper kernel-bugs.
> 
> Tristan, it has been a while. Is it still broken with the latest TW kernel?


I haven't been at the office, where my webcam is, for a couple months, but will try again once I return next week.  Note that the problem is hard to reproduce, since it happens quite randomly and only occasionally, so it may be a while before I can get back to you with a specific kernel version number.

Miroslav, I can confirm that the bug is reproducible with kernel-default-5.16.0-1.1.x86_64 on Tumbleweed.

Oliver, any idea here? See especially comments 20 and 22.

Sorry for the delays, but does this still happen?

Yes, it absolutely does.

Please test this with
usbcore.autosuspend=-1
on the kernel command line.

I will do so.  Since the bug is not reliably reproducible, it may be a few months before I report back.

Well, it's been almost six months and I haven't yet encountered the bug with usbcore.autosuspend=-1.  Hopefully that means that that workaround works.

(In reply to Tristan Miller from comment #31)
> Well, it's been almost six months and I haven't yet encountered the bug with
> usbcore.autosuspend=-1.  Hopefully that means that that workaround works.

Yes, but it should not be necessary. The relevant patch has gone into v5.2

I hope you have another model, but as we have already reopened, please attach the output of "lsusb -v" with your problematic device attached.

(In reply to Oliver Neukum from comment #32)
> (In reply to Tristan Miller from comment #31)
> > Well, it's been almost six months and I haven't yet encountered the bug with
> > usbcore.autosuspend=-1.  Hopefully that means that that workaround works.
> 
> Yes, but it should not be necessary. The relevant patch has gone into v5.2
> 
> I hope you have another model, but as we have already reopened, please
> attach the output of "lsusb -v" with your problematic device attached.

I already did this in Comment 12; see Attachment 759975 [details].  If you're expecting different output this time around, please confirm and I'll run the command again.

(In reply to Oliver Neukum from comment #32)
> (In reply to Tristan Miller from comment #31)
> > Well, it's been almost six months and I haven't yet encountered the bug with
> > usbcore.autosuspend=-1.  Hopefully that means that that workaround works.
> 
> Yes, but it should not be necessary. The relevant patch has gone into v5.2

Oh, and with respect to this comment: I already confirmed in Comment 25 that the problem happens with 5.16.0, so whatever patch got applied in 5.2 obviously didn't solve the issue.  The machine in question is now running 6.3.7 and will soon be updated to 6.4.4.

The problem is that the patch and the work around do the same thing.
So I need to be sure. After this time and with so many different bug reporters it gets very hard to connect all the different status reports and USB ids.

So please confirm that your device has

idVendor           0x046d Logitech, Inc.
idProduct          0x0825 Webcam C270

fails with a 6.3.7 kernel
and works with a 6.3.7 kernel and the usbcore.autosuspend=-1 work around

(In reply to Oliver Neukum from comment #35)
> The problem is that the patch and the work around do the same thing.
> So I need to be sure. After this time and with so many different bug
> reporters it gets very hard to connect all the different status reports and
> USB ids.
> 
> So please confirm that your device has
> 
> idVendor           0x046d Logitech, Inc.
> idProduct          0x0825 Webcam C270


I can confirm this.

> fails with a 6.3.7 kernel
> and works with a 6.3.7 kernel and the usbcore.autosuspend=-1 work around


If you need results specifically for 6.3.7, I won't be able to confirm either of these.  I'm running Tumbleweed and regularly update the system; the problem with the audio occurs far less frequently than Tumbleweed updates its kernel.  All I can tell you is that the problem was occurring as far back as 4.13.12 and as recently as 5.16.0.  Since adding the usbcore.autosuspend=-1 parameter with 5.16.0 about six months ago, I haven't encountered the problem, but in that time the kernel has gone through various upgrades culminating in 6.3.7, all with that boot parameter still in place.  I can remove that boot parameter now and let you know if I encounter the problem in the next few months, but the kernel will almost certainly get updated several more times.

(In reply to Tristan Miller from comment #36)

> If you need results specifically for 6.3.7, I won't be able to confirm

Any result will do, provided I get limits for the kernel versions affected. That is are they v5.3 or younger.

> usbcore.autosuspend=-1 parameter with 5.16.0 about six months ago, I haven't
> encountered the problem, but in that time the kernel has gone through
> various upgrades culminating in 6.3.7, all with that boot parameter still in
> place.  I can remove that boot parameter now and let you know if I encounter
> the problem in the next few months, but the kernel will almost certainly get
> updated several more times.

But you can confirm that v5.16 was affected if you did not use the work around?

(In reply to Oliver Neukum from comment #37)
> But you can confirm that v5.16 was affected if you did not use the work
> around?


Yes, that's exactly what I just wrote in my previous comment, and also in Comment 25.

I can now confirm that the problem is still reproducible with 6.4.4 (without the usbcore.autosuspend=-1 parameter).

Thank you, that does the job.

Created attachment 868618 [details]
debug printk

I've taken this upstream and the conclusion was that the results ought to be impossible and something fundamental is broken. So could you test thw patch I attached in the preceeding comment, so that we can be sure quirks are correctly detected?