Absolutely no sound on Sigmatel / Intel FC6 Gateway

I have been trying for months to get the sound working on my Gateway laptop.

I have updated the kernel and Alsa Mixer several times. Currently I have:
Kernel 2.6.20-1.2948.fc6
AlsaMixer v1.0.14rc1

The Sound Card detection has never worked and I have never beeen able to here sound. (works in Windows though)

The sound is not turned down or muted and I don't even have 'amplifier' in the mixer at all.

Here is some more info on my system:
http://pastebin.ca/592465

have you tried running alsaconf as root? open a terminal, su to root, call alsaconf and configure the card.

According to Kinfocenter in my Debian testing, these are the specs for my sigmaTel:
Sound driver:3.8.1a-980706 (ALSA v1.0.14rc3 emulation code)
Installed drivers: Type 10: ALSA emulation
Card config: Intel ICH6 with STAC9750.51 at irq 16
Audio devices: 0: Intel ICH6 (DUPLEX)
Synth devices: NOT ENABLED IN CONFIG
Midi devices: NOT ENABLED IN CONFIG
Timers: 7: system tymer
Mixers: 0: SigmaTel STAC9750.1

Sound modules:

snd_pcm_oss
snd_mixer_oss
snd_intel8x0
snd_ac97_codec
snd_pcm
snd_timer
snd
snd_page_alloc
soundcore

I don't know how many setting for diferent devices in your mixer, but allot of people solve the "no sound" issue by playing with mute, some items need to be muted. Mandriva installed on this laptop and had no sound issues, Debian testing originally had a alsa-bug where the Master and PCM were muted from fresh installation, so just had to issue a couple alsa unmute commands to fix it and get sound.

Originally Posted by jaydot have you tried running alsaconf as root? open a terminal, su to root, call alsaconf and configure the card.

I have been unable to run alsaconf. I get a message that this command is not found. Under further inspection I have trouble finding this function anywhere on my linux partition even though Alsa and alsatools are listed as installed. I have updated them witht he most recent update.

Have you tried adding the "probe_mask=1" option when loading the snd-hda-intel module? (e.g., adding "options snd-hda-intel probe_mask=1" to the end of /etc/modprobe.d/alsa-base on some distributions?) I've found that this has corrected a problem with my system wherein I never got sound and dmesg would report a line of the form:

hda_intel: azx_get_response timeout

during boot.

Originally Posted by Twinkel Have you tried adding the "probe_mask=1" option when loading the snd-hda-intel module? (e.g., adding "options snd-hda-intel probe_mask=1" to the end of /etc/modprobe.d/alsa-base on some distributions?)

Fedora Core 6 does not have the alsa-base file but I added it to the end of the modprobe.conf file with no luck.

What does "aplay -l" report for you... wait, no I see this on that page you linked to. It really looks like you're a prime candidate for the "probe_mask=1" option. I'm going to try to break my sound and reboot to see if I get a similar report.

Also, what does "dmesg | grep hda_" report? Do you get the

hda_intel: azx_get_response timeout

lines? Do you get any others? I get the following:

[ 29.322273] hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... [ 29.370224] hda_codec: Cannot set up configuration from BIOS. Using 3-stack mode...

as it automatically defaults to the "model=3stack" option.

I'm not sure of any way to ensure that a particular module parameter is getting accepted. It's a shame that lsmod and /proc/modules do not have this information.

In my looking around, I have also seen people report success with the "probe_mask=8" and "model=3stack" options. You might try either/both of these.

Perhaps you've seen this post:
http://www.crinisvilla.com/index.php..._MT6707_Laptop
He has quite a few options that he needed. Is this the model of your Gateway? He doesn't seem to have the card reader that you have.

Ok, I didn't exactly have to reboot. I reloaded the snd_hda_intel module and then "aplay -l" reports:

**** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: ALC880 Analog [ALC880 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem] Subdevices: 1/1 Subdevice #0: subdevice #0

... and sound doesn't work... and I get the azx_get_response timeouts. My only change was to remove (comment out) that "probe_mask" line in my /etc/modprobe.d/alsa-base file. Once I put the line back to normal, and reloaded the module again, sound was fine.

So, the output from "aplay -l" seems usable as a guage to determine whether or not the probe_mask option gets recognized, and the azx_get_reponse timeouts seem to be a good test to see whether or not the option is necessary. What does "aplay -l" say for you, now that you have the probe_mask option in /etc/modprobe.conf ?

In fact, with the probe_mask option in place, what do you get for "aplay -l" and "dmesg | grep hda_" just after booting up?

Originally Posted by Twinkel In fact, with the probe_mask option in place, what do you get for "aplay -l" and "dmesg | grep hda_" just after booting up?

dmesg | grep hda_ yields nothing. No errors. No results. Returns nul.

aplay -l returns

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem]
Subdevices: 1/1
Subdevice #0: subdevice #0

I tried probemask 1,3,8 and the 3stack. All yield same output (above).

My laptop is Gateway mx1023 (not a common linux system but very sleek)

