Comment 158 for bug 946232

Revision history for this message
The_Letter_J (the-letter-j) wrote :

Please add this machine to the list impacted:

Malibal Veda P180HM , aka Clevo P180HM , aka Sager np8180 (other rebranded flavors of this model also exist).
RealTek ALC892 internal speakers fail to show up in sound-settings;
instead the not-plugged-in iec598 aka S/PDIF output becomes default-sink.

Using the workaround from comment#32 corrects the trouble for my hardware. I have composed a brief shell-script which I believe can be cut-n-pasted into the xterm, rather than having folks perform manual editing. Worked for me on 12.04.3 with all updates but I have only tested it on this one machine. David, or other canonical employee, if this looks useful you might consider pasting it into the intro at the top, or as an addendum to comment#32.

BEGIN_CUT_N_PASTE_BLOCK_HERE

aplay /usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf

cp /usr/share/pulseaudio/alsa-mixer/paths/analog-output-speaker.conf ~/tmpUspapaos.bak
grep -v "required-any = any" /usr/share/pulseaudio/alsa-mixer/paths/analog-output-speaker.conf > ~/tmpUspapaos.conf
sudo cp ~/tmpUspapaos.conf /usr/share/pulseaudio/alsa-mixer/paths/analog-output-speaker.conf
grep "required-any = any" /usr/share/pulseaudio/alsa-mixer/paths/analog-output-speaker.conf

cp /usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf ~/tmpUspapaiim.bak
grep -v "required-any = any" /usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf > ~/tmpUspapaiim.conf
sudo cp ~/tmpUspapaiim.conf /usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf
grep "required-any = any" /usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf

ps aux | grep pulse | grep -v grep
pulseaudio -k
ps aux | grep pulse | grep -v grep

aplay /usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf

FINIS_CUT_N_PASTE_BLOCK_HERE

In my particular case, the symptoms were not exactly as described, from what I can garner. I installed 12.04 from LiveUSB a couple months ago, and had no audio-playback (except in the bootloader via grub's play-command) until I had updated to 12.04.2 -- after which I was able to hear the drum-sound at the login-screen that appears immediately after boot.

However, once into the desktop, I was not able to accomplish playback. When I would open up sound-settings from the taskbar (aka "gnome-control-panel sound-nua" under the hood), the only listed internal speakers were S/PDIF output. The laptop does have an spdif-out-jack, but nothing was plugged into it. Clicking on most any of the buttons in sound-settings would cause the not-even-plugged-in spdif-out-jack to become the default audio-sink. So to be clear, I did not plug in external speakers or headphones or microphones -- there were no internal speakers in the list provided by sound-settings, from what I can tell (ever at any time).

I believe following the instructions of step#1A over here helped -- https://help.ubuntu.com/community/SoundTroubleshootingProcedure -- because when I executed killall pulseaudio; rm -r ~/.config/pulse/* ; rm -r ~/.pulse* then counted to fifty then rebooted, I was able to achieve mp3 playback in rhythmbox. There were still no external speakers listed in sound-settings, and any time I messed with sound-settings it would change my default speakers from the (invisible to it) internal speakers to the spdif-out-jack, necessitating a reboot. From the instructions in this thread, I have determined that it is possible to perform pulseaudio -k , as opposed to rebooting, which corrects this particular problem reliably, at least.

As previously mentioned, applying the tip from comment#32 fixes my problem -- I now see 'built-in audio' internal speakers within sound-settings. I also applied the microphone related workaround, although I do not know whether or not my box suffers from that difficulty (I do not use an external mic at the moment).

While I was fiddling with trying to debug this vexing problem, I did find the following indicator which reliably told me when I had lost my default speakers, and switched over to outputting sound to the non-existent spdif-connected-hardware. When I first logged in, I would run this command:

lsmod | grep -P "^snd_hda_intel"

and then make a note of the UsedBy number in the third column, typically the numeral five. Once I lost my audio, due to fiddling with sound-settings, I would instead see numeral six (the spdif endpoint presumably). Running the killall workaround would put the number back at five where it was originally, and audio would work for a bit thereafter.

p.s. This was a dastardly difficult problem to track down. There are a couple things I would suggest for David and/or some other Ubuntu employee with commit access, to help endusers over this hump. First of all, a simple fix, pleas list the audio-chipsets in this bug, not just the model-names of the computers. Clevo P180Hm w/ RealTek ALC892, in my particular hardware. Most forums recommend that you search for your audio-chipset, not for your model-and-vendor, but this bug does not show up thataway currently.

Second, because in at least some cases (mine for one) the bug manifests itself as refusing to display valid information, it was difficult for me to figure out what was going on. It did not dawn on me that my sound-settings applet might be lying to me about what hardware was avaialble for output and input, until *quite* a lenghthy struggle had already passed. I realize that pushing functional changes into LTS releases is frowned upon, of course.... but as David's SRU points out, this is quite the maddening bug, which intermittently prevents listening to music, voice-chat, and other Gotta-Work-All-The-Time features. I'm suspicious that there are plenty of folks out there that *know* their audio is busted, and either change distros -- I ran across at least three such cases with just ALC892 hardware alone in the forums -- or live with the problem. My suggestion is this: push an update to gnome-control-panel (or whatever package contains the ubuntu sound-settings dialog-box), and modify one of the text-labels on the Output Tab and the Input Tab, to alert endusers there is a fix for their pain. Something quite brief, like the following, would suffice:

Do not see your speakers? (with a hyperlink that takes them to this bug-report)
Do not see your microphone? (again with the hyperlink)

These would need to be translated, and verified to fit in the available pixel-real-estate of the dialogbox in question, but methinks it could be done without violating the spirit of an LTS release. Failing that, backporting David's 3.6 kernel fixes to the 3.5.0.41-series that is currently in use with 12.04.3 seems the only way to fix the root cause. In any case, thanks to David for his hard work, and thanks to others for helping me solve my local difficulties. Glad I finally have reliable audio.