Open bkoropoff opened 1 year ago
OK, there is existing sound precache code. Not sure why I'm getting stutter on first sound access, then.
When I added that precache it fixed the problem for some people but not for others. No clue what causes it
Well, while indeed the sound lumps are cached, the SFX that they contain are still not in the right samplerate/channels/bits configuration for SDL2_Mixer to feed to your hardware. What you need, though, is to cache the sound lumps converted to your sound hardware spec.
@fabiangreffrath any idea how to go about doing that? 😸 Does it work already like that in woof?
We had this in Woof before we did the switch from SDL2_Mixer to OpenAL Soft. What you will need to do, in a nut shell, is to load the sound lumps, convert them to your current format/channels/samplerate configuration, store this data in a buffer and feed this into the SDL Mixer.
A complete implementation of this solution can be found in our CacheSound()
function at this point of the code history, i.e. right before we switched over to OpenAL Soft. Please note that we use libsndfile to load non-Doom format sound samples, but I think there is already some solution in the PRBoom+ code base to load at least 16-bit WAV samples.
Second part, call CacheSound()
for every sound effect once at engine start:
dsda-doom is prone to stuttering when a lump is first accessed, especially if the wad file is on a spinning HDD. This is likely because it memory maps wad files, so data is read from disk just in time as the program accesses the mapped region. This can cause the main thread to hang while the disk spins up/seeks on first access of a lump. Options:
posix_madvise(..., POSIX_MADV_WILLNEED)
orPrefetchVirtualMemory