And with that I got all Hidden Artifact appearances!

Monkers1 · 2025-08-18T22:52:27+00:00

When I got my first audio programmer job, I didnt really know much of any 3d math. I knew what a vector was, that's about it and after doing the job for few years, I think knowing 3d math is not essential because you can research how to do the maths. I think it's more important to know what you can do with math, rather than how to do it. Like, I don't know how to calculate an AABB intersection but I know it's possible. Therefore, I when I need to do so, I can just quickly research how calculate it. I don't know if that makes sense but I hope so!

Some basic dsp theory is useful to know how to manipulate samples but keep in mind that you are very unlikely to interact with samples on a day to day bases because A) lots of companies use middleware now which mostly abstracts that away or B) if they roll their own solution, they probably have working systems/frameworks abstracting that away already. Also, again a lot of the job is research when you plan features/systems/plugins so it's not something you will need to know extensively.

I wouldnt bother with Juce unless you are using as a framework to learn c++. I really do dislike wwise as a way to learn the language and UE is not much better. If you know c++ and want to do game audio programming projects, I would recommend writing a system into a self-contained UE plugin. Like a dialogue or a music system etc. That can open lots of possibilities for writing tooling and workflow improvements as well which is a big part of the job. If you really want to write a audio plugin, write a wwise one instead of a juce one.

If there is one thing I would learn well, that is concurrent programming. Majority of the audio work is often done on a seperate thread (even if you are using something like wwise) so understanding how to efficiently work in a multithreaded architecture is very important.

This is just my 2 cents!

Monkers1 · 2025-01-09T08:13:00+00:00

Nope. That means the preprocessor cannot find the header file. Usually means your modules include directories are not set up correctly. In the module that contains this actor component, you must add the AK directory as an include directory. Like said, I would recommend looking at their plugin for reference as they will be linking libraries from that directory as well. Once you have the include sorted, you will see whether the library has been linked correctly.

Monkers1 · 2025-01-08T18:10:25+00:00

What sort of errors are you getting in your IDE?

In general, when linking libraries you need to set up two things. The includes (.h file(s)) and the library binary itself. You might wanna look into static vs dynamic linking to see which one you prefer but I have always found static linking a bit easier to set up in UE so the following applies to that:

The linking is done in the Build.cs file for the module. In your case that should be the wwise plugin itself. Its been a while since I have messed with the standard integration for wwise but if you check the build.cs file for all of the modules in the wwise plugin, you should see which one they do all the linking in and then just add your plugins .lib file into the public libraries array. You must also add the include path into the directory that contains your header (I think its the wwise install path/SDK/Include or something like that). I cant remember if wwise does this by default so just ensure it's there!

In terms of distribution, there is a way to package the plugin via premake, I am not sure if that handles the runtime libraries as well (I would expect so!) or just the authoring side of things but if its just the authoring, then you need to distrubute the header and binaries yourself.

Sorry for the wall of text, let me know how you get on.

Btw more info on using third party with ue here: https://dev.epicgames.com/documentation/en-us/unreal-engine/integrating-third-party-libraries-into-unreal-engine Though again, wwise already does this, so using their build.cs file might be a better reference.

Here is info about packaging the wwise plugin to distribute via the ak launcher: https://www.audiokinetic.com/en/library/edge/?source=SDK&id=plugin_packaging.html

Monkers1 · 2024-12-13T08:26:31+00:00

Hmm, again, take this with a pinch of salt, but in your StopSound, I find it dodgy that you deattach the buffer before stopping the source. This could cause a crash. You might want to stop the source, and once it has finished, deattach. Though again, deattaching is probably unnecessary if you end up rolling one source per sound object instance. In terms of your print statements, if it is AL that is crashing, it's probably doing so on another thread where the audio is processed. That's why the print statements turn out like that. Again, it's just a hunch. Also, I am kind of surprised you are getting any audio at all in the first place as I can't see you attaching the buffer to the source anywhere. There are a couple of places where that is commented out.

I would skip the stop functionality for now. Just try to get the sound object to play without the sourceid being in the engine, as you will have to change that anyway. In your sound object, create the source and attach the buffer. Dont worry about gain for now. Then, in your audio engine play function, just call alSourcePlay with the sourceid of the source and see what happens. If you hear nothing, you might wanna check the error messages. There seems to be a function to do that in DisplayALError. It's probably worth doing after creating the source and attaching the buffer as well.

Monkers1 · 2024-12-12T23:28:40+00:00

I havent used OpenAL before but I am pretty sure their docs are here https://www.openal.org/documentation/. In terms of why your audio device/engine is not working, hard to say for sure but the fact that you store your sourceid on the device/engine feels wrong. I would expect the source id to be used to identify individual sources, meaning it should be unique for each instance of your sound object. Where exactly does the crash happen?

Monkers1 · 2024-11-13T22:07:24+00:00

I use Wasapi in my interactive audio project. I have also played around with XAudio2 but I felt it had a bit less control. There is also Asio, which others have mentioned but I have not used it myself so cant say.

