For some obscure reason, the Wheezy installer did not correctly configure my hardware.
Firstmost the sound isn't working even though in a live CD it works. I have concluded after some research that I need to configure the hardware abstraction layers. If anybody knows any beginner information on these subjects, or could give me some glossary or guidance here, I'd be very grateful.
Secondly stand-by isn't working. I'm not sure how to debug or fix this, but I'm willing to go in deep to get this working perfectly.
I know you dislike beggers, but I'm running out of time, even though I spend all the time I can on this. Please, help quickly, it was supposed to be a birthday present.

about the standby:
how is it not working, when you try to invoke it manually or automatically after some time?
what desktop environment (if any) is installed?
what power management/screensaver?

as a birthday present (for a non-nerd?) i'd recommend a different distro, if you're in a hurry.

I run debian wheezy on my laptop. My sound doesn't work at boot because the sound modules do not load at boot. Although I tend to bypass the installer with my install methods.

# modprobe snd-intel8x0
# modprobe snd-usb-audio

In my case to get sound working I do the above modprobes as root. I could just add the modules to /etc/modules, but I don't really boot often enough to bother IMO. Just saying that the solution might be simpler than you're making it out to be.

Sorry for not responding earlier.
The stand-by issue is that it doesn't come out of stand-by properly: it "spins up", but screen is black and keyboard doesn't respond (to alt+sysrq+b etc.). I might be able to circumvent it by setting the stand-by to S1.
I'll try modprobe. The only applicable kernel module I can find is snd-hda-intel. Can I find a list of kernel modules somewhere with descriptions? This https://wiki.debian.org/ModulesAll seems terribly outdated.

Sorry for not responding earlier.
The stand-by issue is that it doesn't come out of stand-by properly: it "spins up", but screen is black and keyboard doesn't respond (to alt+sysrq+b etc.). I might be able to circumvent it by setting the stand-by to S1.
I'll try modprobe. The only applicable kernel module I can find is snd-hda-intel. Can I find a list of kernel modules somewhere with descriptions? This https://wiki.debian.org/ModulesAll seems terribly outdated.
Is there a chance a kernel module could fix my stand-by issue as well?
(append: desktop environment is xfce with some packages pruned off.)

Check alsamixer to make sure your sound isn't just muted.

Failing to resume from suspend is often video driver related - what are you using?

If you're referencing suspending a laptop, you need swap space to store the contents of your RAM while you're suspended. Hibernation is slightly different in that the system stays running, but does minimal stuff every couple of minutes to refresh the contents of ram so it don't lose integrity. Obviously if you suspend without swap, you basically have nothing to restore. Or I could be wrong.

$ find /lib/modules/$(uname -r)/ -iname '*.*o'
# modinfo <module_name>

Beyond that the kernel sources is littered with information. And the make menuconfig (or xconfig and others) gives you a decent help screen for some modules that you might select. The menu tree isn't exactly intuitive to anyone who's never been there before. Plus that whole source code plus build system requirement.

There's pciids.sf.net and other options to research your hardware vs. drivers / modules for them to shorten the list(s). Chances are that there's a pciids or similar file already on your system, albeit a dated copy.

$ lspci -n

1 members found this post helpful.

Thanks. I've found some candidates for the modules and will post results after I try them.
The stand-by I mention is AFAIK suspend to RAM.

So some harddrive failure and lots of work later...
The appropriate module seems to have been loaded all the time.This (and some other sites) mentioned adding a specific model to /etc/modprobe.d/alsa-base.conf would fix it.
Since it is not in this list the model would be "generic". (Also such a specific scenario was mentioned on-line.)
It didn't work for me, however. I've given the PC and am fixing things afterwards >_> Next step would be messing with the module parameters. I am however inclined to stick a PCI soundcard I was remembered I have lying around.

Not necessarily excluded from "this list" by merits of omission. The lists are generated from folks who gave enough feedback to be included in the list. Just because your model isn't listed, could be that no one else is using (or still using) that hardware, and running linux, and gave feedback to make the list. Most times these lists do not originate from the manufacturer(s) of the device. And are by no means a complete list of all existing models. Or an actively maintained list.

The udev, HAL, and DBUS processes shouldn't prevent sound from working. There are several alsa utilities that access alsa directly. Things like aplay, arecord, alsamixer, speaker-test, amixer, and others. Traditionally sound in linux is muted by default. So the first stop if the modules are loaded is to check the mixer settings. Then try to make some noise through the soundcard. You could need extra module level parameters for your specific card. But if it's loaded and working you probably do not need to take that extra step. Also note that changes to conf files in /etc/modprobe.d/ do not take effect until the next reboot. And other means to try parameters out without having to reboot.

It seems adding a line that says as per the linkdid work. After failing so many times, I was going by the grayed out mixer icon in the system tray. It seems to be a bug, but the icon stays grayed out.