Bug 497557 - Sound is too faint [1028:022f]
Sound is too faint [1028:022f]
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: alsa-utils (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jaroslav Kysela
Fedora Extras Quality Assurance
:
Depends On:
Blocks: AlsaVolume
  Show dependency treegraph
 
Reported: 2009-04-24 13:53 EDT by Mathieu Bridon
Modified: 2009-05-19 20:10 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-19 20:10:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/tmp/alsa-info.txt as required by the tracker bug (26.00 KB, text/plain)
2009-04-29 13:58 EDT, Mathieu Bridon
no flags Details
amixer_before.txt as required by the tracker bug (3.92 KB, text/plain)
2009-04-29 14:02 EDT, Mathieu Bridon
no flags Details
amixer_after.txt as required by the tracker bug (3.91 KB, text/plain)
2009-04-29 14:05 EDT, Mathieu Bridon
no flags Details

  None (edit)
Description Mathieu Bridon 2009-04-24 13:53:12 EDT
Description of problem:
I installed Fedora 11 snapshot on my laptop. The sound is much too faint, so I need to set the volume to the maximum.

I ran « alsamixer -c0 » and set the « Front » mixer to the maximum (that was the only one that wasn't to the maximum already, except for « PC Beep » which is to the minimum, and if that's what I think it is, that's much better this way).

Now it is  much better, the volume control in Gnome actually has a sense. :)


Version-Release number of selected component (if applicable):
alsa-utils-1.0.19-4.fc11.x86_64


Additional info:
My sound card is:
# lspci -s 00:1b.0
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
# lspci -s 00:1b.0 -vn
00:1b.0 0403: 8086:284b (rev 02)
	Subsystem: 1028:022f
	Flags: bus master, fast devsel, latency 0, IRQ 21
	Memory at fe9fc000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel

I tried to run « alsactl init » and then both the « Front » and « PCM » mixers are not to the maximum, which make sound almost inaudible even with the « Master » mixer set to the maximum. This also returns the following message:
# alsactl init
Unknown hardware: "HDA-Intel" "SigmaTel STAC9228" "HDA:14f12c06,14f1000f,00100000 HDA:10951392,1028022f,00100000 HDA:83847616,1028022f,00100201" "" ""
Hardware is initialized using a guess method

From this message and the lspci output, I tried messing with the « /lib/alsa/init/hda file to see if I could control it. I added the following lines which seemed relevant from the informations above:
CARDINFO{mixername}=="SigmaTel STAC9228", \
  ATTR{subsystem_vendor}=="0x8086", ATTR{subsystem_device}=="0x284b", \
  GOTO="Dell Inspiron 1525"

And then:
LABEL="Dell Inspiron 1525"
# playback
CTL{reset}="mixer"
CTL{name}="PCM Playback Volume", CTL{value}="0dB,0dB"
CTL{name}="Front Playback Volume", CTL{value}="0dB,0dB"
RESULT="true", EXIT="return"

I had no luck, « alsactl init » always returned the same error message about an « unknown hardware » and the « Front » and « PCM » mixers were reset to the same value as before trying to configure them.
Comment 1 Adam Williamson 2009-04-28 19:48:52 EDT
The reason your attempted fix worked is you used the wrong IDs. As the message in fact indicates it's looking for the subsystem IDs, not the main vendor / device ones. The subsystem IDs, as noted in your lspci output, are 1028:022f (so the values in your fix should be:

ATTR{subsystem_vendor}=="0x1028", ATTR{subsystem_device}=="0x022f", \


-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 2 Adam Williamson 2009-04-28 19:49:32 EDT
er, obviously I mean "the reason your attempted fix failed" :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 3 Mathieu Bridon 2009-04-29 13:58:51 EDT
Created attachment 341808 [details]
/tmp/alsa-info.txt as required by the tracker bug
Comment 4 Mathieu Bridon 2009-04-29 14:02:22 EDT
Created attachment 341809 [details]
amixer_before.txt as required by the tracker bug
Comment 5 Mathieu Bridon 2009-04-29 14:05:26 EDT
Created attachment 341810 [details]
amixer_after.txt as required by the tracker bug

Note that after running « alsactl init » The « Master » channel was not at maximum.

However, even when setting at 100%, sound is too faint.

After messing with the mixers, setting the « Master » mixer to 100% makes sound too loud, but at least it has a meaning: I can make sound faint or loud if I desire. Before that, I had to choose between too faint or inaudible.
Comment 6 Mathieu Bridon 2009-04-29 14:07:42 EDT
Here are the files requested in the tracker bug.

As for the full context, it's a laptop with only 2 built-in speakers.

I'll try to play again with the /lib/alsa/init/hda file as per the informations Adam provided in comment #1.
Comment 7 Mathieu Bridon 2009-04-29 14:53:11 EDT
I tried:
CARDINFO{mixername}=="SigmaTel STAC9228", \
  ATTR{subsystem_vendor}=="0x1028", ATTR{subsystem_device}=="0x022f", \
  GOTO="Dell Inspiron 1525"

As well as:
CARDINFO{mixername}=="HDA-Intel", \
  ATTR{subsystem_vendor}=="0x1028", ATTR{subsystem_device}=="0x022f", \
  GOTO="Dell Inspiron 1525"

Neither worked, still getting the « unknown hardware » message :-/

What I find weird is that in the message, the last two fields are supposed to represent the subsystem_vendor and subsystem_device. This can be seen in /lib/alsa/init/00main:
ERROR="Unknown hardware: \"$cardinfo{driver}\" \"$cardinfo{mixername}\" \"$cardinfo{components}\" \"$attr{subsystem_vendor}\" \"$attr{subsystem_device}\"\n"
(seems like the definition of the error message)

However, in the message I get, both of those fields are empty. Could it be that « alsactl init » doesn't manage to get those values, and so it fails the test in the /lib/alsa/init/hda file ?
Comment 8 Adam Williamson 2009-04-29 15:29:33 EDT
well, then I'm not sure what's wrong, but we now definitely have enough info for someone smarter to be able to look at it :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 9 Jaroslav Kysela 2009-04-29 15:44:54 EDT
According to CONFIG{sysfs_device} initialization, the attributes are read from /sys/class/sound/controlC0/device tree. Does this directory exist on your system?
Comment 10 Mathieu Bridon 2009-04-29 15:57:28 EDT
It does:
# ll /sys/class/sound/controlC0/device
lrwxrwxrwx. 1 root root 0 avril 29 20:42 /sys/class/sound/controlC0/device -> ../../card0

And then:
# ll /sys/class/sound/card0/
total 0
drwxr-xr-x. 3 root root    0 avril 29 19:49 controlC0
lrwxrwxrwx. 1 root root    0 avril 29 21:53 device -> ../../../0000:00:1b.0
drwxr-xr-x. 3 root root    0 avril 29 21:53 hwC0D0
drwxr-xr-x. 3 root root    0 avril 29 21:53 hwC0D1
drwxr-xr-x. 3 root root    0 avril 29 21:53 hwC0D2
-rw-r--r--. 1 root root 4096 avril 29 21:53 id
-r--r--r--. 1 root root 4096 avril 29 21:53 number
drwxr-xr-x. 3 root root    0 avril 29 21:53 pcmC0D0c
drwxr-xr-x. 3 root root    0 avril 29 21:53 pcmC0D0p
drwxr-xr-x. 3 root root    0 avril 29 21:53 pcmC0D3p
drwxr-xr-x. 2 root root    0 avril 29 21:53 power
lrwxrwxrwx. 1 root root    0 avril 29 21:53 subsystem -> ../../../../../class/sound
-rw-r--r--. 1 root root 4096 avril 29 21:53 uevent
Comment 11 Jaroslav Kysela 2009-04-30 05:34:58 EDT
The sysfs tree was changed in recent kernels. I updated the alsactl tool now. The patch is here:

http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=94ac54bff1e15e69c7c722695c3b259a3bb5c6c0

It will be in alsa-utils-1.0.20 (and I'll update Fedora packages ASAP aftter 1.0.20 release).

Please, change 00main to for your testing purposes:

CONFIG{sysfs_device}="/class/sound/card$cardinfo{card}/device"

Also, do not forget to test and initialize Microphone input on your platform to some safe value.
Comment 12 Mathieu Bridon 2009-05-01 12:52:26 EDT
Works fine with this change of configuration, now « alsactl init » doesn't complain and sets the mixers to the values I added in the /lib/alsa/init/hda file :)

About input, I don't really know how to test it. It seems like my laptop has an integrated speaker (which I didn't even know ^^).

« alsamixer -c0 » lists the following capture channels:
# those 3 are mixers with a « volume bar »
- Capture    (set to 100% by default)
- Capture 1  (set to 0 by default)
- Capture 2  (set to 0 by default)
# those 3 are only switches allowing me to choose
# between « Mic », « Front Mic » and « Line »
# all set to « Mic » by default
- Input Source
- Input Source 1
- Input Source 2
# those 3 are mixers with a « volume bar »
# all set to 0 by default
- Mux
- Mux 1
- Mux 2

Messing with the entries « 1 » and/or « 2 » doesn't seem to do anything.

« Capture » is already set to 100% by default, and when I yell at my laptop, then playback what I recorded with output volume to maximum, I can hear a faint whisper of what I yelled.

If I set « Mux » to something above 0, then I hear way better what I recorded, but there's too much noise.

So I guess input is already well set...

Should I also try with external mic (webcam) ?

(just to be sure, the line you asked me to modify for testing purpose will not be necessary with the latest alsa-utils when it's out right ?)
Comment 13 Adam Williamson 2009-05-15 11:52:30 EDT
Can you re-test with alsa-utils 1.0.20 and confirm the current status of this bug? It's available from rawhide (real rawhide, f12) or f11 updates-candidates, currently. Or directly via koji:

http://koji.fedoraproject.org/koji/buildinfo?buildID=102232
Comment 14 Mathieu Bridon 2009-05-15 14:04:15 EDT
I already have alsa-utils 1.0.20, and I'm on F11 (moved on it from Rawhide), and I didn't take it in Koji or in the updates candidates. Is it normal ? o_O
$ rpm -q alsa-utils
alsa-utils-1.0.20-2.fc11.x86_64


When it updated, the lines I had modified (see above) disappeared, I guess that's because it's not a %config file so it was replaced.

Now, when I boot my computer, the Front and PCM mixers are at 100%, which allows me to listen to music nicely and use the gnome-volume-control mixer :)

If I run « alsactl init », I get the following:
# alsactl init
Unknown hardware: "HDA-Intel" "SigmaTel STAC9228" "HDA:14f12c06,14f1000f,00100000 HDA:10951392,1028022f,00100000 HDA:83847616,1028022f,00100201" "0x1028" "0x022f"
Hardware is initialized using a guess method
/usr/share/alsa/init/default:51: control element not found
/usr/share/alsa/init/default:52: missing closing brace for format
/usr/share/alsa/init/default:52: error parsing CTL attribute
/usr/share/alsa/init/default:52: invalid rule

Still the « unknown hardware » message, lots of weird errors, but the mixers in alsamixer are still at 100%, which is fine.

So basically, some scary messages but sound is great !
Comment 15 Mathieu Bridon 2009-05-16 10:30:30 EDT
Same thing with today's update and alsa-utils-1.0.20-3.fc11.x86_64, except that the weird messages disappeared:
# alsactl init
Unknown hardware: "HDA-Intel" "SigmaTel STAC9228" "HDA:14f12c06,14f1000f,00100000 HDA:10951392,1028022f,00100000 HDA:83847616,1028022f,00100201" "0x1028" "0x022f"
Hardware is initialized using a guess method


If I knew anything about audio, I'd say the bug is fixed :)
Comment 16 Adam Williamson 2009-05-19 20:10:06 EDT
Yes, it seems like it is. Thanks for the report. (I'm hoping to get the updated alsa-utils into F11 GA, btw.)

Note You need to log in before you can comment on or make changes to this bug.