OpenAL Soft is an LGPL-licensed, cross-platform, software implementation of the OpenAL 3D audio API. It's forked from the open-sourced Windows version available originally from openal.org's SVN repository (now defunct).
As compared to FMOD's integration with Unity, Wwise's makes soooooooooo much more sense! From their Unity components, to Wwise Types for simplified access the API, or just straight-up API calls, it all just makes much more sense than FMOD's confusing and incomplete Unity component implementation. Too bad the documentation for this is sorely lacking and the Unity components waste too much UI space by wrapping every field in a frame for no apparent reason.
Which can also be fairly daunting to use as this forces stuff to be buried in tabs, popup dialogs, and other views. It is hard, for example, to see the big picture of a single event like you can in FMOD. But, it feels like you also have more control over details because of it. Thus, Wwise appears more geared towards hard-core sound engineers.
While there is plenty to read in their docs, there is not much help in for getting started with implementing game code. Particularly, with game engine integrations and best practices for working in different ways (components vs code vs both) with each. The docs in general are weak on crosslinking, screenshots, and example code. Some integration stuff simply isn't documented anywhere and requires trial and error in hopes to figure out. Well, their course materials have some more info but they are pain to try to use as reference material (very long and very basic).
How many languages are needed to write a game??? Python must be installed to convert Wwise_IDs.h to Wwise_IDs.cs. Really?! Shouldn't that script have been written in C# to begin with? Or, any other Unity-compatible language or DLL for that matter. Or, just skip the .h and later conversion and provide an option to generate a .cs file in the original function. How hard could that be? Then again, Wwise Types pretty much eliminate the need for Wwise_IDs.cs if you choose to use them.
Wwise Launcher is one of those pain-in-the-butt applications that wants to help you use the various features of Wwise but usually just gets in the way requiring more startup clicks than necessary to get things done. It logs you out at least once a day (even if you check "Keep me logged in") and can become uncooperative very quickly if you are not logged in. I have no idea why it is so demanding about being logged in in the first place. If you're working offline then parts of it will just spin forever leaving you unsure how what to do next. Expect to restart it regularly if you move around a lot. On the other hand, it handles things like upgrades and game integrations really well... but these are also actions that are rarely executed and don't need to be in a project-blocking application.
Lots of different shades of gray in the UI themes leads to poor contrast which makes the text and UI elements harder to read in both light and dark themes.
With Amplitude, assets are written in JSON files. It make them really easy to manage and edit. Most of the time there was not too may code to write after the integration in a game.
Compared to Wwise, for example, which splits the parameter curves that may be affecting your event into at least three different views, FMOD does a good job of flattening the hierarchy, simplifying details into nice UI gadgets, and presenting all this on one view. This may create a bit of a disconnect in understanding the hierarchy... but not really. Details may be hidden because of this but those probably aren't missed by your average developer. Showing the waveforms of the clips everywhere possible also helps. The contrast and readability of the UI is also nice.
The smallest chance of random play is 1%. This may be fine enough for most situations but if, for example, you have 20 clips to randomize and you want one of them to play 1:10 of the rest, you would need ~0.5%. And if you want an Easter-egg event at 1:100, you can't get even close to that. You'll have to do it in code instead of in the studio.
The instructions on how to set up events in Unity work for all events except one-shot events that need to respond to a parameter. These events should be implemented through code instead of using the FMOD Unity components (like you can for all other events). This makes no sense from a design point and is not made clear in any documentation. You might as well implement all of FMOD through code in Unity and ignore the clumsy Unity components.
Well, fully supported except for parameterized one-shot events through FMOD's Unity components, and lack of good getting started documentation showing best practices for various needs.
Easy to automate pitch bending with an RPM parameter, for example. Far easier to use and understand than Wwise's Smart pitch curve command. No idea which is more efficient, however.