Hi,
STW uses the regular sound pool, not the camlorn wrapper. When I get home, I'll look at your code, I'm at school right now.

I tried it out knowing that information, but thanks

For me, the example that came with the BGT wrapper reliably crashes after playing 256 sounds. I'd probably look into how handles are disposed of when they stop playing (I seem to remember that BGT's sound_pool resets them by setting them to null, rather than reusing the same object, but I didn't check to see if Sam's camlorn_audio version does the same.).

V1.17 of what?  if it wasn't V1.17 of OpenALSoft, then the wrapper is doing a ton of additional work: I do not believe it is possible to do that properly.  I had to hack OpenALSoft to even get it working without setting up the INI in the first place, and the key word here is hack.  You can technically loop over all sources and do it that way, but I'd be highly, highly suspicious of anything else.
The rest of this is from memory and I'm going to apologize in advance for inaccuracies.  I haven't touched camlorn_audio in almost 2 years.  OpenALSoft may have fixed some of this, but I doubt it.
But regardless.  The big issue, the one that I don't believe is solvable: I was convinced at the time that it was a good idea to transparently cache sounds, after decoding them to float32.  Unfortunately I don't believe I ever implemented a way to clear this cache.  This means two things.
First, assuming you can load all the sounds in the first place, something like Swamp would eventually take near 2 GB of Ram.  Float32 is going to be twice the size of most wave files, as usually they're signed 16-bit PCM.  If you want to know about how much ram it's going to need, convert all your sounds to .wav as 32-bit signed PCM and add up the file sizes.  This means that you've just excluded tablets or low-end machines for any sizeable projects.  it will run until enough sounds load, and then it will have no more Ram and come crashing down.
Second, there is indeed a limit inside OpenALSoft as to how many buffers you can have, and as I recall this is quite low.  I might or might not have provided a way to change it.  When you hit this limit, you might get an error report.  If you hit this limit and you are using the streaming functionality (which is needed to make music not take hugely big chunks of ram), it will probably outright crash because OpenALSoft error handling is not threadsafe; the error will be seen by the threads that do streaming half the time.  In fact I wouldn't use streaming at all, it generates error codes which can pollute the main thread too.
As for the HRTF not working for some people, OpenALSoft does not contain a resampler of high enough quality that you can apply it to an impulse response, and OpenALSoft is old enough that using a few trigonometric functions was considered scary and a bad thing.  Consequently you have to distribute an HRTf dataset for every individual sampling rate that you would want to support and do something or other in the format string that you pass to the camlorn_audio init function to tell OpenALSoft how to find them.  Unfortunately the tool to generate them does not support above 96khz.  While hardware above 96KHZ is not common, it's not really rare either, and you simply cannot get HRTF working on it via OpenALSoft.
Now we turn to the G930, which can't have HRTf working on it because it shows up as a 7.1 device and the lowest latency backend is Wasapi, so you need to turn Wasapi off or everyone with a G930 isn't going to get HRTF.  OpenALSoft doesn't implement a full mixing matrix setup as I recall, so it can't downconvert, and Windows Wasapi won't do it for you.  The G930 is, as I understand it, a very popular headset in the blindness community.  You will however have similar issues on many of the higher end wireless headsets as showing up as a 7.1 device is now pretty common.  yes, Winmm and Directsound are very high latency backends.  Configure them to not be, and wait for someone with Bluetooth headphones to try playing, whereupon you'll just end up turning it up, probably to around 100 mS before you hit everyone.
Finally, performance.  Don't count on more than 15 active sources of audio, most blind people do not have really high-end machines and I say again tablets (which are the least expensive option for new computers, in a community that is primarily using welfare ).  OpenALSoft was written around 2000 originally.  This means that it contains a huge amount of "optimization" that is no longer applicable in any way to modern hardware, primarily because compilers got very, very significantly better.  After sacrificing a whole lot of quality internally, it still manages to be an order of magnitude slower than Libaudioverse; this is primarily because it decides to do a whole lot of clever stuff with integer math and the like, as well as failing to separate concerns in a manner that would let the compiler automatically vectorize and whatnot.  And so modern processors trip on it and modern compilers don't do a super job at optimizing it, and you're left with a library that manages to sound okay and have some cool effects while sucking in basically every other aspect.
All this put together is why I abandoned it.  If you want to offer a quality experience based on OpenALSoft, drop Camlorn_audio as the intermediate layer.  This will get rid of some (but not all) of your problems.  Then, work around the rest in OpenALSoft.  You will not hit them all without a good amount of effort.
The right answer for free projects that want 3D audio in BGt is nothing.  It will continue to be nothing for some time, though I imagine that someone will eventually write something on top of Libaudioverse for it.  I did not abandon camlorn_audio because it worked, I abandoned it because it didn't, and there wasn't really a way to make it do so even if I were to throw all the code out and start again.  I know this isn't what people want to hear, and I find it ironic that Camlorn_audio gets life 2 years after I abandoned it.  But that should be the complete list of problems, and if this still sounds like something you want to use, go for it.  I consider it ill-advised, but I can't stop you (though the source is no longer available publicly).

