You are not logged in.
Pages: 1
Topic closed
The last kernel version where my audio HW worked flawlessly, was 3.0.4. Even since 3.0.6, the situation changed to this:
The audio seems to be OK (playing videos with mplayer, or vlc, or audio .mp3 files with xmms, etc). But then, suddenly, after 1 or 2 minutes in, a small audio gap - very small, but big enough to be noticeable (in the order of 50-100ms) - is heard. It is then happening again after, say, 10 seconds. And of course drives me mad.
This is NOT application specific - it happens with any player I've tried: they work fine under 3.0.4, but their output occasionally gaps (and alsa errors are sometimes reported) ever since 3.0.6. It kept on happening with 3.0.7, etc, all the way up to 3.1, which I just tried.
I've dealt with the situation by pinning back in /etc/pacman.conf:
IgnorePkg = linux linux-headers
...but it becomes increasingly desperate: with the upgrade to kernel 3.1, the nvidia package now depends on 3.1 - so I now have to pin back nvidia as well:
IgnorePkg = linux linux-headers nvidia
...and I am pretty sure I'll have to keep adding whatever places a dependency on a kernel later than 3.0.4.
Each time a new kernel version appears, I try it full of hope - only to be disappointed again.
Am I the only one suffering with this?
Did something change after 3.0.4 in (shot in the dark) kernel audio priorities? Or maybe something to do with cgroup scheduling?
The audio HW in my machine is an on-board card (on the motherboard) - details follow below, in terms of "lspci" and "lsmod" output. Please refrain from suggesting a purchase of an audio board - this is definitely a SW error, since it doesn't happen with 3.0.4 and kernels before it.
Any advice most welcome,
Thanassis.
# lspci -v
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 01)
Subsystem: Foxconn International, Inc. Device 0dc2
Flags: bus master, fast devsel, latency 0, IRQ 43
Memory at fbffc000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [130] Root Complex Link
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
# lsmod | grep snd
snd_hda_codec_realtek 222124 1
snd_hda_intel 19101 0
snd_hda_codec 66954 2 snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 4942 1 snd_hda_codec
snd_pcm_oss 33792 0
snd_pcm 60015 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_timer 15374 1 snd_pcm
snd_page_alloc 5837 2 snd_hda_intel,snd_pcm
snd_mixer_oss 12807 1 snd_pcm_oss
snd 43561 8 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_pcm,snd_timer,snd_mixer_oss
soundcore 4986 1 snd
Last edited by ttsiodras (2012-02-07 19:37:41)
Offline
Addendum: To check if this is scheduling-related or not, I just compiled from AUR and installed the BFS (Con Kolivas) versions of the trio: linux, linux-headers, nvidia (i.e. the -ck versions of them). I changed my grub.conf, rebooted... and verified that the problem persists. The 3.1 and -ck line exhibits the same audio... starvation as the normal 3.1.
In the absence of any other information, this increases the likelihood of a device driver bug (for my audio HW) which crept up after 3.0.4.
Offline
I read this in the Alsa Arch Linux Wiki:
"Sound Skipping While Using Dynamic Frequency Scaling: Some combinations of ALSA drivers and chipsets may cause audio from all sources to skip when used in combination with a dynamic frequency scaling governor such as ondemand or conservative. Currently, the solution is to switch back to the performance governor. Refer to the CPU Frequency Scaling for more information."
And that raised my hopes for a while... so I upgraded again to the tip (3.1) and made sure to set the scaling_governor in "performance":
# cat /sys/devices/system/cpu/cpu{0,1}/cpufreq/scaling_governor
performance
performance
Same problem, though - the sound stutters :-(
I've also made the problem manifest in a more deterministic manner: (1) I play a video (2) while it is playing, I open another XTerm and load one of the two cores of my CPU with a heavy benchmark (git clone git://github.com/ttsiodras/Score4.git && cd Score4 && make benchmark). The sound from the video then start to stutter in 1-2 seconds.
Running out of ideas...
Offline
Sat down and read the ALSA guide ( https://wiki.archlinux.org/index.php/Ad … chitecture ).
Turns out that for reasons that I *really* dont wanna know about, the snd-hda-intel.ko module sometimes detects the wrong kind of chip, and in that case it needs to be told what chip to use via the "model=" parameter (read the guide for more info, search for "model=").
In my case, I have a FoxConn motherboard (G41 MXE):
home:~# head /proc/asound/card0/codec#2
Codec: Realtek ALC662 rev1
Address: 2
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0662
Subsystem Id: 0x105b0dc2
Revision Id: 0x100101
No Modem Function Group found
Default PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
So I have an ALC662. Looking at...
http://www.kernel.org/doc/Documentation … Models.txt
... I see I have these options:
3stack-dig / 3stack-6ch / 3stack-6ch-dig / 5stack-dig / lenovo-101e / eeepc-p701 / eeepc-ep20
/ ecs / m51va / g71v / h13 / g50v / asus-mode1 / asus-mode2 / asus-mode3 / asus-mode4
/ asus-mode5 / asus-mode6 / asus-mode7 / asus-mode8 / dell / dell-zm1 / samsung-nc10 / auto
I tried "ecs" first, which according to the "HD-Audio-Models.txt" linked above, is my proper option (my mobo is a FoxConn one):
home:~# rmmod $(lsmod | grep snd | awk '{print $1}') >/dev/null 2>&1
home:~# rmmod $(lsmod | grep snd | awk '{print $1}')
home:~# lsmod | grep snd
There, no more snd_* modules. Load snd-hda-intel with "ecs" model:
home:~# modprobe snd_hda_intel model=ecs
...and do the test...
...nope, audio still stutters.
Next one to try... hmm... lots of asus (doubtful), trying "dell":
home:~# rmmod $(lsmod | grep snd | awk '{print $1}') >/dev/null 2>&1
home:~# rmmod $(lsmod | grep snd | awk '{print $1}')
home:~# modprobe snd_hda_intel model=dell
Doing the test...
*********************
audio is clean, finally!
*********************
Permanent modification of /etc/modprobe.d/modprobe.conf to set my card's model:
home:~# cat /etc/modprobe.d/modprobe.conf
#
# /etc/modprobe.d/modprobe.conf
#
options snd-hda-intel model=dell
Hope all this helps someone.
Last edited by ttsiodras (2012-01-29 18:29:15)
Offline
Problem resurfaced in 3.2.x line - I've pinned my machine down to linux 3.1.9 (the last of the 3.1.x series).
All releases in the 3.2 line reintroduce the sound stutter problem. I checked the commits in hda_intel.c from 3.1.9 to 3.2.1, but couldn't find anything that seems relevant to my PCI ids...
(sigh)
Offline
Do you still have the modprobe.conf you configured the card model with, in /etc/modprobe.d,
just to check if it wasn't renamed to modprobe.conf.pacsave with the latest updates?
. Main: Intel Core i5 6600k @ 4.4 Ghz, 16 GB DDR4 XMP, Gefore GTX 970 (Gainward Phantom) - Arch Linux 64-Bit
. Server: Intel Core i5 2500k @ 3.9 Ghz, 8 GB DDR2-XMP RAM @ 1600 Mhz, Geforce GTX 570 (Gainward Phantom) - Arch Linux 64-Bit
. Body: Estrogen @ 90%, Testestorone @ 10% (Not scientific just out-of-my-guesstimate-brain)
Offline
@PReP: Indeed I did notice that, and for a moment I hoped that was the reason - but a quick check with an "rmmod snd-hda-intel" followed by an explicit "modprobe snd-hda-intel model=dell" showed that the problem remains. That same sequence of cmds solves the problem in kernel versions <= 3.1.9, but not in latter ones...
Offline
It turns out that the ALSA people decided to remove many options from the "model" parameter list:
"ALC662 hda codec model options drastically reduced from kernel 3.2.0 onwards"
https://bugtrack.alsa-project.org/alsa- … hp?id=5518
The "dell" option is no longer there - more than 70% of the list is gone!
And apparently I am not the only one that has problems... The Fedora project has chosen to NOT merge any of the ALSA changes in 3.2 because of stuff like this. From the bug report:
"The problems start when a sound card which used a previously available model option to provide access to some capabilities is now forced to fall back on automatically probed capabilities and the probe fails to detect what is required."
I sent a bug report to alsa-devel - I'll report here if I have any news.
Last edited by ttsiodras (2012-02-07 08:36:11)
Offline
Kernel 3.2.x has a useful option:
CONFIG_SND_HDA_PREALLOC_SIZE=2048
I set that, to get my buffer_size to 8192 (see my sig for my ~/.asoundrc)
If compiling alsa-driver 1.0.25, I use:
--with-card-options=seq-rtctimer-default,hda-codec-realtek,hda-hwdep,hda-reconfig,hda-patch-loader,hda-enable-realtek-quirks,hda-codec-analog,hda-prealloc-size=2048
(Probably not all those options are needed, but whatever.)
Show your buffer_size used - play some audio, while running:
cat /proc/asound/card0/pcm0p/sub0/hw_params
Offline
@brebs: Thanks, but the problem is not about audio buffers, it's about the initialization of my ALC662 chip. Since kernel 3.2, the driver for my specific motheboard's audio chip (ALC662) has lost code that fixes the problem (i.e. the "model" option in the driver lost a number of values, including the one I was using, "dell").
https://bugtrack.alsa-project.org/alsa- … hp?id=5530
This has to do with the HW setup of the chip - and as you can read in the upstream ALSA bug report I submitted, the driver now falls back on heuristics - that simply fail in my case.
Last edited by ttsiodras (2012-02-07 08:59:03)
Offline
SOLVED again! :-)
I checked the contents of the PCI config space for my sound card: I booted in 3.1.9 where the driver works fine, dumped the PCI config space, and then did the same under 3.2.4 where the sound stuttered:
# hexdump /proc/bus/pci/00/1b.0 > pciConfigSpaceGood
(reboot in 3.2.4)
# hexdump /proc/bus/pci/00/1b.0 > pciConfigSpaceBad
# diff -u pciConfigSpaceGood pciConfigSpaceBad
-0000060 7005 0081 300c fee0 0000 0000 4179 0000
+0000060 7005 0081 300c fee0 0000 0000 4181 0000
One byte is different!
So I knew I had to hunt down this change. Normally, one would check the driver sources to see who/when writes in that register offset (0x6c) but I decided to experiment a bit - and nailed it:
I just had to uncheck the "Headphone" checkbox from my ALSA mixer:
# hexdump /proc/bus/pci/00/1b.0 | grep ^0000060
0000060 7005 0081 300c fee0 0000 0000 4179 0000
There! After this, stutter was gone - clear, crisp audio.
Until next time the snd-hda-intel driver breaks :-)
Offline
This is brilliant. You not only solved my problem, but I also learnt a great deal about diagnosing issues. I can't thank you enough.
Nigel
Offline
Congrats nigelthorne and welcome ot the forums. No need to bump in your exuberance. Be sure to read the Forum Etiquette in full. Closing to prevent further bumping.
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline
Pages: 1
Topic closed