Yep, that's the menu. You highlight the first entry, then follow the instructions in post 6 to temporarily add
acpi=off (that's ACPI,
Advanced
Configuration and
Power
Interface) to the end of the line that starts with
linux /boot/kernel-version (what used to be the "kernel" line in legacy GRUB). This will disable power control features from the kernel level (like turning the monitor off).
As far as ALSA vs Pulse, they work together. ALSA (Advanced Linux Sound Architecture) is the interface that manages the sound card driver(s). Traditionally, you could access the ALSA interface directly if the application supported it. It also creates an emulated OSS (Open Sound System; single card and featureless predecessor to ALSA) interface for compatibility with older programs. ALSA supports multiple cards, plugins, and a simple stream mixer (very limited and not high quality). It also has a plethora of audio and sound card tools.
PulseAudio is what's called a sound server. PulseAudio is primarily associated with the Gnome Desktop (though it is not limited to it) and is meant as a drop in replacement for the previous Gnome sound server, Esound. KDE has a different sound server called aRts. The role of the sound server is to manage or mix sound from various supporting applications in a graphical environment so as to not tie up the sound card driver with one application, which can happen on older single stream cards (alsa will queue sounds, so when the application tying up a card is finally closed, you may get a chain of sounds following... kind of weird sometimes since the event that triggered them had long past). It generally does not happen either with cards that have multiple channel streams like the Creative SB Live series or when the sound server is working correctly. Another key feature of a sound server is the server part... since like with X you can run programs on a terminal across a network, a sound server lets you do the same with the audio.
One of the things I disliked about Pulse was that it adds an ALSA plugin that redirects a sound stream that's configured to go directly through ALSA and forces it through Pulse instead. As long as PulseAudio is working right, the theory behind this is sound; it keeps the audio resources available to all programs. When something falls silent though, it becomes a goose hunt to find out why, and in previous versions because of that plugin, sometimes the only fix was to get rid of PulseAudio so sending audio directly through ALSA worked again.
Many of those problems have since been fixed, so as long as you have sound in most programs, it may just be that you have to try and find why a particular given program is running silent. It may be a setting in the audio setup (To try in order: PulseAudio (if available), ALSA, and OSS). Failing that, leaving the output at OSS, you can try the
aoss wrapper to launch the app (will slow it down, but might actually work). First step is usually to google your application followed by "no sound". You're probably not the only person to have the problem and the experience of others can benefit you. Google is usually my consult when I come across a specific issue that I don't have personal experience with. Google is your friend (usually).
I hope I have explained your questions to a satisfactory level. I know I can get a little long winded in these posts. Good luck.
