Project

General

Profile

Actions

Feature #21

open

Audio system

Added by quintus over 1 year ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
04/28/2021
Due date:
% Done:

0%

Estimated time:

Description

Our central game development library, OGRE, does not provide audio facilities as it restricts itself to rendering questions. We will thus need an audio system. A widespread and cross-platform library for this is OpenAL-Soft, which implements the OpenAL specification. I see that it is not exactly lightweight with regard to its dependencies, but since a 3D game needs things like audio spatialization (this is what makes sounds left from the viewer come from the left speaker, for instance) I do not think that we can go much thinner. libsndio is lightweight, but it is neither available for Windows (thus we would require system-specific code) nor can it do audio spatialization.

OpenAL's and thereby OpenAL-Soft's interface is not exactly welcoming for use in a C++ application. In addition, OpenAL does not help with reading the actual audio data from the disk, which probably means that we will utilise another library to do that as modern audio formats like OGG/Vorbis are not that much fun to implement. Both aspects together signal that we need our own proper API to abstract both aspects away behind an interface that is nice to use namely from within the Scene system. I have added a possible API for this wrapper with commit 73933a39ca16a57a9d4468d279e08145c9a6a3ac. Take a look at the audio/ folder in the repository to see whatever is the current state of it.

Here is a blog post I found that explains how OpenAL works. I will update this ticket's description once I have made up my mind about which audio format is good to use.

This ticket is to track progress on the audio system.

Actions #1

Updated by quintus over 1 year ago

I will update this ticket's description once I have made up my mind about which audio format is good to use.

For now, I would like to play the ball over to refi64. What do you think is the most useful audio format? OGG/Vorbis as we had it in TSC? Or would you prefer something different?

-quintus

Actions #2

Updated by refi64 over 1 year ago

So nowadays I believe Opus is basically the best, which is by the same creators of Ogg Vorbis and just compresses a bit better (you can have 128kbps Opus files that sound basically transparent in most cases, i.e. they sound perfect, at least as good as the average 320kbps MP3).

I know I did use it for a small game as part of a group project with libgdx (which is a TERRIBLE game engine btw, as a note for any other poor souls who read this), and the file sizes were quite amazing relative to the audio quality.

That being said, I'm not that familiar with the libopus APIs, but it can't be that terrible...right?

On another note I actually also have acquired some experience I wish I didn't with regard to looping an audio file at an arbitrary point inside it without audible gaps, which is surprisingly painful (you essentially have to have the audio buffers for the start of the loop point ready in memory, then seamlessly swap over to them when you hit the end of the audio file).

Sadly, in terms of actually playing audio, I'm not aware of any major OSS libraries that support 3D audio other than openal-soft.

Actions #3

Updated by quintus over 1 year ago

So nowadays I believe Opus is basically the best, which is by the same creators of Ogg Vorbis and just compresses a bit better (you can have 128kbps Opus files that sound basically transparent in most cases, i.e. they sound perfect, at least as good as the average 320kbps MP3).

Thank you for your opinion! I always wonder if there is really an audible difference between all these formats. When I hear people discoursing over the topic, I have the impression it is kind of esoteric. My ear for certain would not tell the difference apart; I presume there is more quality loss in bad speakers than in the file format.

That being said, I'm not that familiar with the libopus APIs, but it can't be that terrible...right?

I took a look and its documentation looks pretty reasonable. These audio decoder libraries look all alike: create a decoder state, feed compressed audio data into it, receive decompressed audio data for your audio output library.

If I understand it correctly, the Opus format does not comprise a container format, but instead leverages the pre-existing OGG container format. That is, for decoding the container first, we would still need libogg, whose documentation is a little sparse, but because it is not a large library, I think it is managable. What bugs me more is that this generates two new dependencies, both libopus and libogg, in addition to openal-soft and its dependency libsndio. But I suppose there is no useful audio format that has both the codec and the container in one library, no?

On another note I actually also have acquired some experience I wish I didn't with regard to looping an audio file at an arbitrary point inside it without audible gaps, which is surprisingly painful (you essentially have to have the audio buffers for the start of the loop point ready in memory, then seamlessly swap over to them when you hit the end of the audio file).

Thanks for the information point. When I (or someone else) tackles this ticket, it will be useful to ask for your experience in this area.

Sadly, in terms of actually playing audio, I'm not aware of any major OSS libraries that support 3D audio other than openal-soft.

Which is fine. We will wrap it in a nicer to use C++ API as outlined in this ticket. If you find the API I suggested in the OP insufficient, please speak up and I will try to improve the suggestion.

-quintus

Actions #4

Updated by quintus over 1 year ago

Today I got another thought. The game is currently meant to be a 1-2 player game. If we suppose for the moment we would use a splitscreen in 2-player mode, how would one want to do 3D audio anyway? There is no single listener in this case, but there would be two! In such a case, 3D audio does not make that much sense anymore. Or how would one approach the 3D audio implementation of such a scenario?

Even if the game is played in the regular 1-player mode, is the lack of 3D audio that much bad? If we can omit it, we can use a much simpler audio library like libsndio.

I have not decided anything yet, I am just thinking aloud and am entirely open for discussion.

Actions #5

Updated by refi64 over 1 year ago

I'd imagine we could just assume that split-screen gameplay will generally involve audio being played on speakers, where 3D audio doesn't matter as much? Vs in single-player, where someone might be using headphones and thus the effect would be quite obvious.

Actions

Also available in: Atom PDF