SoLoud audio engine
category: code [glöplog]
Nice, although on the first cursory look it doesn't really seem to be ready for my favorite bit in game audio-code: "deallocate audio source while it is playing" :)
Yep, that would be bad. Adding to todo list.. =)
whats good enough for minecraft cant be bad for solo! ;P
hmm, seems the interface fundamentally rules out more than two channels output, is that the right decision for an audio API in 2013?
On that note, I think it's unfortunate that the term "channel" in the API is used for audio streams.
<Insert rant about how people still think "sound effect == play a wav" in fucking 2013 here>
Apart from that: Yeah, actually stopping sounds would be a good idea, and everything I said in my imaginary rant above is another layer anyway so you can easily build on what you've done so far. :)
Apart from that: Yeah, actually stopping sounds would be a good idea, and everything I said in my imaginary rant above is another layer anyway so you can easily build on what you've done so far. :)
@kb_: so what _are_ the requirements of a modern game sound engine?
trc: Looking at XACT, FMOD Studio, Miles and all the others might give you a hint. But the general rule of thumb for the last 10 years now is "if you see any occurrence of volume or pitch or pan or samples in general in the game code, you're doing it wrong" (except of course setting the sfx/music volume from the menu :D).
And yes, I fully understand that as a small indie dev you might think that having to do a few mouse clicks in an editor when all you want to do is PlaySound("ding.wav") is already too much indirection. But every 30 seconds you lose when adding another sound effect is worth as well the hours you will _not_ spend recompiling and tweaking all the time, and as soon as you have a decently capable sound designer operating the sound editor tool the whole outcome will be SO much better...
Because even a PlaySound("ding.wav") leaves open a lot of questions. Wwhat volume is that ding sound played at? You'll at least need to wire it to the sfx volume => more code to type. And what about some variation (different samples or vol/pitch randomization) if it's getting played multiple times? Or how about tuning it to the background soundtrack's chords? If the player has a 5.1 audio setup, where does the sound come from then? Could it be necessary to mute other sounds when the ding is played? What if it's triggered like 10 times after each other because the game coder was sloppy?
A modern data driven audio engine will never need more than PlaySound("ding"); on the game coder's part, all the stuff I wrote above will be adjustable in the tool. In real time while the game is running. The coder won't know what's going on inside; the audio engine might as well post a classified ad and order you a triangle player who comes to your house and plays "ding". And this very set of features is more than 10 years old now.
And yes, I fully understand that as a small indie dev you might think that having to do a few mouse clicks in an editor when all you want to do is PlaySound("ding.wav") is already too much indirection. But every 30 seconds you lose when adding another sound effect is worth as well the hours you will _not_ spend recompiling and tweaking all the time, and as soon as you have a decently capable sound designer operating the sound editor tool the whole outcome will be SO much better...
Because even a PlaySound("ding.wav") leaves open a lot of questions. Wwhat volume is that ding sound played at? You'll at least need to wire it to the sfx volume => more code to type. And what about some variation (different samples or vol/pitch randomization) if it's getting played multiple times? Or how about tuning it to the background soundtrack's chords? If the player has a 5.1 audio setup, where does the sound come from then? Could it be necessary to mute other sounds when the ding is played? What if it's triggered like 10 times after each other because the game coder was sloppy?
A modern data driven audio engine will never need more than PlaySound("ding"); on the game coder's part, all the stuff I wrote above will be adjustable in the tool. In real time while the game is running. The coder won't know what's going on inside; the audio engine might as well post a classified ad and order you a triangle player who comes to your house and plays "ding". And this very set of features is more than 10 years old now.
If this was a commercial project, I'd tend to agree.
Instead, this is a free project (in fact, just about as free as you can get, much more free than gpl); it naturally lacks features I didn't feel necessary at the time. It's not suitable for every project out there.
I wanted something simple, easy to use, that solves my immediate audio needs. If someone else finds it useful - great! And for someone to find it useful, that someone has to find it first.. hence, this post. =)
Instead, this is a free project (in fact, just about as free as you can get, much more free than gpl); it naturally lacks features I didn't feel necessary at the time. It's not suitable for every project out there.
I wanted something simple, easy to use, that solves my immediate audio needs. If someone else finds it useful - great! And for someone to find it useful, that someone has to find it first.. hence, this post. =)
Sol, it's great that you release stuff you originally made for yourself to the public for free use by others. Thank you!
Oh, I didn't want to discourage you. Sorry if that came out that way. On the contrary - with the handles (and especially their revert-to-dummy behaviour when they become invalid) you're actually on the absolutely right track, and everything I wrote can easily be added. It's just that I wouldn't really call it "game audio engine" yet, it's more a medium-level audio API like XAudio or whatever is going on with the consoles. And hey, it's already at the level of one big commercial engine that's starting with U. ;)
Just promise that as soon as you find the feature set lacking for your own needs, you actually improve in the engine instead of writing workarounds in the game code because it feels quicker at the time. :)
Just promise that as soon as you find the feature set lacking for your own needs, you actually improve in the engine instead of writing workarounds in the game code because it feels quicker at the time. :)
kb_: I'm already doing that. I've found holes in the API by making tests, and integrating it in the game I'm working on, and it's much easier to change the audio engine than to hack stuff like faders into the game.
What's more, since it comes with a liberal license, anyone using it can do the same for their project, if they find something lacking. Of course it would be better if they submit said changes for the main tree, but nothing stops them from forking it. And I'm fine with that.
And I've already implemented some stuff other people have asked for. =)
What's more, since it comes with a liberal license, anyone using it can do the same for their project, if they find something lacking. Of course it would be better if they submit said changes for the main tree, but nothing stops them from forking it. And I'm fine with that.
And I've already implemented some stuff other people have asked for. =)
Oh, I forgot: kudos to you Sol! audio FTW.
Hey, it's time to kick some life back to this ancient thread!
http://soloud-audio.com now has a new release with more changes than I bother copypasting here. As well as documentation in pdf, mobi, epub and html format, since I got that documentation toolchain going finally.
http://soloud-audio.com now has a new release with more changes than I bother copypasting here. As well as documentation in pdf, mobi, epub and html format, since I got that documentation toolchain going finally.
okay. i just flew over. wtf. game audio engine? it's looks like a doubled wrapped interface around the same api functionality that's underneath it. and it needs a wrapper class around to setup and control the output. dunno what's under the hood, but a real fire and forget would probably be something like: modify the spatial environment around the listener on the fly and fire a sound with a vector and movement relative to the listener. then you just turn the listener around. one call per frame. easier?
Ehh.. I have no idea where you got that impression.