I have Asus A8V-VM motherboard, VIA K8M890 chipset with HDA audio.No matter what version of kernel I use, playing 2 channel sound has always high-pitch background noise, like feedback in an amplifier, and attempts to manipulate PCM during playback silence the card. Multiple (perhaps all) channels must be muted then in alsamixer, and then unmuted again to resume work. Interestingly feeding a 6 channel sample up the card works well, I get clear sound without noise and PCM can be manipulated freely without risk. I use a simple workaround in mplayer, just adding "-af channels=6" to the command line (or rather "af=channels=6" to the config file), but it is not so easy with other programs. From Bug #166149 I understand that I should report that upstream. Yet I hope at least my workaround might possibly help to others who have similar problem. Reproducible: Always Steps to Reproduce: Play any 2 channel (stereo) sound sample. Try to change volume. Actual Results: High pitch noise. Manipulating PCM (changing volume) brings about silence. Expected Results: Clear playback, adjustable volume. 6 channel OK.
When you say no matter what kernel you use, I'm guessing you mean 2.6.20 and 2.6.21? Please clarify to make sure. Could you also post your dmesg, emerge --info, kernel config, lspci, and lsmod? Also just to see if it might have a resemblence to a similar bug, could you post the output of alsamixer scontents? Thanks
Make that : amixer scontents not alsamixer
(In reply to comment #1) > When you say no matter what kernel you use, I'm guessing you mean 2.6.20 and > 2.6.21? Please clarify to make sure. From 2.6.18-gentoo-r6 to 2.6.21. > Could you also post your dmesg, emerge --info, kernel config, lspci, and lsmod? There is nothing interesting in dmesg. lspci says: 00:00.0 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:00.5 PIC: VIA Technologies, Inc. K8M890CE I/O APIC Interrupt Controller 00:00.6 Host bridge: VIA Technologies, Inc. Unknown device 6290 00:00.7 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] 00:02.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller 00:0f.0 SATA controller: VIA Technologies, Inc. VT8251 AHCI/SATA 4-Port Controller 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90) 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8251 PCI to ISA Bridge 00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 7c) 00:13.0 PCI bridge: VIA Technologies, Inc. VT8251 Host Bridge 00:13.1 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCI Bridge 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 02:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] 02:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE] 04:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio Controller 05:09.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01) All the other things I'm going to post as attachements.
Created attachment 119394 [details] emerge --info emerge --info
Created attachment 119395 [details] lsmod The output of lsmod.
Created attachment 119397 [details] lspci -vv The audio portion of lspci -vv.
Created attachment 119399 [details] amixer scontents The output of amixer scontents.
You said the bug appears from 2.6.18-gentoo-r6 to 2.6.21, does that mean that earlier kernel versions did work for you? If so, which was the latest one? Also, you say this happens with the in-kernel driver. Does the problem still exist if you use an out-of-kernel driver, ie. alsa-driver?
There's no need to test alsa-driver specifically. We're just interested to know if have ever found a working configuration, or if it's always been broken for you.
(In reply to comment #9) > There's no need to test alsa-driver specifically. We're just interested to know > if have ever found a working configuration, or if it's always been broken for > you. I don't think it ever worked correctly. As far as I remember, the eldest kernel I tried was of 2.6.17 series. That time my hardware was relatively new, and especially its SATA controller just starting to be recognised at all in the newest kernel versions. The problems with sound were just a minor annoyance. I don't remember when I first tried to play six channel sound, so I'm not sure if that always worked, but with all the kernel versions I keep now the case is all the same: Six channels good, two channels bad. Since playing two channels, adding four empty tracks is always possible, I can live well with the present driver status; its in fact a real problem only when I try to use a program that I don't know how to configure for such a trick. At the same time, however, I wonder what makes the difference, why not feeding four channels with anything is not the same as feeding them with nothing.
Thanks for the info. Can you reproduce this on the latest development kernel, currently 2.6.22-rc4?
(In reply to comment #11) It took me some time to find a while for kernel compilation and reboot. Now I have sys-kernel/git-sources-2.6.22_rc4 installed and kernel compiled -- and I see no difference Six channels work, two channels not. Even if I mute everything except PCM and Front, I'm getting high pitch noise as a sound background, and if I try to manipulate PCM during two channel playback, all sound gets lost. Then muting and unmuting of PCM and Front is necessary -- both of them, either at a time or one after another -- to enable playback again. No error message anywhere I have looked.
Created attachment 122547 [details] emerge --info
Created attachment 122548 [details] lsmod
Created attachment 122549 [details] amixer scontents
I'd still be interested in out of kernel alsa-driver works for you.
(In reply to comment #16) Compiling kernel (sys-kernel/gentoo-sources-2.6.21-r2) with just bare sound support, and then installing media-sound/alsa-driver-1.0.14_rc3 helped partially. No background noise this time, nevertheless manipulating PCM during playback still kicks the sound out, and muting of PCM and Front, followed by their unmuting, is required to get sound back.
OK. please file this bug upstream at http://https://bugtrack.alsa-project.org/alsa-bug/ and post the new URL here.
I took my time to report the bug upstreams (and to skim through those many intel-hda bugs already reported there, looking for something similar), but finaly I've filed my report: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3219 Verifying the bug again for the report I found the high-pitch background noise is back, even with the standalone alsa-driver -- so the problem is probably consistently persistent.
Thanks, will monitor that.
Looks like sys-kernel/gentoo-sources-2.6.23-r2 with media-sound/alsa-driver-9999 installed on November 27th works OK. I've just tested that and reported my comfortable findings upstream. (May be the driver has even been in order for some time already, I've been letting my computer work undisturbed until lately.)
reportedly fixed in 2.6.23 (see upstream bug)
oh wait, you're not using the in-kernel ALSA, so we should try and backport the patch. Any chance you can test the latest 2.6.24-rc release (use the in-kernel ALSA) and confirm if the bug is fixed there?
(In reply to comment #23) > Any chance you can test the latest 2.6.24-rc release (use the in-kernel ALSA) > and confirm if the bug is fixed there? Unfortunately the in-kernel ALSA of sys-kernel/vanilla-sources-2.6.24-rc3 still has the problem.
Please see if the in-kernel driver in 2.6.25-rc1 is any better. Also, if you have already tried 2.6.24 final, I'd be interested to know the results.
(In reply to comment #25) I don't reboot my amd64 box often, but recently after a crash I used the opportunity to update my kernel to gentoo-sources-2.6.24. The ALSA driver there seems to play two channel samples well. I'm sorry for neglecting to report that. So the bug is probably fixed in sys-kernel/gentoo-sources-2.6.24. Unfortunately I've omitted experimenting with vanilla-sources, and now I have long calculations running again, so I'm not sure when I'll be able to test other kernel flavours.
OK, thanks. No need to test anything else. Unless anyone has some insight on which post-2.6.23 patch fixes this, I think we'll just wait for 2.6.24 to go stable for this to be 100% fixed. Not worth the time backporting given the low impact and the fact that 2.6.24 will hopefully be stable within a week or 2. Thanks for all the testing.