Hmm, looks like he did fix some stuff.  Unfortunately upgrading the version Camlorn_audio uses is not possible.
I know that it's the only option for commercial projects.  But let's be honest here.  Would you really want to buy a commercial project that used something that's so fragile it breaks when you breathe on it wrong?  Do you want to be the one offering it?  Given just how few commercial and first-person audiogames are going on these days anyway, it's really kind of a nonissue; HRTF is not very helpful for side-scrollers and similar.  But the point stands.  I would never sell something that used Camlorn_audio, and I'm the one who wrote it.  Libaudioverse might go MPL so that's something, but BGT is too limited to bind anything actually good because he apparently didn't use libffi, or if he did he didn't expose 90% of it to you.  I really strongly suggest using OpenALSoft directly if you're going to insist on doing this, and you're probably going to need to fork it and hack the code to not use the ini as I did for Camlorn_audio.
If you want to make your own, you're going to need to have gone at least as far as trigonometry.  If you've got a good understanding of trig and a good grasp on complex numbers, that might be far enough.  More realistically, going as far as Calculus 2 is helpful, as a lot of the stuff you'll be dealing with is derived from analog filters, and those need you to know enough to not be scared off by the laplace transform.  Despite it being used sometimes, I've managed to make it pretty darn far without ever taking a class on linear algebra; the only place that really came up was for reverb design, as feedback networks are the easiest way to get something that sounds good.
Once you're confident enough in your math skills, you need to learn at least C.  I suggest C++, namely C++11.  C is kind of awful for anything with nonobvious pointer relationships, and C++11 gives you enough stuff that you can generally not leak memory like a sieve.  Using a garbage collector is not an option, garbage collectors may try to preempt your audio threads.  You need to be comfortable with threads as well, and good at Googling stuff.  You'll probably want CMake.  I absolutely wouldn't use Purebasic or any of the other native languages, not even the popular ones; C++ compilers have 30 years of everyone in the industry adding optimizations, and you're going to be able to hit most of them.  To give you some idea of how fast you have to be, an HRTF source in Libaudioverse with default settings needs something around 22 million math operations a second.  This can be reduced some with mathematical cleverness, but you want to lean on your compiler as much as possible, and you'll probably want to learn SSE at some point down the road.
Next, learn Python.  You're going to need Numpy and Scipy to do some data munging.  Google the diffuse MIT kemar dataset, download it, and convert it into whatever you need.  Libaudioverse embeds the dataset directly, via a Python script using Jinja2 to write a C++ file that contains it as an array.  But the point is that it needs to be super super convenient to distribute the HRTF; nothing can be allowed to go wrong with finding the data.  As you go further, you'll eventually need Numpy and Scipy to do other stuff; it looks like the gold standard might be a minimum-phase filter and computing some bits at runtime, but I haven't tried it yet.  Regardless, you're going to want an accessible science stack at some point, and pretty much the only option for that is Python.
Now that you've come to terms with all that, you can get as far as an HRTF using this textbook, and this one will get you as far as reverb.  These are using LaTeX alt text for the math, so you'll need to be somewhat comfortable with that.  Even if MathML resources existed, Mathplayer falls hard on DSP stuff, at least in my opinion; if you can find some and have a braille display, that might be reasonable, but the speech is way too verbose.  You can supplement those textbooks with various Wikipedia articles.  The ones on convolution, circular convolution, and the fast fourier transform are particularly useful and important.  If you want alias-free analog waveforms, then also look at the dirak delta, the dirak comb, and the dirichlet kernel; these can be used to efficiently synthesize a bandlimited impulse train, which is an important building block for those.  Wikipedia's list of trig identities can also be helpful from time to time.
A basic HRTF mixer including file loading and audio output will be 2000 to 5000 lines.  Libaudioverse is around 15000 lines and growing, though admittedly it does way more than just games at this point and it's got a lot of additional stuff that allows me to not have to maintain bindings and gives lower latency audio.  If you use C++, I have audio_io on my GitHub; that's not GPL and will eventually make it into NVDA as well.  Audio_io can save you a bit of screaming in frustration.  It just does the right thing.  Things like PortAudio have atrocious latency on Windows.
And that's pretty much everything you need to know to duplicate my path.

