How to strip rpmalloc in Final builds and still retain AK::TempAlloc functionality in AkMemoryMgr.lib?

Question

We have noticed that there is some fine print around the rpmalloc open-source library that is incorporated into the Audiokinetic deployment software. 

https://www.audiokinetic.com/en/library/edge/?source=SDK&id=open_source.html

To avoid any presence of the rpmalloc code in a product, you should not link to AkMemoryMgr.lib or libAkMemoryMgr.a (found in $<Wwise>/SDK/<platform_name>/<Release|Profile|Debug>/lib/). This will ensure no element of the open source library is incorporated in the Audiokinetic deployment software.

We had previously ensured we were stripping the AkMemoryMgr.lib in final builds and re-implementing the AK::MemoryMgr interface in our client-side code in version 2022.  

However, we have now upgraded to 2023 and have noticed there is a new AK::TempAlloc interface that has been implemented in the AkMemoryMgr.lib

C:\Program Files (x86)\Audiokinetic\Wwise 2023.1.0.8367\SDK\source\SoundEngine\AkMemoryMgr\Common\AkTempAllocator.cpp

If we strip out the AkMemoryMgr.lib, to remove rpmalloc from our shipped product as described in the licensing documentation above, we end up with link errors related to the missing AK::TempAlloc implementation. 

However the AK::TempAlloc implementation does not appear to depend on rpmalloc, so we wanted to inquire on the best way to utilize the AK::TempAlloc implementation in our client-side code, _without_ linking to AkMemoryMgrl.lib.   After reviewing the source code, it looks like this system would be non-trivial to re-implement.

Note that we are currently working with our legal department on whether we are able to ship with rpmalloc, but it feels like the packaging up of critical internal memory management functionality into a library along with open-source code that is intended to be potentially stripped from the final product is not desirable. 

Specifically, what is the best practice if we want to strip rpmalloc, but still have access to the AK::TempAlloc functionality.

Any advice on how best to approach this issue would be most appreciated!

 

 

Answer 1

Hi,

Sorry for the inconvenience in this regard. The mixing of an open-source lib with AK-licensed code like this -- especially in light of the comment in our "Open Source Components in Wwise" documentation -- is definitely an oversight in our code structure.

For the near-term, I can note two or three options for you.

1) Proceed with inclusion of the rpmalloc compiled code anyway, since its license is so remarkably permissive.

2) Since you have access to the AkMemoryMgr source code, it should be possible to diverge the code locally to remove the contents of, and references to, rpmalloc.c/.h and rpmalloc_rename.h

2a) Alternatively, since most of the AK::TempAlloc details are all contained in its own namespace and files, it should be possible to move or copy the AkTempAllocator.cpp/.h files over to the AkSoundEngine project without much fuss, as well.

Do you think this will work out, or will you need another option to be proposed? We expect to have this resolved this in the next major release of Wwise, but we may pursue an intermediate solution for a patch release, as well, if required.

Comments

Hello,
No worries, thanks for confirming that this is a valid issue in terms of the code structure.  I'm hopeful that our legal department will give us the go ahead for rpmalloc and no further changes will be necessary from our point-of-view, but we will look into a variation of your suggestion 2a) whereby we can include the AK::TempAlloc source code into our client code for final builds, to satisfy the link errors we are seeing, if we are still required to strip AkMemoryMgr.lib in final builds.

Many thanks for your assistance.