Reverb with OpenAL in windows build

Hi OpenFLians!

I’m working with somewhat advanced audio features and currently having issues with OpenAL use in windows builds: reverb is not working. I mean it looks like it’s created, but I can’t hear it, it’s not there. I’m at a loss, since it’s working on neko builds.
Other effects seem to be working ok. Switching the standard reverb for the eax one makes the game crash a few milliseconds after reverb creation.

Do you have any tips on how to make this work?

That’s strange, it works on Neko, but not on Windows C++?

What methods do you call in the OpenAL-Soft API to create the reverb? Perhaps we can inspect the bindings or other code to see if there’s something that HXCPP and Neko might treat differently

That’s strange, it works on Neko, but not on Windows C++?

Exactly.

What methods do you call in the OpenAL-Soft API to create the reverb?

Nothing extraordinary really in the creation part:

aux = AL.createAux();
var fx = AL.createEffect();
AL.effecti(fx, AL.EFFECT_TYPE, AL.EFFECT_REVERB);
AL.effectf(fx, AL.REVERB_DECAY_TIME, 5.0);
AL.effectf(fx, AL.REVERB_GAIN, 0.4);
AL.auxi(aux, AL.EFFECTSLOT_EFFECT, fx);

And then, to use it, it’s a matter of getting a NativeAudioSource backend from a SoundChannel and playing it through the aux.

var source = @:privateAccess soundChannel.__source;
var backend:lime._backend.native.NativeAudioSource = @:privateAccess source.backend;
AL.source3i(backend.handle, AL.AUXILIARY_SEND_FILTER, aux, sendIndex, AL.FILTER_NULL);

Can’t see why OpenAL would act differently in a windows build.

It might be the AL.source3i call.

aux is not an Int, but a CFFIPointer. The parameter appears to be dynamic on the CFFI side in C++, but not here:

Does it work differently if you change value1 to Dynamic instead of Int?

All right! That worked! :smiley: thanks @singmajesty, you had the perfect answer, as usual :wink:

I made a pull request for the master branch.