Revamp audiolib?

[malespiaut]

This is more of a discussion rather than an issue.

From what I remember looking at the audiolib code, it seems that this is a pile of old code that do things that SDL is supposed to do directly. Like, if I'm not saying anything wrong, filling a small sound buffer to read audio files chunk by chunk. While this is understandable as DOS wasn't handling anything back in the days, I wonder if that's a real necessity to keep that code, rather than using SDL directly and have a much more readable code base.

There might be some small issues, or decisions, doing this. For instance, how should audio samples be resampled? Using linear interpolation (so that'll make them sound muffled) or use nearest neighbor (so that the sound stays sharp and crunchy, like in the old days)?

[fabiangreffrath]

I'm all for getting rid of audiolib! It's just that it's knitted very well into the code, so this will be a major rewrite. Unfortunately, the code base by far isn't as organized as Doom's with its s_sound.c and i_sound.c separation.

[fabiangreffrath]

Resolving this to directly interact with SDL2_Mixer (or even openal-soft) will probably resolve #8 as well along the way.

[fabiangreffrath]

The current sound code is a mess and involves three layers of indirection: The SD_*() API in rt_sound.c calls into the FX_*() API in audiolib/fx_man.c which in turn calls into the MV_*() API in audiolib/multivoc.c et al which in turn calls into SDL2_Mixer's API by using a callback function in audiolib/dsl.c. 😖