Red Hat Bugzilla – Bug 991234
Audio hangs randomly with USB audio errors
Last modified: 2013-10-08 12:34:00 EDT
+++ This bug was initially created as a clone of Bug #663583 +++
+++ This bug was initially created as a clone of Bug #583168 +++
Original bug was closed due to EOL. Bug is still present in FC14. Sometimes when system starts up the system is very slow. Taking a look at the /var/log/messages file shows a large number of entries of the form:
Dec 16 10:31:57 kernel: [ 2711.698066] ALSA sound/usb/clock.c:233: 3:3:3: cannot set freq 16000 to ep 0x86
And a bit less but also frequently:
Dec 16 10:38:13 pulseaudio: module-alsa-card.c: Failed to find a working profile.
Dec 16 10:38:13 pulseaudio: module.c: Failed to load module "module-alsa-card" (argument: "device_id="0" name="usb-046d_08c9_56B751A2-02-U0x46d0x8c9" card_name="alsa_card.usb-046d_08c9_56B751A2-02-U0x46d0x8c9" tsched=yes ignore_dB=no card_properties="module-udev-detect.discovered=1""): initialization failed.
Login in is also very slow since it is unable to play the required sounds when selecting a username to use for login; this is the first indicator of this bug when using the system.
--- Additional comment from Kyle McMartin on 2010-12-17 11:31:59 EST ---
What kind of USB sound device?
--- Additional comment from Joël Wijngaarde on 2010-12-18 08:48:53 EST ---
Two USB sound devices:
- Logitech USB Headset / A-0356A (with mic)
- Logitech QuickCam (with mic)
Bus 001 Device 005: ID 046d:0a01 Logitech, Inc. USB Headset
Bus 001 Device 003: ID 046d:08c9 Logitech, Inc. QuickCam Ultra Vision
--- Additional comment from Sergei LITVINENKO on 2011-01-17 01:27:02 EST ---
I have problem with mic on Logitech 9000 (on 2 PC).
To avoid it, I have disabled snd-usb-audio.ko module.
--- Additional comment from Chuck Ebbert on 2011-01-19 08:09:24 EST ---
This problem appears to be widespread and is triggered somehow by pulseaudio. One workaround is to remove the snd-usb-audio module, wait a few seconds, and then load it again.
--- Additional comment from Mohammed Arafa on 2011-04-26 21:04:53 EDT ---
suddenly, i am meeting this bug. it has appeared at least 5 times today. the system is now stable.
these are my usb devices:
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 046d:c05a Logitech, Inc. Optical Mouse M90
Bus 003 Device 002: ID 046d:c31c Logitech, Inc.
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 07d1:3c03 D-Link System AirPlus G DWL-G122 Wireless Adapter(rev.C1) [Ralink RT73]
Bus 001 Device 004: ID 046d:0825 Logitech, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
and this is a sample from /var/log/messages:
kernel: [ 4497.987096] ALSA sound/usb/clock.c:233: 4:3:4: cannot set freq 48000 to ep 0x86
the only thing i think of other than auto yum updates everyday is that i updated/installed the latest version of skype on april 22
also, out of character is when i log in to a particular user on this system kde tells me that :
audio device playback HDA intel (ALC662 rev1 Analog) does not work
--- Additional comment from Mohammed Arafa on 2011-05-22 23:10:04 EDT ---
i am testing this:
the contents of /etc/modprobe.d/snd-usb-audio.conf :
alias snd-usb-audio off
--- Additional comment from Pavel Ondračka on 2011-05-25 15:43:32 EDT ---
I'm also affected with F15.
--- Additional comment from Francis Shim on 2011-06-14 11:27:59 EDT ---
I would like to emphasize that this problem is intermittent; however, I am noticing an increased frequency whenever I have 2 devices that have sound capabilities, in particular microphone sound devices. Similar to Joël Wijngaarde's (original bug reporter) report I am seeing in the syslog messages the following:
Jun 14 10:13:02 mobile-pc pulseaudio: module.c: Failed to load module "mo
dule-alsa-card" (argument: "device_id="0" name="usb-046d_0991_0E39ACE1-02-U0x46d
0x991" card_name="alsa_card.usb-046d_0991_0E39ACE1-02-U0x46d0x991" tsched=yes ig
nore_dB=no card_properties="module-udev-detect.discovered=1""): initialization f
Jun 14 10:13:03 mobile-pc kernel: [ 1529.584231] ALSA sound/usb/clock.c:233: 2:3
:1: cannot set freq 16000 to ep 0x86
Jun 14 10:13:04 mobile-pc kernel: [ 1530.584149] ALSA sound/usb/clock.c:233: 2:3
:1: cannot set freq 16000 to ep 0x86
Jun 14 10:13:05 mobile-pc kernel: [ 1531.584183] ALSA sound/usb/clock.c:233: 2:3
:1: cannot set freq 16000 to ep 0x86
The "sound/usb/clock.c:233" report line repeats several times (> 15 times) and the overall system response time noticeably slows to a grind. The frequency of this intermittent bug occurence appears to be more often when I have more than one audio input device connected:
Bus 001 Device 002: ID 046d:0991 Logitech, Inc. QuickCam Pro for Notebooks
and my native mobo audio device (from "lshw")
pci@0000:00:1b.0 N10/ICH 7 Family High Definition Audio Controller [8086:27D8]
I am observing this bug on a "Lenovo Thinkpad T60p" using the following:
GNU/Linux Distribution: Fedora 14
Kernel: 184.108.40.206-92.fc14.i686.PAE #1 SMP
--- Additional comment from ult on 2011-07-02 17:05:17 EDT ---
Confirming the bug. Reproducible every suspend/resume cycle.
My case is :
Logitech C310 webcam
Bus 002 Device 006: ID 046d:081b Logitech, Inc.
#tail -f /var/log/messages
kernel: [13358.103143] ALSA clock.c:218: 7:3:2: cannot set freq 24000 to ep 0x86
kernel: [13358.240523] ALSA clock.c:233: current rate 290 is different from the runtime rate 32000
Latest F14 stock kernel, pulseaudio from repo.
Mic works ok until first suspend, after which no recording is possible. Plug out/in fixes the problem.
Since i have to use custom 2.6.39-rc1+ kernel, i tried it with latest ALSA from git (needs to compile /usr/src/kernels/`uname -r`/linux/include/smp_lock.h, which has been removed, i took it from 13-92.fc14 src), and it triggers new behavior :
1.Recording seemingly possible, but recording indicator is inactive (in pavucontrol it's seen only if "All Streams" is chosen but still inactive) or "stream empty" when trying to playback.
2.Recording, but probably with wrong frequency, so playback of recorded sound is pitchshifted and speeded up.
Plug-out/plug-in fixes the problem unreliably. Worst of all even if it does - only before first wakeup from suspend. Then disconnect-reconnect doesn't help anymore.
A dirty workaround prooved to be functional - modules, alsa and pulseaudio have to be stopped and restarted in particular order :
Create executable script 20snd in /usr/lib/pm-utils/sleep.d/
#I'm logged in as root, so it may require adaptation.
case "$1" in
#skype hangs on resume if everything sound-related was restarted
modprobe -r snd_usb_audio
#kmods u've to reload. my specific are xfi,via. determine your with lsmod.
modprobe -v snd_hda_codec_via
modprobe -v snd_hda_intel
modprobe -v snd_ctxfi
modprobe -v snd snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep ctxfi snd_seq snd_seq_device snd_pcm snd_timer
modprobe -v snd_usb_audio
# /etc/init.d/alsasound start #probably unnecessary
#substitute root with your username
su -c - root "gmixer -d" &disown
su -c - root "skype" & disown
*) exit $NA
This fixes it for me.
--- Additional comment from ult on 2011-07-03 05:00:34 EDT ---
(In reply to comment #9)
> Since i have to use custom 2.6.39-rc1+ kernel, i tried it with latest ALSA from
> git, and it triggers new
> behavior :
Forgot to add :
I was unable to defeat this behavior, so i reverted to last stable alsa-driver.
> Upon coldboot:
> 1.Recording seemingly possible, but recording indicator is inactive (in
> pavucontrol it's seen only if "All Streams" is chosen but still inactive) or
> "stream empty" when trying to playback.
> 2.Recording, but probably with wrong frequency, so playback of recorded sound
> is pitchshifted and speeded up.
Symptom 1 pertains to both both kernels after resume, symptom 2 only to 39-rc1+ with alsa from git.
With latest Fedora's kernel it's indeed enough to disconnect/reconnect the cam to make it work.
> A dirty workaround
Script is tested in this config :
kernel 220.127.116.11-92.fc14.i686 + alsa-driver 1.0.24
kerenel 2.6.39-rc1+ + alsa-driver 1.0.24
--- Additional comment from Steven Seed on 2011-11-17 23:31:08 EST ---
Also seeing this on RHEL 6.1 2.6.32-131.6.1.el6.x86_64 with a Logitech, Inc. Webcam Pro 9000.
Bus 001 Device 102: ID 046d:0809 Logitech, Inc. Webcam Pro 9000
Nov 17 20:02:56 godzilla kernel: 87:3:4: cannot set freq 48000 to ep 0x86
Nov 17 20:02:57 godzilla kernel: 87:3:4: cannot set freq 48000 to ep 0x86
Nov 17 20:02:58 godzilla kernel: 87:3:4: cannot set freq 48000 to ep 0x86
Nov 17 20:02:59 godzilla kernel: 87:3:4: cannot set freq 48000 to ep 0x86
Nov 17 20:03:00 godzilla pulseaudio: alsa-source.c: Failed to set hardware parameters: Connection timed out
messages above were being logged until I unplugged the webcam.
--- Additional comment from Fedora End Of Life on 2012-08-16 14:30:06 EDT ---
This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
--- Additional comment from Bapf on 2013-02-25 11:49:26 EST ---
This bug is still present in Fedora 18.
--- Additional comment from A Mangoroban on 2013-05-31 20:44:18 EDT ---
Confirming previous comment. This bug is still present on Fedora 18.
--- Additional comment from Masoud Pajoh on 2013-06-28 15:16:24 EDT ---
I run F18 and see the this bug frequently.
I use F18, with all updates applied, on a X86_64 kernel with Evga Geforce 7600 GS PCI-E 256mb DDR2 video card. Have a Logitech quickcam connected to a usb.
Bug still present in Fedora 19.
(In reply to Bapf from comment #1)
> Bug still present in Fedora 19.
I concur, the bug still present in F19
FYI - while I believe this bug is fundamentally caused by a kernel issue, I think PulseAudio deals with it suboptimally -- one ends up losing all sound instead of just sound related to the borked hardware. Also, on my system, even after an unplug/replug of the webcam, pulseaudio needs to be restarted before things return to normal.
I created this RFE for PulseAudio to deal with this situation more elegantly:
*********** MASS BUG UPDATE **************
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.
Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.
If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.