I found that, due to the (perhaps unique) requirements of my UE4 project, the default UE4 integration did not meet all my requirements. Whether or not this is because of genuine limitations and not just me overlooking something, I figured I would share:
Game Objects Requiring AVolume-Derived Parents
A handful of game objects (e.g Ak Acoustic Portals, Ak Reverb Volumes, Ak Spatial Audio Volumes) are volumes (derive from the AVolume actor class, which derives from brushes). It turns out that brushes can't be created at runtime, as they require the editor modules, which are ideally to be left out of shipped titles. This means that I can't create these Wwise game objects in runtime. Additionally, per this design, most Wwise actor components (in exception to the Ak Geometry Component) require a brush parent actor - making it impossible to use them in custom actors without tweaking their code. This means that I don't just have to create a custom actor to replace brushes, I also have to create custom components for that custom actor.
Given that brushes are only used to obtain geometry data which is passed onto Wwise (at least as far as I could tell from the code) - this limitation imposes arbitrary constraints which actively prevent runtime spawning + updating of most Wwise game objects. It would be nice if instead, geometry acquisition can be virtualized. It is also my understanding that brushes are more on the deprecation side nowadays.
Lack of AKAUDIO_API macros on internal AkAudio types
Having to rewrite the way geometry is sent to Wwise, I ran into unresolved external symbol errors as I tried to make calls to internal AkAudio types (for example FAkGeometryData). This left me no choice but to edit the UE4 integration source code and resolve these errors by pasting the macro in (this one is an easy fix at least!). This post goes into more detail about the problem and solution: https://answers.unrealengine.com/questions/668941/unresolved-external-symbol-error-with-module.html
Custom geometry with AkGeometryComponent can either be static mesh or collision model - sometimes not enough
While we can use 'any' geometry we'd like - by attaching an AkGeometryComponent onto a dummy static mesh component hidden on our main actor - this quickly becomes expensive for the engine, both memory and performance wise.
Using the static mesh model can be really expensive. But, sometimes we also can't use the simple collision model. For example, this concrete tube needs to be able to roll around in a physical simulation (requires a relatively high-poly collision model, so too expensive for Wwise), and be hollow for the player (so appropriately hollow in Wwise scene):
The black boxes attached to it are virtualized geometry (an array of box defining structs). I couldn't use those boxes as the simple collision model as then the tube wouldn't be able to roll. This kind of constraint makes it difficult to use the AkGeometryComponent comfortably.
Ideally, users would be able to add a third 'custom mesh' to do this.
I completely understand if my usecase is a bit too quirky/niche for Audiokinetic to decide to leave those integration tweaks to their clients, but I figured I should still post these if this wasn't the case!