Problem after updating to alsa 1.0.17

I’m running OpenSuse 11 with a emachines E510.

The sound card is: 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)

Everything was (almost) fine when I tried to make an update of alsa to version 1.0.17:

rpm -qa | grep alsa
alsa-driver-kmp-default-1.0.17.20081028_2.6.25.18_0.2-6.1
alsa-plugins-1.0.17.git20081028-1.1
alsa-tools-gui-1.0.17.git20080715-1.11
alsa-utils-1.0.17.git20081025-2.1
alsa-oss-1.0.17.git20080715-2.17
alsa-tools-1.0.17.git20080715-1.11
alsa-firmware-1.0.17.git20080617-2.1
alsa-1.0.17.git20081024-1.1
alsa-plugins-pulse-1.0.17.git20081028-1.1
alsa-devel-1.0.17.git20081024-1.1

But now, I’m getting the following error from dmesg:

hda_codec: Unknown model for ALC268, trying auto-probe from BIOS…
ALSA /usr/src/packages/BUILD/alsa-driver/pci/hda/hda_codec.c:3268: autoconfig: line_outs=1 (0x15/0x0/0x0/0x0/0x0)
ALSA /usr/src/packages/BUILD/alsa-driver/pci/hda/hda_codec.c:3272: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
ALSA /usr/src/packages/BUILD/alsa-driver/pci/hda/hda_codec.c:3276: hp_outs=1 (0x14/0x0/0x0/0x0/0x0)
ALSA /usr/src/packages/BUILD/alsa-driver/pci/hda/hda_codec.c:3277: mono: mono_out=0x0
ALSA /usr/src/packages/BUILD/alsa-driver/pci/hda/hda_codec.c:3285: inputs: mic=0x19, fmic=0x18, line=0x0, fline=0x0, cd=0x0, aux=0x0
ACPI: PCI interrupt for device 0000:00:1b.0 disabled
HDA Intel: probe of 0000:00:1b.0 failed with error -22

Thanks in advance!

I’ve made the changes proposed in SDB:Intel-HDA sound problems - openSUSE for an ACER lapto and the sound is working now, but the microphone is still not working…

Are you still getting the same dmesg error?

What changes did you make? Did you update your /etc/modprobe.d/sound file? If so, what is the contents of that file now? What hardware audio codec do you have on your acer laptop ? An ALC268 ? (per the dmesg in your 1st post ? ).

Are you still getting the same dmesg error?

No, no errors at dmesg now.

What changes did you make? Did you update your /etc/modprobe.d/sound file? If so, what is the contents of that file now?

Yes. Exactly this!
The new file is:

options snd-hda-intel model=acer enable=1 index=0
alias snd-card-0 snd-hda-intel
alias sound-slot-0 snd-hda-intel

What hardware audio codec do you have on your acer laptop ? An ALC268 ? (per the dmesg in your 1st post ? ).

I’m not sure how is the best way to see that, but after seeing the content of

cat /proc/asound/card0/codec#0

I’ve got

Codec: Realtek ALC268

as the first line.

Thank you for your help!

ok, try this instead (ie change the order of lines):

alias snd-card-0 snd-hda-intel
alias sound-slot-0 snd-hda-intel
options snd-hda-intel model=acer enable=1 index=0 

There is a bug in openSUSE-11.0 in the way it handles the /etc/modprobe.d/sound file.

Your /etc/modprobe.d/sound file looks like it was created by alsaconf. If the above doesn’t work, you could also try to configure your sound with YaST > Hardware > Sound, and then after YaST has completed recreating your /etc/modprobe.d/sound file, add the line “options snd-hda-intel model=acer enable=1 index=0” at the end of that file.

In the /etc/modprobe.d/sound file, you could also try some different ALSA-Configuration.txt options (for the alc268) instead of “acer”. Other options are:


	ALC267/268
	  quanta-il1	Quanta IL1 mini-notebook
	  3stack	3-stack model
	  toshiba	Toshiba A205
	  acer		Acer laptops
	  dell		Dell OEM laptops (Vostro 1200)
	  zepto		Zepto laptops
	  test		for testing/debugging purpose, almost all controls can
			adjusted.  Appearing only when compiled with
			$CONFIG_SND_DEBUG=y
	  auto		auto-config reading BIOS (default) 

