TBH I'm starting having doubts that using OpenAL interface in general is a good idea for AGS project. It came as a part of the SDL port done by Nick Sonneveld, and which we decided to use, and I trusted this choice; but the more i looked into it on my own, the more potential problems I saw. I think the biggest is that it's another layer of complexity which we cannot fully control. Good example is playback "Speed" property: it appeared OpenAL does not have a direct equivalent for it, so I had to implement it on top by resampling the sound data. The sound is "sped up" before passing into openal, but because we must buffer at least couple chunks of data there all time, there's a delay at which the "speed" parameter is applied to the output sound, and that delay depends on the size of this buffering. In Allegro4 it was applied for the very next played chunk perhaps at the very end of the data chain before it goes out to the sound driver, so almost immediately. I'm having concerns that situation may become worse if we decide to implement more sophisticated sound system in AGS script, with mixers, and so on.
Note that mojoAL uses SDL2 internally, which we also use directly in the engine, so the question to ponder is, what use is OpenAL for us, and how it will work in perspective.
If it's actually useful, perhaps there's a proper way to "extend" it ourselves and let us control the sound closer to the final output.
Personally, i used ffmpeg before and liked its "filter" design, where sound transformations may be applied freely at any stage of the data processing. Compared to that, OpenAL is a "black box" with everything which connects directly to the output.
