Bugzilla Bug 178549

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 an attachment (id=119394) [details]
emerge --info

emerge --info

Created an attachment (id=119395) [details]
lsmod

The output of lsmod.

Created an attachment (id=119397) [details]
lspci -vv

The audio portion of lspci -vv.

Created an attachment (id=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 an attachment (id=122547) [details]
emerge --info

Created an attachment (id=122548) [details]
lsmod

Created an attachment (id=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.