I have a motherboard that uses the AMD am690g chip set,
which has a sound hardware called "azalia", which apparently is
controlled by linux/sound/pci/hda/hda_intel.c.
The audio works fine under linux-2.6.24.2. However, in
linux-2.6.25-rc3 (haven't tried earlier ones) through 2.6.25-rc6
(released a couple of hours ago), the audio is barely audible unless I
crank up my speakers to the maximum volume, at which point I can hear
the music playing relatively quietly. In comparison, if I were to do
that with 2.6.24.2, it would wake the neighbors. In both cases,
this is with the volume set in aumix to 100 in both left and right
(the maximum values).
I haven't attempted to look through kernel changes from
2.6.24.2 to 2.5.25-rc3 yet, although I expect to over the weekend if
nobody beats me to it.
Adam Richter
On Mon, Mar 17, 2008 at 11:23:59PM -0700, Adam J. Richter wrote:
> I have a motherboard that uses the AMD am690g chip set,
> which has a sound hardware called "azalia", which apparently is
> controlled by linux/sound/pci/hda/hda_intel.c.
>
> The audio works fine under linux-2.6.24.2. However, in
> linux-2.6.25-rc3 (haven't tried earlier ones) through 2.6.25-rc6
> (released a couple of hours ago), the audio is barely audible unless I
> crank up my speakers to the maximum volume, at which point I can hear
> the music playing relatively quietly. In comparison, if I were to do
> that with 2.6.24.2, it would wake the neighbors. In both cases,
> this is with the volume set in aumix to 100 in both left and right
> (the maximum values).
>
> I haven't attempted to look through kernel changes from
> 2.6.24.2 to 2.5.25-rc3 yet, although I expect to over the weekend if
> nobody beats me to it.
>
> Adam Richter
I want to add the results of a few simple tests:
1. Reverting only linux-2.6.25-rc6/sound/pci/hda/hda_intel.c to the
2.6.24.2 version had no effect (sound was still very quiet).
2. Reverting linux-2.6.25-rc6/sound/pci/hda/*.[ch] to their
2.6.24.2 versions worked (i.e., sound was lound again).
3. Other quick attempts at reverting various subsets of
linux/sound/pci/hda/*.[ch] have resulted only in compilation
errors.
Adam J. Richter wrote:
> I have a motherboard that uses the AMD am690g chip set,
> which has a sound hardware called "azalia", which apparently is
> controlled by linux/sound/pci/hda/hda_intel.c.
ACK, I have the same problem here:
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High
Definition Audio Controller (rev 01)
At Mon, 17 Mar 2008 23:23:59 -0700,
Adam J. Richter wrote:
>
> I have a motherboard that uses the AMD am690g chip set,
> which has a sound hardware called "azalia", which apparently is
> controlled by linux/sound/pci/hda/hda_intel.c.
>
> The audio works fine under linux-2.6.24.2. However, in
> linux-2.6.25-rc3 (haven't tried earlier ones) through 2.6.25-rc6
> (released a couple of hours ago), the audio is barely audible unless I
> crank up my speakers to the maximum volume, at which point I can hear
> the music playing relatively quietly. In comparison, if I were to do
> that with 2.6.24.2, it would wake the neighbors. In both cases,
> this is with the volume set in aumix to 100 in both left and right
> (the maximum values).
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.
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
In most cases, running the following commands solves the mixer issue:
% amixer set Master unmute 80%
% amixer set Front unmute 100%
% amixer set Headphone unmute 100%
Takashi
At Tue, 18 Mar 2008 00:41:58 -0700,
Adam J. Richter wrote:
>
> On Mon, Mar 17, 2008 at 11:23:59PM -0700, Adam J. Richter wrote:
> > I have a motherboard that uses the AMD am690g chip set,
> > which has a sound hardware called "azalia", which apparently is
> > controlled by linux/sound/pci/hda/hda_intel.c.
> >
> > The audio works fine under linux-2.6.24.2. However, in
> > linux-2.6.25-rc3 (haven't tried earlier ones) through 2.6.25-rc6
> > (released a couple of hours ago), the audio is barely audible unless I
> > crank up my speakers to the maximum volume, at which point I can hear
> > the music playing relatively quietly. In comparison, if I were to do
> > that with 2.6.24.2, it would wake the neighbors. In both cases,
> > this is with the volume set in aumix to 100 in both left and right
> > (the maximum values).
> >
> > I haven't attempted to look through kernel changes from
> > 2.6.24.2 to 2.5.25-rc3 yet, although I expect to over the weekend if
> > nobody beats me to it.
> >
> > Adam Richter
>
> I want to add the results of a few simple tests:
>
> 1. Reverting only linux-2.6.25-rc6/sound/pci/hda/hda_intel.c to the
> 2.6.24.2 version had no effect (sound was still very quiet).
>
> 2. Reverting linux-2.6.25-rc6/sound/pci/hda/*.[ch] to their
> 2.6.24.2 versions worked (i.e., sound was lound again).
>
> 3. Other quick attempts at reverting various subsets of
> linux/sound/pci/hda/*.[ch] have resulted only in compilation
> errors.
That's vital to know which codec is used. lspci shows only the
controller chip and it doesn't help debugging at all.
Please show the alsa-info.sh output. At best, get the alsa-info.sh
outputs on both 2.6.24 and 2.6.25 kernels to compare.
thanks,
Takashi
At Tue, 18 Mar 2008 03:54:20 -0400,
Jeff Garzik wrote:
>
> Adam J. Richter wrote:
> > I have a motherboard that uses the AMD am690g chip set,
> > which has a sound hardware called "azalia", which apparently is
> > controlled by linux/sound/pci/hda/hda_intel.c.
>
> ACK, I have the same problem here:
>
> 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High
> Definition Audio Controller (rev 01)
A different controller, and likely a different codec, thus a
different problem :)
Anyway, it'd be helpful if you can get alsa-info.sh snapshots on both
working and non-working states. alsa-info.sh can be found on:
http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh
thanks,
Takashi
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.
> 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.
> In most cases, running the following commands solves the mixer issue:
>
> % amixer set Master unmute 80%
> % amixer set Front unmute 100%
> % amixer set Headphone unmute 100%
Thank you. These commands give me approximately the old
volume levels. In particular, the middle command seems to be the one
that effected the volume that I could hear.
I hope the little bit of information about the PCI IDs that I
was able to provide above will be helpful. Thanks again for your
quick response.
Adam J. Richter
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