HP DC7800 - no sound from speakers (headphone working fine)

Hi all,

After trying at least a dozen distros, I’m a happy OpenSuse user now and hoping to stick to it for some time now. I am running it on HP DC7800 workstation and the performance is superb. One problem I have is that my sound is not working. If I plug-in the headphone to the front jack, I sear sound just fine but nothing from internal speakers. I tried a lot of threads and they talk about everything else in the world but not what I’m facing.

Here are some details:

maliks@maliks-suse:~> cat /proc/asound/card0/codec#0 | grep Codec
Codec: Analog Devices AD1884
maliks@maliks-suse:~> rpm -qa '*alsa*'
maliks@maliks-suse:~> rpm -qa '*pulse*'
maliks@maliks-suse:~> rpm -q libasound2
maliks@maliks-suse:~> uname -a
Linux maliks-suse #1 SMP PREEMPT 2009-10-26 15:49:03 +0100 i686 i686 i386 GNU/Linux
maliks@maliks-suse:~> cat /etc/modprobe.d/50-sound.conf

options snd slots=snd-hda-intel
# u1Nb.ET0nFMtnEEF:82801I (ICH9 Family) HD Audio Controller
alias snd-card-0 snd-hda-intel

Below is the link where I’ve uploaded my /usr/sbin/alsa-info.sh output:


Any suggestions on how can I make it work? If you need any more data, please let me know.

Thanks in advance.


From what I can see from the above, you have everything correct that you need for the AD1884 on your HP DC7800.

I did a search on the alsa site, and could not find any recent updates for the AD1884. I did note some Red Hat/Fedora and Ubuntu users raised bugs reports on their respective bug reporting tool that speaker sound did not work for them with this specific PC. I also note from the HD-Audio-models.txt file that there is no pre-defined model configuration that one can apply for force a model configuration upon boot for the AD1884.

I recommend you raise a bug report against openSUSE-11.2 on component “sound”. There is guidance here for raising such a bug report: Submitting Bug Reports - openSUSE … this will bring the problem to the attention of the SuSE-GmbH packager for alsa sound driver, who is also an alsa developer. If he finds the problem and fixes this, he is very good at sending the fixes upstream, and hence all Linux distributions will benefit from the fix.

As part of your bug report, please run the script:

/usr/sbin/alsa-info.sh --no-upload

which will create the file /tmp/alsa-info.txt. Please attach that file to the bug report.

As an extra note the alsa driver documentation has this to say in the HD-Audio.txt file for this type of problem:

**Speaker and Headphone Output

One of the most frequent (and obvious) bugs with HD-audio is the silent output from either or both of a built-in speaker and a headphone jack.  In general, you should try a headphone output at first.  A speaker output often requires more additional controls like the external amplifier bits.  Thus a headphone output has a slightly better chance.

Before making a bug report, double-check whether the mixer is set up correctly.  The recent version of snd-hda-intel driver provides mostly "Master" volume control as well as "Front" volume (where Front indicates the front-channels).  In addition, there can be individual "Headphone" and "Speaker" controls.

Ditto for the speaker output.  There can be "External Amplifier" switch on some codecs.  Turn on this if present.

Another related problem is the automatic mute of speaker output by headphone plugging.  This feature is implemented in most cases, but not on every preset model or codec-support code.

In anyway, try a different model option if you have such a problem. Some other models may match better and give you more matching functionality.  **If none of the available models works, send a bug report.**  See the bug report section for details.

If you are masochistic enough to debug the driver problem, note the following:

- The speaker (and the headphone, too) output often requires the  external amplifier.  This can be set usually via EAPD verb or a certain GPIO.  If the codec pin supports EAPD, you have a better chance via SET_EAPD_BTL verb (0x70c).  On others, GPIO pin (mostly it's either GPIO0 or GPIO1) may turn on/off EAPD.
- Some Realtek codecs require special vendor-specific coefficients to turn on the amplifier.  See patch_realtek.c.
- IDT codecs may have extra power-enable/disable controls on each analog pin.  See patch_sigmatel.c.
- Very rare but some devices don't accept the pin-detection verb until triggered.  Issuing GET_PIN_SENSE verb (0xf09) may result in the codec-communication stall.  Some examples are found in patch_realtek.c.

Thanks for the detailed response. I’ll do the needful.

Thanks again.