ie instead of “acer” you could try “auto”, or “zepto” or “dell” or “toshiba” or “3stack” or “quanta-il1”. IMHO the options “auto”, “acer” and “3stack” have the best chance of working properly. Note you need to restart alsa after each attempt. The dmesg will provide a partial indication if the model option you have tried is no good.

ok, try this instead (ie change the order of lines):

alias snd-card-0 snd-hda-intel
alias sound-slot-0 snd-hda-intel
options snd-hda-intel model=acer enable=1 index=0

I haven’t noticed any differences…

There is a bug in openSUSE-11.0 in the way it handles the /etc/modprobe.d/sound file.

Your /etc/modprobe.d/sound file looks like it was created by alsaconf. If the above doesn’t work, you could also try to configure your sound with YaST > Hardware > Sound, and then after YaST has completed recreating your /etc/modprobe.d/sound file, add the line “options snd-hda-intel model=acer enable=1 index=0” at the end of that file.

I also tried that, but with no differences.
It’s important to say that the model “auto” is not working. When I use it, I got that error from the my first post in dmesg.

ie instead of “acer” you could try “auto”, or “zepto” or “dell” or “toshiba” or “3stack” or “quanta-il1”. IMHO the options “auto”, “acer” and “3stack” have the best chance of working properly. Note you need to restart alsa after each attempt. The dmesg will provide a partial indication if the model option you have tried is no good.

Very good. I haven’t seen all these options in the Alsa-Configuration.txt.
The best one is “quanta-il1”. It’s the only one that alsamixer works and also the microphone.

The only problem now is related to the headphone. Before this update, when I used the headphone, the speakers were mute automatically, but now it doesn’t work.

There is also a little mistake: the volume controls for speakers and headphone are swapped.

Thank you again!

This is reading like a bug with the latest alsa … You could raise a bug report here:
https://bugtrack.alsa-project.org/bugs/
and/or also raise a bug report on openSUSE, with guidance here:
Submitting Bug Reports - openSUSE

You could reference this thread in your bug report.

I believe it is possible to fix this, either by a special parameter at boot, or by a custom /home/username/.asoundrc file. For example, I have read of this problem with an AC97 (which I believe you do not have) in the ALSA-Configuration.txt file:

AC97 Quirk Option
=================

The ac97_quirk option is used to enable/override the workaround for
specific devices on drivers for on-board AC'97 controllers like
snd-intel8x0.  Some hardware have swapped output pins between Master
and Headphone, or Surround (thanks to confusion of AC'97
specifications from version to version :-)

The driver provides the auto-detection of known problematic devices,
but some might be unknown or wrongly detected.  In such a case, pass
the proper value with this option.

The following strings are accepted:
    - default	Don't override the default setting
    - none	Disable the quirk
    - hp_only	Bind Master and Headphone controls as a single control
    - swap_hp	Swap headphone and master controls
    - swap_surround  Swap master and surround controls
    - ad_sharing  For AD1985, turn on OMS bit and use headphone
    - alc_jack	For ALC65x, turn on the jack sense mode
    - inv_eapd	Inverted EAPD implementation
    - mute_led	Bind EAPD bit for turning on/off mute LED

For backward compatibility, the corresponding integer value -1, 0,
... are  accepted, too.

For example, if "Master" volume control has no effect on your device
but only "Headphone" does, pass ac97_quirk=hp_only module option. 

For example, specifying ac97_quirk=swap_hp in the options line of the /etc/modprobe.d/sound file would swap the two controls around for ac97 users. … I do not know what the alc268 equivalent would be.

Reference the .asoundrc file, I have read of users swapping left and right speakers with the file: infofiles - swap right/left speaker example
but I do not know the edit for swapping “speaker” and “headphone” volume control.

This is reading like a bug with the latest alsa … You could raise a bug report here:
https://bugtrack.alsa-project.org/bugs/
and/or also raise a bug report on openSUSE, with guidance here:
Submitting Bug Reports - openSUSE

You could reference this thread in your bug report.

I’m going to work a little bit more on this problem before sending to the tracker.

If I have some news, I’ll post them here.

Thank you for you help!

No solutions until today…
Bug “reported”: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4190