The fact that all three different probe_mask options result in the same output from "aplay -l" seems a strong indication that the option is not getting picked up properly. Is it possible for you to copy and paste the line you're using from your /etc/modprobe.conf?

It looks like ( http://www.google.com/codesearch?hl=...hda_intel.c#a0 ) valid values of probe_mask are from 0-15, and that it does represent a bit mask of sorts, as the name would suggest. I imagine the only useful values to try for debugging are, therefore, 1, 2, 4, and 8. Using 1 works for me. Using 2 gives me my modem as the only viable playback device. Using 4 or 8 results in no sound devices for me.

Is it possible for you to "rmmod snd_hda_intel" (as root)? I find that I typically have to quit most of my sound-based applets and wait about 30 seconds for arstd to timeout before there are no more users of the module. If you can successfully do so, then you can try "modprobe snd_hda_intel -C /dev/null probe_mask=1" manually, to make sure the option is picked up (the "-C /dev/null" is to make it ignore your current /etc/modprobe.conf). Then, it could be relatively easy to try 1, 2, 4, and 8 for probe_mask... since you don't have to edit /etc/modules.conf and reboot every time (if that's what you were doing).

"rmmod snd_hda_intel" yields
"ERROR: Module snd_hda_intel is in use"

I made sure I had no programs running but this always happens.
I ran "modprobe snd_hda_intel -C /dev/null probe_mask=1" anyways but nothing changes in "aplay -l"

If the 'rmmod' command does not succeed, the 'modprobe' command will have no effect. You can test to see if the 'rmmod' command will succeed by doing "lsmod | grep snd_hda_intel", which will report two numbers at the end of the line. The second number shows how many users the module has, and must be 0 in order for the 'rmmod' command to succeed.

If you can't succeed in getting 'rmmod' to work, you may need to repeatedly reboot while altering /etc/modprobe.conf file. What does the pertinent line of that file currently look like?

(Note: the 'kmix' program will be counted as a user of the snd_hda_intel module if it is in your system tray)

Originally Posted by Twinkel If the 'rmmod' command does not succeed, the 'modprobe' command will have no effect.

Sorry for the long delay. Yes the sound module in the tray was the culprit. I tried again and got:
[root@localhost sbin]# rmmod snd_hda_intel
bash: rmmod: command not found
[root@localhost sbin]# /sbin/rmmod snd_hda_intel
[root@localhost sbin]# /sbin/modprobe snd_hda_intel -C /dev/null probe_mask=1
[root@localhost sbin]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
[root@localhost sbin]# /sbin/rmmod snd_hda_intel
[root@localhost sbin]# /sbin/modprobe snd_hda_intel -C /dev/null probe_mask=2
[root@localhost sbin]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem]
Subdevices: 1/1
Subdevice #0: subdevice #0
[root@localhost sbin]# /sbin/rmmod snd_hda_intel
[root@localhost sbin]# /sbin/modprobe snd_hda_intel -C /dev/null probe_mask=3
[root@localhost sbin]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem]
Subdevices: 1/1
Subdevice #0: subdevice #0
[root@localhost sbin]# /sbin/rmmod snd_hda_intel
[root@localhost sbin]# /sbin/modprobe snd_hda_intel -C /dev/null probe_mask=4
[root@localhost sbin]# aplay -l
aplay: device_list:204: no soundcards found...
[root@localhost sbin]# /sbin/rmmod snd_hda_intel
[root@localhost sbin]# /sbin/modprobe snd_hda_intel -C /dev/null probe_mask=8
[root@localhost sbin]# aplay -l
aplay: device_list:204: no soundcards found...



Same if I set the changes in the conf files and reboot.

Well... now I'm stumped. It would seem that probe_mask=1 (or any other odd number) should work, except that this setting seems to allow two codecs (instead of your total of 3). I'm wondering if sound apps are getting access to your digital audio output, rather than your analog audio (I assume you have your speakers/headphones plugged into the analog jack, rather than the digital... I believe the built-in speakers use the analog audio).

So, my running theory is that, given multiple subdevices reported by aplay -l, sound apps will default to the last one in the list... I don't know if that's true or how to prove it, but if you have access to some digital audio speakers/headphones you could try it out.

Apparently, aplay has the -D option which supposedly lets you pick the PCM device to use, and the -L option, which lists the PCMs defined, but I can't seem to figure out how to use these command-line parameters in a meaningful way that would allow you to try to shove a *.wav file out the right PCM (the analog one). Beyond that, I'm not sure how to get the usual sound apps to pick the right PCM, either.

Whatever the technique is for selecting the appropriate PCMs in general sound apps, that sounds like the better solution in general... better than the probe_mask option, that disables some hardware support for the purposes of forcing an appropriate default option.

I was going nuts trying to make sound work on my Dell Vostro laptop running Fedora Core 7. I tried a million options on snd_hda_intel in modprobe.conf, and I finally realized that I was not going to be able to make the sound work under kernel 2.6.22.

I built a custom 2.6.23 kernel and sound worked great - none of the module parameters were necessary since model=ref was automatically detected and probe_mask wasn't needed. If you aren't ready to build your own kernel, then just wait until your distro updates to 2.6.23.