ZDoom with OpenAL

[Rachael]

I think as long as it remains open source, there shouldn't be TOO much problem, but contacting the author(s) and getting their permission might be a good idea.

[Ferk]

Any news? ^^ I registered in this forum just to let you know that I appreciate this! thanks
Having ZDoom working with OpenAL would also mean that it could be easily distributable for Linux distributions, and perhaps even be included in the repositories, maybe I could do some maintenance for a deb package. Currently, there's only lxdoom, which is nice for boom and vanilla compatibility, but it lacks the features and power that gzdoom has.

Anyone know what the legality would be for using a GPL lib (libmad for MP3) with ZDoom? AFAIK, run-time loading doesn't protect it from the viral aspects of the GPL, and since ZDoom's license isn't GPL compatible, I'm not sure what can be done. The other MP3 lib I'm aware of which is LGPL (libmpg123) isn't conducive to being loaded at run-time.

One of the main reasons why I think that OpenAL would be needed is because I believe that FMOD is the only thing stopping GZDoom for being GPL (Graf Zahl, correct me if I'm wrong). So... I think that you can use the GPL library if permision is given to relicense the non-FMOD-dependant code to the GPL by the people who wrote it.

[Graf Zahl]

Actually, it's not the only thing. There's some parts in the source that are under a not-for-profit license which are obviously incompatible with the GPL.

[Rachael]

Even so, I think switching sound libraries would be quite a desirable thing, but I could be wrong. If using OpenAL is prohibited, then that sucks.

[Macil]

Even so, I think switching sound libraries would be quite a desirable thing, but I could be wrong. If using OpenAL is prohibited, then that sucks.

No, I think Graf was talking about parts of the zdoom source.
I know some parts of the code were taken from Hexen, but that's been GPL for a while. What else is left?

[Chris]

Even so, I think switching sound libraries would be quite a desirable thing, but I could be wrong. If using OpenAL is prohibited, then that sucks.

Nothing is prohibiting (G)ZDoom from using OpenAL (there's no license issues and I've pretty much been using it exclusively). I'm just trying to get a set of decoder libraries that are compatible with (G)ZDoom's license to be able to handle the compressed audio formats that wads can have.. and currently it's just MP3 that's proving to be a problem to solve.

As far as I'm concerned, it's all but ready to go in. The big remaining problem is you'd lose MP3 support, and OXM support (since ZDoom relies on the sound backend to decode and return the Vorbis sound data to the module player for Ogg XM modules; but IMO this is a bad assumption to make about the sound backend).

Actually, that's not quite true.. there is one nasty problem that I've yet to find a fool-proof fix for. Currently, FMOD for Linux (improperly) exports modified functions for decoding Ogg Vorbis. Unfortunately because of the way dynamic linking works on Linux, these are taken as overrides, so when OpenAL tries to call the real Ogg Vorbis decoder functions, it's hijacked by FMOD. This problem can be side-stepped by using the plugin version of FMOD, where its ogg vorbis decoding is done in a plugin that's not loaded until needed; but the plugin itself also happens to have the ogg vorbis functions improperly exported, so if that ever gets loaded at the same time (eg. if switching between FMOD and OpenAL), the problem resurfaces.

The only real way to fix this (besides fixing FMOD itself, which we can't do without the source) would be to not load FMOD, at all, if OpenAL is going to be used. Even making sure to dlclose isn't safe because that's not guaranteed to actually unload.. it just decreases the ref count on them. If anything else has a hold on them, they stay. And it may not be unloaded immediately when it reaches 0 references. So either ZDoom would need to physically shut down and restart to change audio backend (which will increase the wait time as the FMOD backend must be run-time loaded before OpenAL can go in), or ZDoom can only be compiled to use FMOD or OpenAL with no option to change (which would be quicker since it would be easier to #ifdef out the FMOD stuff).

[Chris]

Updated against r1458. Now, FMOD can be left out of compilation, either by letting the search for headers/libs fail, or by passing -DNO_FMOD=1 to cmake (OpenAL can be left out like this as well). The relevant menu entries are left out of the sound menu if the respective backend isn't enabled at compile-time.

Currently the latest GIT version of ALURE can handle MP3 if you have a semi-recent GStreamer (and it has support for MP3 enabled, of course). I don't think this works on Windows/OSX, but I intend to add DirectShow and QuickTime support eventually, as well.

[Graf Zahl]

I had to drop MP3 support from ALURE because libmpg123 was not cooperating and does not like to be loaded at run-time, so MP3 sound effects and music won't work

Is this a Linux-only or a general problem? I've got several FMod related crashes reported at the GZDoom forum and would like to do a test release with OpenAL enabled.

But in order to do a release I need a version that can handle MP3 sound. To be honest, the problems with MP3 are the sole reason why I lost interest in this.

[Chris]

Is this a Linux-only or a general problem?

A little of both. If I try to make it work on Linux, it won't work on Windows, and vice-versa. libmpg123's ABI is just fubar'd.

I may consider adding it back since Linux can get MP3 via GStreamer now.. but I'd prefer trying to get a DirectShow decoder which should be able to handle MP3 fine on Windows.

But in order to do a release I need a version that can handle MP3 sound. To be honest, the problems with MP3 are the sole reason why I lost interest in this.

Believe me, dropping MP3 wasn't the easiest decision to make. But I considered the stability and cross-platform-ness of the library a bit more important. I may even have to remove GStreamer if I can't get the Windows/OSX equivalents working (though GStreamer can apparently work on Windows and OSX by bridging to DShow/QuickTime.. I will have to look into how nicely that works).

[Graf Zahl]

Let's make this short.

The only chance I can ever see for this becoming official is if we have a working Windows implementation that

- does not add megabytes in library bloat - especially library bloat that doesn't come precompiled (I couldn't find a binary package of this GStreamer stuff...)
- supports all sound formats that FMod currently can handle

What's the problem of enabling mpg123 selectively? You said you got something working for Linux using GStreamer. So why the need to use the exact same libararies everywhere. Is it really this bad to have different code on Linux and Windows?

[bagheadspidey]

GStreamer support would be awesome, it has plugins for just about every sound format imaginable. I'm sure DirectShow has a bunch of plugins available for it too. Seems to me like that approach would provide enough flexibility to make fmod and dumb both optional, and allow more formats to be plugged in (like sid!)

[Chris]

Let's make this short.

The only chance I can ever see for this becoming official is if we have a working Windows implementation that

- does not add megabytes in library bloat - especially library bloat that doesn't come precompiled (I couldn't find a binary package of this GStreamer stuff...)
- supports all sound formats that FMod currently can handle

