OpenAL occasionally crashes in aluMixData() - and solution to it

[vedran-]

As title says, OpenAL occasionally crashes in aluMixData(). Easiest way to quickly reproduce it is to play and stop many sounds in short period of time.

That is because calls to SuspendContext() and ProcessContext() have been removed from function aluMixData(), so it sometimes tries to process the sound which has already been stopped/destroyed. Calls to SuspendContext() and ProcessContext() were there so threads could be synchronized when playing sounds. That is needed, as the same data is used in OpenAL main thread, in s3e callback thread (main s3e thread), and it can be also called from different application threads.

Problem is that s3e main thread, from which is aluMixData() called, doesn't allow any locking functions. And if you don't use s3e callback functions but your own thread to avoid that problem, you will have cracking sound - which is also not good.

So I have found a workaround - I have created worker thread for each channel which calls aluMixData() - and aluMixData() can then call SuspendContext() and ProcessContext() without problems, as it is not called from s3e main thread anymore. And that worker thread gets its data from s3e callback function, which then waits for worker thread to finish - but it doesn't wait via mutex or semaphore as that is not allowed, but via volatile variable and Sleep().

[madmaw]

Nice one dude, I'm not actively maintaining this project at the moment, but let me know if you need permissions to commit any code changes.

[madmaw]

Merged and, presumably, fixed

[vedran-]

Thanks, I think that should be it - OpenAL Soft 1.13 in itself is stable and shouldn't make any more problems.

I have tried porting OpenAL Soft 1.14 and 1.15.1, but it is pointless - they require even more thread locking and even atomic operations, which Marmalade doesn't support at all (for now). So I'll stick to this version, it has more than enough for what I need.