Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modernize the Audio system. #135

Open
MakoEnergy opened this issue Mar 10, 2017 · 0 comments
Open

Modernize the Audio system. #135

MakoEnergy opened this issue Mar 10, 2017 · 0 comments

Comments

@MakoEnergy
Copy link
Member

MakoEnergy commented Mar 10, 2017

This one is a little bit vague because it potentially entails so much. Currently we use OpenAL Soft for our audio solution, but we don't make use of any major features that would prohibit us from using OpenAL (not soft) as well. We have also created a series of interfaces that could be reimplemented using another backend. Libraries that could be used as a backend are somewhat is short supply due to our strict criteria (license, platform support, 3d support, maintained, etc.). Still, some others do exist that can at a minimum be used for reference and have some meaningful feature parity with what we have now.

https://github.com/yvanvds/yse-soundengine
https://github.com/libaudioverse/libaudioverse
https://www.twitch.tv/videos/125625961 (start at 3h,26m)

The biggest thing we're missing that these other examples have is solid support for sound synthesis, a means of mixing sounds that is intuitive that allows you to more easily produce procedural sounds. Nothing about OpenAL forbids this, however would take considerable effort to build on top of.

Another example is something that has had a ticket for a long time: #17
This is a less common feature but being able to automate the effects of terrain is a massive time saver for content creators.

Better examples of shortcomings of how the OpenAL code is actually used lies in the soundscape manager and soundproxy classes. It is necessary to create multiple sound sources PER OBJECT because listeners aren't allowed to share sources. Furthermore access to sources is based on the context that is active, so context switching is commonplace for even simple operations. This produces code that could be slow and is definitely horrendous to look at. BEHOLD!
https://github.com/BlackToppStudios/Mezzanine/blob/master/Mezzanine/src/Audio/OALS/oalssoundproxy.cpp#L387

Getting access to the buffer for the "rendered" listener perspective is also not supported in OpenAL. This is a bit of an edge case, but prevents us from taking audio output as is and do additional effects with it or send it to a file/network host. It also prevents us from using it locally as you would if you wanted to have a mic in game to transmit to a speaker elsewhere over a distance. Eavesdropping mechanics.

Overall, the audio system needs a lot of love. I'm not sure what the best solution is at the time of this writing. Maybe move away from OpenAL altogether. Maybe refactor our interface classes to accommodate other libraries. Or maybe just build relentlessly on top of what we have. But also, the SoundProxy class should be renamed to SpeakerProxy. >.>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant