Determining memory usage
s_list will display a list of all sounds and whether they're currently in RAM, along with a summary at the end, e.g.:
0[16bit] : sound/weapons/mortar/mortarf1.wav[paged out] 53950[16bit] : sound/etpro/osp_fight.wav[resident ] 52808[16bit] : sound/etpro/osp_goat.wav[resident ] Total resident: 45634975 105060 bytes (0.10MB) free sound buffer memory, 50521500 bytes (48.18MB) total used 92463100 bytes (88.18MB) sound buffer memory have been allocated since the last SND_setup
This example is with com_soundmegs 48, and it shows that if I wanted to keep all the sound in memory, I'd want to shoot for soundmegs 96 or so. In reality, that's probably overkill (some large sounds, like the per-level voiceover in the limbo menu, are rarely used), but I'm pretty sure they're all loaded when you load the level, regardless (and just freed again if you use up soundmegs.) So, basically, a high-ish soundmegs is good, but setting it really high probably won't help much unless you have a really slow/busy disk but a lot of RAM.
Note that sample rate affects sound memory needs (s_khz 44 will use twice as much memory as 22, which in turn uses twice as much as 11).
Hunk and Zone
meminfo will display information about the hunk and the zone:
67108864 bytes ( 64.00 MB) total hunk <- current com_hunkMegs 25165824 bytes ( 24.00 MB) total zone <- current com_zoneMegs 0 bytes ( 0.00 MB) low mark 42606880 bytes ( 40.63 MB) low permanent 5864568 bytes ( 5.59 MB) low tempHighwater <- top low hunk usage from temporary allocations 0 bytes ( 0.00 MB) high mark 384 bytes ( 0.00 MB) high permanent 82624 bytes ( 0.08 MB) high temp 18769504 bytes ( 17.90 MB) high tempHighwater <- top high hunk usage from temporary allocations 42607264 bytes ( 40.63 MB) total hunk in use <- current hunk in use 18769120 bytes ( 17.90 MB) unused highwater <- temporary hunk memory that wasn't reused 2055832 bytes ( 1.96 MB) in 3088 zone blocks <- current zone usage 0 bytes ( 0.00 MB) in dynamic botlib 1110492 bytes ( 1.06 MB) in dynamic renderer 945340 bytes ( 0.90 MB) in dynamic other 82888 bytes ( 0.08 MB) in small Zone memory
(note the comments to the right of each line) So, the client uses a fair bit of hunk memory (adding together the total hunk and the unused highwater, my com_hunkmegs of 64 looks pretty good), a lot of sound memory, and very little zone memory.
The value of com_zonemegs can only be set via commandline (+set com_zonemegs xx). If set in the config, the desired value will only show as "latched." Regardless, meminfo always lists zone as 24 (the default), which would imply that this value cannot be changed.