https://bugzilla.novell.com/show_bug.cgi?id=833585 https://bugzilla.novell.com/show_bug.cgi?id=833585#c0 Summary: snd-hda-intel: Changing "Mic" volume breaks sdl audio and generates kernel warning message Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Sound AssignedTo: tiwai@suse.com ReportedBy: Yarny@public-files.de QAContact: qa-bugs@suse.de Found By: --- Blocker: --- Created an attachment (id=551432) --> (http://bugzilla.novell.com/attachment.cgi?id=551432) sdl test application User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 When changing the "Mic" volume of the sound card of my notebook, e.g. in kmix, there is a chance that the kernel logs

ALSA hda_intel.c:911 azx_get_response timeout, switching to polling mode: last cmd=0x00b35003 to dmesg. Volume control still works after it happened, but sdl can't play any sound anymore, i.e., mplayer -ao sdl somefile.oga yields Starting playback... A: 0.0 (00.0) of 4373.8 ( 1:12:53.8) ??,?% Audio device got stuck! A: 0.0 (00.0) of 4373.8 ( 1:12:53.8) ??,?% Audio device got stuck! [...] whereas mplayer -ao alsa somefile.oga still plays fine.

Reproducible: Always Steps to Reproduce: Execute

while true do for j in '1+' '1-' do for k in `seq 20` do amixer -q sset Mic $j sleep 0.1 done done done

Actual Results: After less than a minute the kernel logs the message quoted above to dmesg. Any sdl audio application won't work anymore until the machine gets rebooted. For testing I programmed a tiny sdl application which prints a "." whenever the callback is called (see attachment). When running it, the dots stop appearing at the moment the bug is triggered. When restarting the application after the bug was triggered it will print two or three dots, then stop. In fact this is how I discovered the bug: I'm using sdl for a homemade sine generator. When I use it and touch the "Mic" control, the sine generator's callback isn't called anymore and sdl simply repeats ~200ms of sound endlessly. After the bug is triggered, I cannot reset alsa to the state before. I tried to rmmod some of the snd* modules but they are all busy. I have to reboot the machine to revive sdl. I failed to reproduce the bug with the "Master" or the "PCM" volume controls. When searching the web (and bugzilla) for similar bugs, openSUSE Bug 547948 appeared where Comment #5 suggests to add position_fix=1 to the snd-hda-intel module. I tried this but it didn't affect the behaviour. This bug also exists in openSUSE 12.2 (tested ~4 months ago). This is what hwinfo has to say about my sound hardware:

$ hwinfo --sound 15: PCI 14.2: 0403 Audio device [Created at pci.319] Unique ID: 5Dex.iY2D3wQA8i8 SysFS ID: /devices/pci0000:00/0000:00:14.2 SysFS BusID: 0000:00:14.2 Hardware Class: sound Model: "AMD Audio device" Vendor: pci 0x1022 "AMD" Device: pci 0x780d SubVendor: pci 0x1179 "Toshiba America Info Systems" SubDevice: pci 0xfb44 Revision: 0x01 Driver: "snd_hda_intel" Driver Modules: "snd_hda_intel" Memory Range: 0xf0440000-0xf0443fff (rw,non-prefetchable) IRQ: 46 (3234 events) Module Alias: "pci:v00001022d0000780Dsv00001179sd0000FB44bc04sc03i00" Driver Info #0: Driver Status: snd_hda_intel is active Driver Activation Cmd: "modprobe snd_hda_intel" Config Status: cfg=new, avail=yes, need=no, active=unknown

Here are the snd* modules I have loaded:

$ lsmod | grep -E '^snd' snd_hda_codec_realtek 82329 1 snd_hda_intel 42034 1 snd_hda_codec 147417 2 snd_hda_codec_realtek,snd_hda_intel snd_hwdep 13603 1 snd_hda_codec snd_aloop 19301 0 snd_pcm 110154 3 snd_hda_intel,snd_hda_codec,snd_aloop snd_timer 29371 1 snd_pcm snd 91489 9 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_aloop,snd_pcm,snd_timer snd_page_alloc 18711 2 snd_hda_intel,snd_pcm

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.