People have very selective memory (remembering the good things and forgetting the bad things). This is very true for the first few years of being a parent. It's also true for sound support in Ubuntu. Every time I upgrade my desktop's version of Ubuntu, I seem to be effected by some odd unknown problem with my Intel HDA sound. I say "seem" since I have selective memory about having trouble with it. But the last few days have brought all the horrible memories of scouring forums and bug tracking sites from years ago. Each of which gives "advice" that potential only cripples a system in other ways. For example, installing some PPA that hasn't been updated, or using OSS instead of ALSA, or ALSA instead of pulseaudio. Let me immediately say that I don't fall for them, I only browse them hoping that someone has commented on them with some real help. I found the best summary of this problem in an article titled "Top five wrong ways to fix your audio." The problems stem from Canonical having two audio troubleshooting pages. The first one, "SoundTroubleshooting" is outdated and downright dangerous, then it says to the use the second page. The second page, "DebuggingSoundProblems", has no more than "is the speaker plugged in."
My most recent upgrade to 13.04 manifested itself as ALSA being fine and pulseaudio silently coming up with no devices. This was good since it eliminated a slew of problems with the kernel, which is where 90% of ALSA really lives and consequently problems with how the modules are loaded. The way I knew this was running "aplay -L" to see which devices ALSA knew about. You can also run "alsamixer", but it won't give you device names. The best diagnostic tool I found for ALSA was speaker-test, which can target any of the multitude of drivers available. I quickly learned that some process has taken over the default sound device, via a "Resource is busy" message. I'm still not sure why "lsof /dev/snd/*" did tell me which process was grabbing the device, but a quick scan of "ps aux" showed the culprit as Pulseaudio. Odd, since Pulseaudio was exactly what I was trying to get working.
The breakthrough was realizing that the owner of that Pulseaudio was a user called speechd, which I assumed was some sound daemon, but proved to an artifact of the speech-dispatcher package. It turns out that this package starts up early on, starts its own Pulseaudio and never gives it up. It didn't take long to know that I didn't need a speech library for Lisp. Uninstalling the package did fail, but a manual userdel and it was cleanly gone. A nice side effect of uninstalling speech-dispatcher is that Ubuntu starts up twice as fast, and now safely shutdown (which it couldn't before).
I'd like to believe that my diagnostics process was this clean. Not even close. There were hours of trying new kernels, snd_intel_hda settings, and pulseaudio configurations. At this point I'm expecting to have another sound problem come November, but hopefully there's one less way it can fail without me knowing how to fix it.