Basic thread safety question

I've written my own DirectSound8 implementation and load most of the sounds at game start into memory. As music in wav format can get quite big (20-30MB per file) I only load it when required during gameplay and free it after it has been played.
Even on my rather fast PC this leads to some stutter (loading from my custom container file from the hard disk, then CreateSoundBuffer and QueryInterface (which creates the final buffer)), which will be much worse on lower end machines.

Therefore - as DirectSound seems to be multithreading safe -, I both load the file in a separate thread (using fopen/... instructions and sys_malloc) and create the soundbuffer as well.
This seems to be working fine, however I want to make sure it's actually thread safe.

I assume sys_malloc(size) is just something like malloc(size+8) during development, which writes the sys_marker in the first 3 bytes and some security byte at 3(4) and after size.
When I google thread safety of malloc I get a bunch of "it depends" answers, such as here: https://stackoverflow.com/questions/855763/is-malloc-thread-safe
Are (sys_)malloc and free thread safe in acknex/ lite-C?
Using the forum search I've found that add_buffer seems to be thread safe, which probably does at least one malloc itself as well but I want to be sure.
Thanks.

Are you still using wav for music? Instead of mp3?

I readed that Ogg Vorbis is smaller and have better quality.

I use Fmod for sounds and music for some years. There you can easily decide what is loaded into memory and what gets streamed from disk.

I'm not using wav files "still" but again, ever since making my own DirectSound implementation. I don't want to use media_play so I'd have to decode mp3 myself before I could feed it into the sound buffers.

Ogg files are (/ can be) smaller when you use compression. Compressed audio is lossy audio, thus having worse quality (although on high quality settings rather unnoticeable). However, I'd have to use an ogg decoding library as well for that. I looked into it for a bit but didn't feel like implementing it.

Although frequently used, FMOD has a ton of issues (and used to have bad licensing for indies). Some projects are stuck with audio issues for months because of FMOD.

Previously I had used irrKlang (65 bucks license) which worked fine with automatic streaming/ memory management. There was a bug with the Windows/ DirectSound implementation though, messing sounds up when you played more than one instance of them at the same time. I had reported it and worked with the dev but he took over half a year or so to fix it, so I just wrote my own "sound engine".


It's all working fine, I just need to know that lite-C's malloc is threadsafe.

I remember using BASS DLL. I remember I didn't have any problems and licensing was affordable for indie projects. But this was several years ago, things might have changed.

sys_malloc does indeed allocate at least 4 more bytes and aligns to qword boundaries. As to my knowledge, in lite-C it should be thread safe.

Thank you for the response. I'll just go with it then and hope for the best.

@Firoball: Had not heard of that sound library before, interesting. It's notably more expensive than irrKlang though, so if I had to I think I'd rather use the latter again.