Graf Zahl wrote:About the slowdown, hard to tell, because it appears to be in both 1.0.27 and 1.0.28 so it cannot be SSE. Maybe the toolchain is set up to compile some stuff unoptimized? It's really the only thing I can imagine.
I didn't say that the performance issue is related to SSE. 1.0.27 doesn't use these instructions while 1.0.28 has the same performance with them.
I meant that we already experienced two independent problems with DLLs built by MinGW. And we are using only a relatively small subset of library's functions.
By the way GCC produces ABI-compatible binaries.
Crash in 32-bit DLL was caused by improper alignment inside stack which is a code generation bug.
Graf Zahl wrote:About the 10-30% advantage of FMOD, maybe that's because GZDoom's loaders perform an added conversion from float to 16 bit? If I understand the comments correctly, that was done to circumvent some problem with libsndfile (sounds somewhat familiar, doesn't it?)
The first culprit of FMOD's performance advantage is down-mixing to mono in OpenAL backend.
This especially important for 5+ seconds 44.1 kHz/16bit stereo sounds as they are loaded in OpenAL buffers twice.
I hope Chris
will handle this with a special OpenAL extension soon.
I'm not an expert in Vorbis library but it seems samples are handled as floats internally. So I guess this doesn't cause a slowdown.
Conversion of floats to shorts can be optimized too. At the moment I cannot say about its cost in overall processing time though.