-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stutter on first playback of sound effect #405
Comments
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? 😸 |
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 |
Second part, call |
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
The text was updated successfully, but these errors were encountered: