#What is the most complete open source audio gem?

1 messages · Page 1 of 1 (latest)

rustic dragon
#

Hey @indigo elbow I have not tried ssamplitudeaudio or AudioEngineSoLoud, but the MiniAudioO3DE by AMZN-Olex is a great gem that I use. In my eyes the only two at this time is the MiniAudio gem and Wwise gem. Both being decent though the Wwise gem has more features, the MiniAudio gem is a great starter gem that can do audio but a lot of features are not implemented that the Wwise gem offers.

The other two have been out for a long time, but I am not sure if they are even up to date with the newer versions of O3DE or if they will work at all anymore.

sour spruce
#

Did you get MiniAudio to compile for latest build? I'm getting some errors, haevn't really looked into it though. I remember having it working on some earlier build, but they were just static sounds in 3D space, they wouldn't do any kind of spatialization back then.

rustic dragon
#

I have not used miniaudio for a while since before its last update, I know before its last update it worked, but now it may not because it fetches miniaudio instead of including it in the gem itself. I can possibly give it a try coming soon, but last time I checked you were correct @sour spruce miniaudio's newest version did not work with o3de.

cerulean birch
#

miniaudio on its own should be a complete header file, so even if there is no gem for it, iirc it should be the easiest to setup

sour spruce
#

The errors I had in setting this up was with the build process treating certain errors as warnings - I think some recent fix managed to get this working for me again. I'm not exactly sure where and what I would need to add in cmake configuration to change this compile behaviour myself if needs be, but a newer engine version now compile with miniaudio successfully

polar nest
#

I was able to get MiniAudio working with latest O3DE but I had to use the development branch of MiniAudioO3DE instead of the main one.

zinc vapor
#

I tried earlier with just the zip and trying to add it manually but I didn't have success. What was your setup?

polar nest
#

I'm on linux.
I was using a local built engine (and installer). I cloned the MiniAudioO3DE repo to some location, then used the O3DE Project Manager to browse for and register it so that it showed up in the list of gems.
When I tried to build, it failed.
then I switched it to the development branch (ie, executing git switch -d origin/development in the miniaudioo3de repo) and it worked for me with both installer and code verison of the engine.

#

Note though that I'm using my own installer build (built via cmake --build ... --target install

#

I tend to always start from the code of the engine since its pretty trivial to build (altho it takes a while, it kinda takes care of all of its dependencies cept cmake and a few others), so thats usualy my setup

polar nest
#

a lot of work should still be done to miniaudiooo3de.

I would love to see it expose the Audio Events system proper like wwise does, and then add some way to use the Script Canvas graph to deal with the logic behind them.

#

the wwise and underlying ATL system is supposed to be like "the game play person triggers event 'footstep' and thats where their responsibility ends."

#

the audio layer is then supposed to have 'footstep' be some input starting point into a larger system and the result may, or may not be, a series of playing of audio or mixer changes or whatever.

#

right now, miniaudio-o3de skips that and just exposes a direct "play this sound" component that plays the sound when told to

#

the audio trigger system is not used

#

a more ideal way would be for those audio triggers to instead still be valid but serve as say, script canvas graph node triggers that can then have logic and compute behind them and potentially result in playing of one or more audio, starting/stopping music, altering the mix or reverb parameters, randomizing selection, changing things based on distance, and so on, that way the audio person can live in script canvas node (or lua) land

polar nest
#

That wouldn't be a lot of work, tbh, since script canvas already exists and works fine that way, just a matter of hooking up the exisitng audio events (ATL) system with some entry points for script canvas graphs.

sour spruce
#

I had it working at one point, with the main version I was getting the warning-as-error compile fails, then it worked out; I updated the engine version again, and now I'm getting them again. I have no idea where in the build system the flag is being set, and I'd much rather not start editing the miniaudio libraries directly.

polar nest
#

what branch is your miniaudioo3de gem on though?

#

is it on development?

polar nest
#

I'll give it another try once I have a clean workspace.

sour spruce
#

No need to, the development branch of the gem works - I assume it's the fact that this branch uses "add subdirectory" instead of "ly_add_external_target_path" which causes the build system treat it differently?

#

The main branch gem not working, then updating the engine and working, updating the engine again and then not working, had me confused for a while

polar nest
#

no, I'm the one that submitted the switchup of the way the 3p stuff works for the development branch

#

basically, before the change, the external 3p libraries not part of MiniAudioO3DE (which are namely, miniaudio, and stb_vorbis) were actually part of the project and compiled into the project itself

#

after my change, I fetch them from their original sources, and treat them as external 3ps and compile them into their own compile units that don't include any other compile units

#

stb_vorbis does things like
#define L (something)

#

as well as many other global vars and defines

#

turns out if you include that in a compile unit with unrelated code that uses L as a template parameter, or R, or B, or many others, it will bork everything

#

so the difference between main and dev is mostly that one change I committed

#

shuffling 3p around, fixin up the licenses and basically isolating those external 3p libraries from the MiniAudioO3DE code itself, so that they can compile with their own flags and with out any other code

wind dome
polar nest
#

Perhaps it should be set to be the default one in the templates?

#

for next actual big relaese, I mean. Don't want to rock the boat in the short term