Don't forget FMod isn't averse to licensing formats which may not be available for open source decoders. If you're truly trying to get away from proprietary libs (for all of ZDoom, or just GZDoom), maintaining support for patented/non-reversed formats may not be possible. At most you can "cheat" and use an external API that may provide it if the user has it configured too, but there's still no guarantee it'll work, and it would be detrimental to encourage users to use it. And I'm not talking about just MP3, by the way.

Looking at the plugins dir, though, I see these for codecs:
flac, oggvorbis, aiff, wav - fine
cdda, xm, it, mod, s3m, midi, raw, playlist - ZDoom handles these explicitly, afaik
dls, fsb, vag, tag, sf2 - not sure what these are (except sf2, but I don't see how that could work for ZDoom's purposes..)
mpeg - missing (except with gstreamer)

What's the problem of enabling mpg123 selectively? You said you got something working for Linux using GStreamer. So why the need to use the exact same libararies everywhere. Is it really this bad to have different code on Linux and Windows?

Not so much about having the exact same libraries everywhere. I would just like to have comparable functionality. If I have an explicit MPEG decoder for Windows, I want an explicit MPEG decoder for Linux and OSX, too. Whether it uses the same libraries or not doesn't matter (that much). GStreamer would be considered a "system decoder" for Linux, so I want something comparable for Windows and OSX.. whether it would work through GStreamer or use separate DShow/QT decoders doesn't really matter. I don't want Linux to have any more of an advantage than I want Windows or OSX to.

It would just make things much easier for me if the system decoder can all work through the same API on different platforms, because I can't program on Windows or OSX. At most I can cross-compile a Windows version and try it under Wine, but that's hardly optimal. And I don't think there's anything I can personally do for OSX without getting a Mac.. someone else would need to do it.

[Graf Zahl]

Let's make this short.

The only chance I can ever see for this becoming official is if we have a working Windows implementation that

- does not add megabytes in library bloat - especially library bloat that doesn't come precompiled (I couldn't find a binary package of this GStreamer stuff...)
- supports all sound formats that FMod currently can handle

Don't forget FMod isn't averse to licensing formats which may not be available for open source decoders. If you're truly trying to get away from proprietary libs (for all of ZDoom, or just GZDoom), maintaining support for patented/non-reversed formats may not be possible. At most you can "cheat" and use an external API that may provide it if the user has it configured too, but there's still no guarantee it'll work, and it would be detrimental to encourage users to use it. And I'm not talking about just MP3, by the way.

That may be a concern for you. The question now is, how important is working OpenAL support to you and others? For me personally it's secondary as FMod works fine for me. So please excuse me if I say that this whole undertaking holds no interest to me as long as the commonly used sound formats are not properly supported. And by 'supported' I don't mean relying on system-internal libraries and codecs that may or may not be installed.

[Chris]

The question now is, how important is working OpenAL support to you and others? For me personally it's secondary as FMod works fine for me.

It's a rather primary concern for me since FMod doesn't seem to be working here (ZDoom keeps reporting that FMOD::System::init returns 60 or 61 (depending if I try to use "default" or "alsa" respectively), and no other info), and it's not as customizable/configurable/open as OpenAL Soft.

So please excuse me if I say that this whole undertaking holds no interest to me as long as the commonly used sound formats are not properly supported. And by 'supported' I don't mean relying on system-internal libraries and codecs that may or may not be installed.

Well, the only thing "missing" here is MP3, right? So for a Windows build, you'd just need to provide some base gstreamer libs and its mp3 codec (which I'd imagine is still usable despite being able to also use dshow; though it should be noted that Windows comes with an MP3 codec, so I don't see a problem with using it since it will, for sure, be there). AFAIK, OSX's QuickTime libs will also for sure have MP3 support, so again, it won't be missing (but also, again, gstreamer's own MP3 codec should still work). And Linux users will have this installed/can install it easy enough.

My comment about supporting patented/proprietary formats applied more to formats which haven't been successfully reverse-engineered yet (like newer WMAs and such), because I don't know exactly what formats FMod supports and has licensed, and because it would be an issue if you're aiming for GPL compatibility in some way. Missing MP3 support in specific would only be a concern for Linux/Unix users that purposely avoid using patented software, in which case it's all on them and they know what they're getting into, and no matter what ZDoom does, it won't make them install MP3 libs (and it seems a bit harsh for ZDoom to try and force them to).

[Graf Zahl]

Reading stuff like this makes DirectShow not appear to be a good solution...