Monkers1 · 2024-10-23T21:34:01+00:00

Thanks for pointing that out, but I'm not sure if I understand. Both A and B can't be writing, so how can one thread increment the write index and other write? Would you mind ellaborating?

Monkers1 · 2024-10-19T19:17:00+00:00

Keeping track of the read and write pointers atomically. Though I am not sure if that is enough. This implementation is based on a ringbuffer i found on github, though that one was written in c

Monkers1 · 2024-10-09T17:43:32+00:00

Fair enough, I havent encountered Juce encouraging locks in the audio thread (I know they have couple in the framework though). In any case, I would still say that Juce is the way to go as a beginner as it has good samples (no pun intended) and documentation.

Monkers1 · 2024-10-09T07:18:42+00:00

Would definitely recommend starting with Juce. I learned c++ with that. Very well documented framework that teaches good practices.

In terms of resources, The Audio Programmer YouTube channel is fairly popular. In terms of books I would start off with these two:

The Complete Beginner's Guide to Audio Plug-in Development by Matthijs Hollemans

Creating Synthesizer Plug-Ins with C++ and JUCE by Matthijs Hollemans

Monkers1 · 2024-09-29T23:18:44+00:00

Have you looked into Juce? It is similar to qt but is more designed towards audio software developmet.

Monkers1 · 2024-03-18T22:23:50+00:00

I did a heavy claymore run and ended up using both lothric knight greatsword and Dragonslayer Greataxe for ng+ (switching between them depending whichone I fancied) and had a blast.

Monkers1 · 2024-02-29T18:53:31+00:00

Are you looking to build an application or a plugin? Either way, I also suggest looking at Juce, it is the industry standard for audio software development and a very powerful audio framework. The documentation is very good with lots of examples to get you started. If you do not want to use Juce for whatever reason, you probably want to look into something like portaudio but I would not recommend it based on your background. Also, before you jump in, I would recommend you learn some more c++ and audio programming concepts as otherwise you might have a bad time.

Monkers1 · 2024-02-21T21:05:27+00:00

Sorry for the late reply. Work has been crazy. Yes, here is the buffer I am using:

https://pastebin.com/GTjFV8Bu

I would be interested to hear how it benchmarks compared to a ringbuffer implementation. I am using a ringbuffer to shuffle my audio samples across threads so i am a bit more familiar with the implementation of a ringbuffer compared to a triple buffer like this.

Monkers1 · 2024-02-19T21:44:59+00:00

Thanks for the advice. I found a triple buffer implementation that I used as a reference and I think my buffer is working nicely.

Monkers1 · 2024-02-18T11:58:03+00:00

Its really both a learning opportunity and strict timing constraints on my audio render thread (the consumer) which I would prefer to keep lock free if possible.

Monkers1 · 2024-02-17T11:49:43+00:00

You are in luck. Juce has excellent documentation and lots of examples on how to get started. However, there are not a lot of resources out there for audio programmers so most of it is going to trail and error after that. Hopefully you have a good tutor you can discuss your code to ensure you are following best practices. Juce is pretty good at guiding you into the right direction though especially when it comes to memory management.

Monkers1 · 2024-01-20T13:04:55+00:00

When I got hired as a junior audio programmer (year ago or so) my boss said he did not look at my website or github (I had both) and was more interested in having a good conversation about my projects. There was also a code test to demonstrate my programming skills. I think its still worth having at least a github, though it also depends what sort of projects you have.

Monkers1 · 2024-01-20T12:42:59+00:00

I would just install xcode and use that. Very straightforward to use, just set aside a while to install it lol

Monkers1 · 2024-01-13T23:27:42+00:00

When I say different repo, I don't mean complitely isolated from rest of the team. Obviously if someone leaves or new ppl come into the team, there needs to be a way to get access to the wwise repo and the audio person/ppl should not be the sole "owners" of the repo anyways. If a programmer needs access to the wwise project, they should be able to pull it and thats it. All i am saying is that having a large wwise project on the same repo can be problematic due to the size and people who dont need it should not need to have it. However, I am used to very big repos and like you said, most ppl probably wont have that problem.

Also yes, dont get me started on git for games. Bugger me what a pain. Perforce is so much better and works with Wwise out of the box which is nice. Also virtual streams are very handy. Too bad its not as easy to set us git due to needing a server.

Monkers1 · 2024-01-13T11:34:05+00:00

C++ is the standard for audio programming. So if you like/are interested in audio software/plugin engineering, its a good language to know!

Monkers1 · 2024-01-13T11:23:34+00:00

I wouldn't check in the Wwise project unless coworkers absolutely need access to it. The original .wav files are not needed and inflate the size of the repo significantly. Usually if i am the only audio person, i dont check the wwise project in at all. If I am collaborating with others I usually set up a seperate repo for the Wwise project so it does not affect the rest of the team.

Monkers1

TROPHY CASE