Bug 497557

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

er, obviously I mean "the reason your attempted fix failed" :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Created attachment 341808 [details]
/tmp/alsa-info.txt as required by the tracker bug

Created attachment 341809 [details]
amixer_before.txt as required by the tracker bug

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.

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.

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 ?

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

According to CONFIG{sysfs_device} initialization, the attributes are read from /sys/class/sound/controlC0/device tree. Does this directory exist on your system?

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

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.

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 ?)

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

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 !

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 :)

Yes, it seems like it is. Thanks for the report. (I'm hoping to get the updated alsa-utils into F11 GA, btw.)