ZDoom with OpenAL

[Gez]

Could we get a sync with trunk? It's been a while since the last update and so it hasn't caught on the latest sound system changes (such as the GUS emulator being unhidden, XMI support, etc.).

[Graf Zahl]

Sure. But I'd rather get this into a state where it can be compiled under Windows without a hassle. I still haven't managed to so even though I could merge it I can't compile it.

[Chris]

I can set it up so GStreamer can be disabled, then you should only need to install the OpenAL SDK.. although that will only leave raw sounds available without a replacement format reader.

I really am not sure how to handle this that would be satisfactory to you guys. I can't think of anything that won't either require including the source for decoders, so they can be built and linked with ZDoom itself, or including the headers with ZDoom's source and provide some DLLs with the binary redist. You haven't particularly cared for those options, though.

FWIW, the Git version of Alure is under the X11/MIT license now (was LGPL), so can be static-linked/included with ZDoom, and it is able to dynamically load the necessary shared libs for decoding formats.

[Chris]

Here's a patch which makes GStreamer optional. Can't test on Windows, though.

[Graf Zahl]

I really am not sure how to handle this that would be satisfactory to you guys. I can't think of anything that won't either require including the source for decoders, so they can be built and linked with ZDoom itself, or including the headers with ZDoom's source and provide some DLLs with the binary redist. You haven't particularly cared for those options, though.

I have no problems with a binary distribution package. My problem with GStreamer is that it's a huge install that contains far too many files and it's impossible to figure out what is needed and what not. Including everything is not an option because it's simply too much files.

For me the ideal solution would be to rewrite the sound code so that both the FMod implementation and the OpenAL implementation are separate plugins not statically linked into the EXE. That would have the great advantage that the biggest licensing obstacle is no longer part of the project (and I could relicense GZDoom under something more usable after removing the software renderer and (unfortunately) the OPL emulator.)

[Chris]

My problem with GStreamer is that it's a huge install that contains far too many files and it's impossible to figure out what is needed and what not. Including everything is not an option because it's simply too much files.

