linux-kernel - Re: intel-hda sound too quiet in linux-2.6.25-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <s5hy78ekc5s.wl%tiwai@suse.de>
Date:	Wed, 19 Mar 2008 15:42:55 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	"Adam J. Richter" <adam@...drasil.com>
Cc:	pshou@...ltek.com.tw, matt.jared@...el.com, andy.kopp@...el.com,
	dan.d.kogan@...el.com, linux-kernel@...r.kernel.org
Subject: Re: intel-hda sound too quiet in linux-2.6.25-rc6

At Wed, 19 Mar 2008 01:11:46 -0700,
Adam J. Richter wrote:
> 
> Hi Takashi,
> 
> 	Thank you for your quick response.  Your suggested alsa
> commands seem to have worked.  Here is a more detailed response in
> case the information contained below might be helpful.
> 
> 
> On Tue, Mar 18, 2008 at 11:15:53AM +0100, Takashi Iwai wrote:
> [...] 
> > This is likely a missing volume setting.  With the upgrade to 2.6.25,
> > you may have a different mixer representation and the udev or init
> > script didn't restore the old mixer setting properly (typicall missing
> > -F option to alsactl).  Also note that aumix doesn't cover all volume
> > controls since it's an OSS app.
> 
> 	I would think that these new volume controls should be made to
> default to whatever setting leaves the volume unmodified (usually
> "100%"), to minimize disruption and to preserve support for pure OSS
> systems.  I would be interested to know if there is some consideration
> that outweighs this.

Actualy the new virtual master is 100% as default.  The problem is
that the (old) alsactl is so strict (unless -F option is given) and
won't accept any changed values.  This is so even only when the mixer
element number id is changed although other attributes remain
identical.  Thus one addition may cause a chain reaction over all
elements.  IOW, it's rather a design problem of alsactl and a wrong
use in scripts than a kernel regression.

I already fixed this behavior in the latest version of alsactl to be
more robust.  But that version isn't used widely yet, unfortunately.

> > Anyway, there is too little hardware information here.  Please show
> > the output of alsa-info.sh:
> > 	http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh  
> 
> 	I ran this script, and it only showed me the dialog program
> getting a segmentation fault (probably my fault), but perhaps the
> following information will be helpful:
> 
> % lspci -s 14.2
> 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia
> % lspci -n -s 14.2
> 00:14.2 0403: 1002:4383
> 
> 	Vendor 0x1002, product 0x4383 in sound/pci/hda/hda_intel.c has
> a pci_device_id entry with AZX_DRIVER_ATI in the extra data field.
> 
> 	Also, Jeff Garzik's posting about having a similar problem
> with a chip described by lspci as "Audio device: Intel Corporation
> 82801G (ICH7 Family) High Definition Audio Controller (rev 01)"
> appears to correspond to PCI vendor 0x8086, PCI device ID 0x27d8,
> which has AZX_DRIVER_ICH.

The controller chip doesn't indicate the root cause but it's rather in
the codec.  Please show the contents of /proc/asound/card0/codec*
files and the generated file via "alsactl -f somefile store", together
with PCI SSID (lspci -nv output).


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/