Thanks for agreeing with me, aschuring. :-)  However, the change for 126140 certainly won't benefit you so my previous advice of "wait and hope" no longer makes sense for some.  

This is a cascade of bugs and behaviors.

In bug 295136, FlagMan said, "If pulseaudio is the default sound sink and you are NOT logged into X, amixer will search the pulseaudio server but there is none running on the local machine. Therefore, the network will be searched for a pulseaudio server. Most likely there is none on the local network either, and network timeouts are set to high values, so this may take some time and is the symptom we are seeing."

MY THEORY (and I'm not too strong on my capture of linux sound, so beware): 

I think the root cause is in that first sentence -- the user is no longer logged into X, the pulseaudio daemon has been terminated when the user session ended, but pulseaudio is still sought by alsa tools.  So amixer, searches fruitlessly for the daemon and it has to wait for a network timeout every time its called, and it is called numerous times in /etc/init.d/alsa-tools as the script zeros and mutes channels.  (After the user logs out of gnome, I have also noticed a delay between the time that "gdm" appears ready for input and /usr/share/sounds/question.wav plays, which is played by gdmplay which is simply a script that calls aplay, another alsa tool trying to do something after pulseaudio has ended.)  

Finally, gdm.conf has this text, 

---Quote---
# Program used to play sounds.  Should not require any 'daemon' or anything
# like that as it will be run when no one is logged in yet.
SoundProgram=/usr/lib/gdmplay"
---EndQuote---

This points the finger at alsa-tools OR, and I think this more likely, the ubuntu user-session implementation of pulseaudio, and here's where my lack of knowledge about these ends my usefulness -- I don't know the implications of default sinks and whether the closing gnome session can and ought to switch audio defaults back and forth.  It should be noted that pulse's xsmp module is installed to load upon login, and never does.  That might have everything to do with this.

It is probably not a bug that the alsa tools looks for pulseaudio using network calls.  This is not only very common, it works fine when the network isn't searching DNS for the localhost hostname.  Even though many workarounds involve killing the network, or nfs, or uninstalling pulseaudio -- these are avoiding the symptom.  There might be a bug related to whether alsa tools seeks the network correctly, and how to do that in IPv4/IPv6 LAN has been the topic of much disagreement (see below).

SECONDARY ISSUES: 

It was found that listing localhost to :::1 in the IPv6 section of /etc/hosts avoided the long delay mentioned in this report.  

Some distributions, including Debian, include (or have included) that entry in /etc/hosts by default while others have not (including Ubuntu, apparently, starting with Hardy (bug 211537).  However, and this is important no matter which way this goes, several VERY POPULAR network applications that have bug reports indicating that they fail or misbehave when localhost is listed twice in /etc/hosts (these reports are older and are probably fixed).  How to handle localhost in lookups as everyone transitions to IPv6 has been the source of questions http://lists.debian.org/debian-ipv6/2008/07/msg00000.html and heated (and infamous) discussions http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980 and contradiction http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=427067 (seems to indicate that localhost ought to be listed in the IPv6 section, even though it means that localhost is listed twice). I have researched this question for days and can't find which answer is right.  However, as a result of this bug, and as observed by aschuring, my system ends up sending AAAA DNS lookups for localhost to the WAN.

However, even though localhost lookups for IPv6 might be a bug, fixing it only hides the fact that pulseaudio is not running when the alsa tools need to find it (the root cause bug).  It seems like when the user logs out and the pulseaudio daemon is not running, alsa tools should stop trying to find it.