Angelscript is technically suitable if someone adds the things that need to be added, but Angelscript has so close to zero market share as to be inconsequential.  Everyone uses better and faster things for their actual scripting engines.  V8 and Luajit are very popular
The only platform I've ever heard of that uses Angelscript for something standalone is BGT.  For that matter, it's the only thing I know of that uses it at all.  The problem is that BGT fails to support threads and the ability to be called from C (you can call out. C can't call back in).  I designed Libaudioverse in such a way that it can integrate with a garbage collector, but this means that a proper abstraction needs these things for object deletion.  It looks something like the flyweight pattern and the proxy pattern, for anyone familiar with those terms.  Other libraries will have more problems than mine, honestly; BGT's FFI falls short of binding half the software, at least as it's documented in the help file.  Maybe there's more that just never got written down, but everyone else these days uses Libffi for it and therefore supports basically everything (and if they don't, someone has probably written a libffi package for it, i.e. Java).
I don't use the Visual Studio IDE.  I don't use Jaws because Jaws does all sorts of weird things to me on a regular basis, so I'm on NVDA.  I prefer NVDA for lots of other reasons, but needing to use a dongle with Jaws and being told it was my fault was the last straw.  I've been complaining loudly at Microsoft for a long time about VS accessibility on Twitter, but nothing ever happens; the reason Jaws works is because jaws has a mirror display driver and does who knows what to get around the fact that MS can't be bothered to properly expose their own product through their own accessibility APIs.  It's good that you're reporting, as Visual Studio is very important for employment, but the debugger is probably the biggest problem and they've known for at least 2 years at this point (their response to me was that they didn't have time).  Since I'm doing nominally cross-platform development, the IDE is fortunately not that important, and I hold out some hope that they're changing.
My workflow is CMake via the jom generator.  Jom is a makefile thing from the QT project, and CMake can output files for it.  Unlike MSBuild, it gives much less spammy output and, ironically, builds about twice as fast.  This is a completely command line setup.  I use CDB, the little-known Microsoft command line debugger.  CDB is cryptic but insanely powerful considering, and gets the job done; in DSP land, debuggers aren't overly important anyway.  I think it's a nice setup, though CMake can be a bit different when you first learn it (but o, is it powerful).  CMake has some preliminary support for Windows 8/10 apps, Swift on OSX, etc; I'm not sure on the state of all of it, but they have tests in the official repository for them.  Not to mention working the same on Linux and Mac.  CMake is what LLVM uses for one, and that's probably one of the biggest projects out there now.  Because of the science stuff and the custom bindings generation, the Libaudioverse build process also uses custom build steps to call out to Python scripts for a good chunk of stuff, but that's not really general to all projects.
I need to put up side-by-side Libaudioverse to OpenALSoft demos soon.  I suspect Libaudioverse is better by a significant margin, but I've never done the listening tests.  We'll see, I guess.  If I can spin a Kickstarter or a Patreon or something, I want to take Libaudioverse MPL; I have to get money for it somehow if at all possible, as it's already taken a year and a half and it's probably got another year to go before I can nominally call it done (there is a lot of stuff I want to add. HTTP streaming, Midi and soundfont support, etc).  But I don't see making more than $50k from it if I go commercial, and if I go MPL then I can quite possibly get all sorts of contributors who do DSP as their research area and whatnot, who knows.  Believe it or not, there are not that many things like Libaudioverse, not even for researchers.
If you do go OpenALSoft, you need to figure out what you're doing about the ini, but as you know some C that may not be a problem.  It used to respect the ini before anything, which caused no end of  trouble.  If I had to summarize, the problem is that the developer would not concede that OpenALSoft is anything but a software replacement for a sound card, and expects you to program to the same constraints the "real" OpenAL wants you to, now long dead for all intents.  That is, as opposed to being able to drive it completely as a library and specify everything yourself, etc.

Most on-topic bit first: it probably does respect the ini first for all the stuff you still can't set at runtime, which is probably still a significant amount of things.  I'm thinking resampler quality, forcing stereo as opposed to surround sound, audio backend block sizes and buffering.  But maybe he finally, finally got it and realized that his project is only useful for legacy apps and advanced end-users unless he fixes it.
The difference between a batch file and CMake is that eventually you will have 50 source files and the project will take 2 or 3 minutes to build.  CMake outputs project files for any of a number of tools.  In all cases, the tool that does the building will only rebuild changed source files; your batch file will rebuild all source files.  This cuts down most build times on Libaudioverse from minutes to seconds, and on a project like LLVM it cuts it down from hours to minutes.  In most cases, the build tools will also use multiple cores.
Typical build process is clone the repository for whatever, type:

mkdir build
cd build
cmake -G "NMake Makefiles Jom" ..
jom

And on most if not all subsequent runs, just open a command directory to build and type jom and CMake automatically reruns if it needs to. All the build settings are in CMakeCache.txt in the build dir, and you just edit that to change them.   If your project's code is cross-platform, it will then also build on Linux and Mac without you changing anything.
You don't want to edit makefiles by hand if you can avoid it, especially on windows.  Makefiles are cryptic and lock you to one compiler and possibly one platform.  Other people may want Visual Studio projects or QT projects or who knows, and CMake can do that for them.  In addition, CMake contains a bunch of magic to find and detect libraries and header files, to talk to autoconf on Linux, to test the compiler for features, to run custom scripts and commands, to package your project into a zip or installer in a variety of formats, and to perform unit testing.
I still don't recommend C++ for most projects.  But if you have to use it and you're blind, CMake and cdb is the best way I've found.  Even with jaws, the VC++ IDE is very cumbersome.
As for text editor, these days it's Notepad++.  It used to be Edsharp, but Edsharp has a lot of strange little bugs and strange not-so-little bugs here and there, and I can't fix it because he put all his source code in one hugely monolithic file with no organization.  I still think I might end up writing one one day, but Notepad++ works well enough.  It also has the one feature i consider kind of essential: the ability to select blocks without holding shift.  In the case of Notepad++, it's alt+e, b to start, alt+e, b again to select from where you started to the cursor.  Somehow, most people don't find that on their own.

Yeah, NVDA has special support for Notepad++.  That and the beyond exceptional web experience make it a major win for most programmers; 75+% of programming is web, and the VS IDE (the only one Jaws has special support for) is really small fry in the grand scheme of things.  But trying to convince people to switch screen readers is beside the point, especially when Jaws is ultimately dead within the next 5-10 years anyway.  Still, I have yet to find any other text editors that do everything that Notepad++ can do, even with the accessibility issues, thus my comment about maybe making my own one day.
As for libraries, the real solution is don't use C++ if you can at all avoid it, but I doubt that I can convince you that this is a good idea.  With CMake you run from the Visual Studio developer command prompt.  In that case and on Windows, you just make a directory for the .lib files and a directory for the .h files and set the include and lib environment variables to point at them with control panel.  Once you've done that, you can just throw new stuff into the appropriate directories and it will work, mostly.  I prefer to use a batch file called cppshell that I run before I start programming, but this is just preference and not needed.  Linux and Mac have actual standard install locations, but a C/C++ compiler on Windows is very ad-hoc and stupid and whatnot.  Libaudioverse goes out of its way to actually include dependencies in the repository for that reason, building them itself via CMake.  But everyone on Windows basically has to hack together their own little custom setup for it, which is really a shame.
I'm going to ask. Why are you going for C++?  Because I still stand by everything I've said about it in the past, and everyone else I've seen online agrees with me: it's a loaded gun pointed at your foot, possibly your head.  On account that there's no way you haven't seen this at least from me, I'm curious why you care.  College comes to mind, I suppose, though I don't get why colleges still insist on teaching what may be the hardest programming language to learn first anyway.

So this is my opinion on the situation.  It is long, and you can take it or leave it as you choose.  But you specifically asked, and C++ is one of the things I share my opinion on at any opportunity.
Yes, C++11 is still bad, Though it's at least better. I'll give it that much.  If you stay in the realm of smart pointers, use std::array and std::vector instead of the raw C types, declare all destructors to be virtual, and avoid template overuse, you're kind of sort of okay.  But not really great.  Do note that most tutorials do not teach you the C++11 way to do things, mostly because people don't rewrite after they wrote it in 2000 and still get the good Google rankings.
C is simple.  C is very simple.  Simplicity is the point of C.  But this doesn't mean easy.  The problem with C is that you can't effectively abstract over anything.  You can make some sort of list of ints, but good luck using that code on lists of mobs, at least without going into void pointer land or way overusing the preprocessor.  You'll end up coding your own inheritance and basically duplicating huge chunks of what C++ gives you, and you have to manually manage the lifetime of everything without any help whatsoever.
C++ fixes this at a cost.  Libaudioverse quite simply wouldn't be possible to write in C, so much so in fact that I actually spent a week rewriting and converting it to C++11.  C++ gives you abstraction.  But these abstractions are all designed around being efficient and producing code that would be as fast as if you'd hand-written it at the lowest level possible, and lots of them were originally developed in a time when we had so little ram and CPU that compilers could do almost nothing for you.  So you end up with the ability to write at a rather high level, believe it or not, but there's a million and one ways to make things fragile, or crash outright, or cause the compiler to give you cryptic error messages that tell you nothing except that there is a problem somewhere.  And you sometimes have to hold something like ten times more information in your head as compared to the more "modern" languages.  If you avoid most of the features, you can use it like C with classes, and generally that's what I do; I do use templates and stuff, but I think very hard before deciding to do that.  Libaudioverse has less than 10 templates, to give you some idea.  Templates in C++ are an entire second language that you mix with "normal" C++, in a way, and semantically they're actually closer to Haskell than anything.  Most libraries written specifically for a C++ audience love their templates.
This is where I get to confess that I have considered doing games in C++.  I've been using it for 3 years now, mostly because I don't have a choice for the projects I want to do, and I know how to steer clear of all the gaping maws to C++ hell at this point.  If you know how to steer clear of the gaping maws to C++ hell, it's actually an okay language, and you're right: no one will ever reverse engineer it, though breaking your DRM is still possible.  C++ is the language of sighted gaming, and so you can find all sorts of libraries and stuff that cater to C++ first (Box2D comes to mind here, and the fact that it's C++ first is very obvious if you try it in Python).  The standard library, what exists of it, is generally very well done.  C++11 gives us the next best thing to a garbage collector, and if you bring in Boost you can get cross-platform networking and a bunch of other goodies.  Disregarding anything about the language, the one major downside that I keep running into from time to time is the completely abysmal support for unicode, but other than that the gaming landscape is pretty okay.  I'll be doing C++ wrappers over the Libaudioverse C API at some point, if only because C++ is the most game-centric language in sighted land.  But setting up all these libraries is tricky at best, as you have discovered already.
But this is after 3 years of intense programming in it, I'd still have Libaudioverse in C if it weren't for C++11 because pre-C++11 is not by any stretch of the imagination okay, and honestly I'd have to say that learning C++ to a degree where I think you need to be to get a job in it is probably harder than learning to write games in the first place.
The thing about code protection is this.  You are not going to do anything at all that I can't get off the internet faster and easier than decompiling and reverse engineering your code for it.  Everything you are going to do in your game has been done before. Hundreds or thousands of times.  Your network protocol can be cracked even in C++, just by getting some packet sniffing software.  Your DRM can be cracked by someone determined, as all they have to do is patch your DRM's assembly to return true when it's asked if it can be authorized.  I have a friend who can do that in minutes, and I could learn to do it in a Saturday if I had the urge.  Encryption keys can still be extracted; people have written utilities for this, most notably strings on Linux.  You will end up integrating a scripting language for anything not completely trivial, as the change-compile-run cycle is slow and inefficient and horrible, so you're still going to be open to modding from that direction.  No one in this community is doing anything that's actually worth some sort of patent, or that a halfway decent programmer couldn't figure out in a few minutes of thought.  SO unless you already know it well, you gain almost nothing from C++.
If not being decompiled is really important to you anyway, look at rust or go.  These are the newest up-and-coming languages down near the level of C++, and I've heard good things about both.  They are both accessible in terms of IDEs (because they don't have or require any), both come with tooling that's easier than CMake, etc.  I know for a fact that Go at least has OpenAL bindings, though I have no idea how hard they are to set up.  Rust is very different from every other language you have ever seen, but possibly in a good way, and I've been considering it for a possible project for a while now.  C# is okay if you can use VS or are willing to live without a debugger.  Java is horrible because you now need everyone to have a 200 MB runtime.  Python is of course something I recommend, though these days I think that if your project is over 10000 lines or so then you might want to consider a compiled, statically typed language, just to avoid stupid typoing and such.
But I do agree with the learning motivation.  If you manage to come out the other side of C++, you've got a lot of stuff going for you.  Most usefully is a good appreciation of the machine itself, probably including understanding of things like cache friendliness and maybe SSE and all sorts of stuff that's usually just hidden away.  There's also a lot of good money in terms of jobs if you know C++: many people nowadays aren't learning it anymore, and it's super important because we've got literally billions of lines of production code written in it.  Unlike other languages, C++ is such that a good programmer can write good code, but a bad programmer can write code that's so bad it's beyond belief; nothing protects the bad programmer from himself, or you from him for that matter.  And you won't find out that he shot you all for, say, 2 months when you find out that he forgot to add a 1 to that pointer, and the OS just happened to put you somewhere where you didn't segfault and now you're crashing on half of the machines you run on and have to spend a day auditing every line to find out where and who screwed up.  I've done this to myself at least twice, and I'd say I'm at least decent at this point.  So in my opinion at least, given that most programmers who have jobs never cross the line past okay programmer, an actually good C++ programmer is probably worth a whole lot of money.  So for motivations like that, it may actually be a really good choice, if you can handle it.  But I think the really important thing here is to be willing to back out and try another language if you can't, because not being able to handle C++ is in no way the fault of the programmer.  I don't want to see anyone not programming because they hit the amazingly steep learning cliff of C++ and gave up, which is why i share my opinions at the drop of a hat.  Go into it with your eyes open, is all.  Most people don't and then get frustrated or end up with crashy, unmaintainable messes or both.  I was in the latter group, when I did Camlorn_audio, for the record; this is half the reason it collapsed, OpenAL and OpenALSoft being the other half.