Yeah, the idea was that it would use GStreamer on systems like Linux (where most have it by default, and it's simple to install with package managers), and something else on Windows, like DShow or the ACM stuff (though there still is an issue there, since Windows doesn't come with Vorbis/FLAC support; a user would have to install the codecs if they haven't already).

For me the ideal solution would be to rewrite the sound code so that both the FMod implementation and the OpenAL implementation are separate plugins not statically linked into the EXE. That would have the great advantage that the biggest licensing obstacle is no longer part of the project (and I could relicense GZDoom under something more usable after removing the software renderer and (unfortunately) the OPL emulator.)

On the surface, that doesn't look too hard to do. The FMod-specific code is contained within the SoundRenderer-derived class (and static functions in the fmodsound.cpp source), and isn't used by the rest of the engine. It wouldn't be difficult to make plugin libs that contain a factory function which returns a SoundRenderer-derived object, which would be called instead of new'ing the specific class. An issue might come in where the sound renderer needs to reference stuff in the main executable, though.. the CVars, for example, and some helper functions. I'm not too sure how well that will work on Windows.

[Graf Zahl]

I just had a look at this code. Unfortunately this is all in a state where it's pretty much unusable.

For once, the GStreamer code is one big, fat and ugly mess that's impossible to decipher and the GStreamer-disabled option looks like all sound streaming has been completely disabled. How does this handle external streams like DUMB, GME or Timidity++?

So without GStreamer it looks like it's perfectly useless.
In addition, I noticed that when opening a stream your code is copying data around from one file to another when it wants to play music. Again, why? This will happen at time critical moments (music can be changed in the middle of a level!) and it's simply not acceptable to extend this period of time any further. Is there a reason you can't play from the middle of a file? More importantly, does this really requite a FILE pointer. If this ever gets turned into a plugin a completely different file reading interface needs to be implemented so that the plugin can share data with the main application.

What this needs first though is a setup that allows easy definition of other decoders. I'd like to try libsndfile and libmpg123 but in all that bloat for GStreamer I just can't find where to start.

[Chris]

For once, the GStreamer code is one big, fat and ugly mess that's impossible to decipher and the GStreamer-disabled option looks like all sound streaming has been completely disabled. How does this handle external streams like DUMB, GME or Timidity++?

Currently, with GStreamer disabled, it doesn't. However, for callback-based streams I can make it play using a regular buffer queue set up. I was just more concerned with getting the code to work with and without GStreamer than to add anything more yet.

In addition, I noticed that when opening a stream your code is copying data around from one file to another when it wants to play music. Again, why? This will happen at time critical moments (music can be changed in the middle of a level!) and it's simply not acceptable to extend this period of time any further. Is there a reason you can't play from the middle of a file?

The code I originally wrote that for couldn't handle middle-of-the-file files (and is only invoked in those circumstances). I can likely fix that now, though.

I'd like to try libsndfile and libmpg123 but in all that bloat for GStreamer I just can't find where to start.

If you'd be happy enough with libsndfile and libmpg123, I can drop GStreamer and use them instead. I suppose I should drop GStreamer anyway, if it's bloating the code too much.

[Graf Zahl]

That's your decision. But the least I'd do is to separate the GStreamer code from the OpenAL related code in the stream class. Once they are cleanly separated it will no longer be an issue. My problem right now is that I can't compile it and the stream class has so much code in it that it's hard to find the parts that need to be retained to make the custom streams ZDoom uses to play certain music work.

[Chris]

Here's a patch that splits the gstreamer streamer into a separate file (oalgstreamer.cpp/h, which need to be added to the repo after patching them in), and adds callback-based playback to the non-GStreamer streamer.

That should be enough to start playing around with libsndfile and libmpg123. For streaming, they can run through the callback-based player, and for sound effects, they can be used by decoding the data first and passing them to LoadSoundRaw.. both agnostic to the sound backend in use. This could be done by having default implementations of SoundRenderer::LoadSound and SoundRenderer::OpenStream which use external decoders, and pass them through to LoadSoundRaw and CreateStream respectively.


As for the code, there's one issue and something I'm not sure about. The issue is that the streams' IsEnded() method doesn't seem to be getting called at all. I'm using that method to check if there's any more data coming in and to "pump" the buffer queue, but the engine never calls it. I dug a little bit, and it looks like it should be getting called, but it doesn't. I currently hack a call to it in OpenALSoundRenderer::UpdateSounds. And as for what I'm not sure about: CreateStream is given a set of flags for the callback-provided sample format. Does Bits8 specify signed or unsigned data? 8-bit data is historically provided as unsigned (and 16-bit as signed), but I'm not sure what to expect here. I get the feeling I may have already asked that...

EDIT:
Updated patch, so it handles 32-bit float and 32-bit int conversions as needed.

[chmmr]

Looking forward to seeing how this turns out, especially now that this is the last thing keeping GZDoom from being GPL.

Regarding OPL music emulation, doesn't the AdPlug project have a fully GPL OPL emulator?

[Gez]

And so does Chocolate Doom, and DOSBox, and ScummVM...

[Chris]

Odd. I seem to have not uploaded the updated patch. Oops. Here it is...

[ryan]

Hi Chris. What zdoom revision does that latest openal patch require? I've ended up downloading almost every patch set in this thread trying to get together the most recent of patches and no matter what i always end up with patch rejections. Cheers.

[ryan]

i found the zdoom-openal tree in subversion so its been safe to ignore my comment since the day i posted (woops)

i managed to get a zdoom binary that works on openbsd, but to do so i had to do some angry code snipping (rather than take the time to do code fixing) and my resulting binary, while it runs..does not save any settings and openal doesn't work because i had to port openal-soft rather than the normal openal-0.0.8 distribution, and i only did that enough literally to get a lib that would allow zdoom to build. i didn't even care about sound so long as my zdoom binary was an OpenBSD/ELF binary and ran the game

that being said, when i sit down to actually properly complete the openbsd port for zdoom, i will be sure to send any useful patches upstream.
many many files had to be modified to #include <SDL/SDL.h> instead of #include "SDL.h". cheers,

-ryan