ZDoom with OpenAL

[Graf Zahl]

The warnings are indeed retarded. I always thought that an explicit type cast was supposed to suppress them.

[Chris]

Here's an update that should fix those problems.

[Graf Zahl]

Not the most efficient solution.

I think a double cast with an intptr_t in between would have been enough.

[terminx]

You guys might want to check out http://www.tdragon.net/recentgcc/ for your MinGW needs; has an installer and everything and gives you gcc 4.3.2. I use this for all builds of EDuke32 with no issues.

[Blzut3]

It compiles fine now, but now it segmentation faults on run time.

Code: Select all • Expand view

(gdb) run                                                                   
Starting program: /home/blzut3/Code/ZDoomAL/zdoom                           
[Thread debugging using libthread_db enabled]                               
ZDoom v2.2.0 - SVN revision 1268M - SDL version
Compiled on Oct 20 2008

[New Thread 0x7f14e302d780 (LWP 1397)]
[New Thread 0x425aa950 (LWP 1402)]
M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
 adding /home/blzut3/Code/ZDoomAL/zdoom.pk3
 adding /usr/games/Doom-Data/iwads/doom2.wad (2919 lumps)
I_Init: Setting up machine state.
CPU Vendor ID: GenuineIntel
  Name: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
  Family 6, Model 15, Stepping 11
  Features: MMX SSE SSE2 SSE3 SSSE3
I_InitSound: Initializing OpenAL
  Opened device

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f14e302d780 (LWP 1397)]
0x00007f14e277b7b2 in ?? () from /usr/lib/libopenal.so.0
(gdb) bt
#0  0x00007f14e277b7b2 in ?? () from /usr/lib/libopenal.so.0
#1  0x00007f14e2752f8b in ?? () from /usr/lib/libopenal.so.0
#2  0x00007f14e27783b1 in alcMakeContextCurrent () from /usr/lib/libopenal.so.0
#3  0x0000000000730470 in OpenALSoundRenderer::Init (this=0xfb4920) at /home/blzut3/Code/ZDoomAL/src/sound/oalsound.cpp:516
#4  0x0000000000731000 in OpenALSoundRenderer (this=0xfb4920) at /home/blzut3/Code/ZDoomAL/src/sound/oalsound.cpp:458
#5  0x000000000071f4f4 in I_InitSound () at /home/blzut3/Code/ZDoomAL/src/sound/i_sound.cpp:243
#6  0x0000000000506062 in I_Init () at /home/blzut3/Code/ZDoomAL/src/sdl/i_system.cpp:188
#7  0x0000000000535f03 in D_DoomMain () at /home/blzut3/Code/ZDoomAL/src/d_main.cpp:2331
#8  0x0000000000504e54 in main (argc=1, argv=0x7fffeb06a2f8) at /home/blzut3/Code/ZDoomAL/src/sdl/i_main.cpp:272

[Chris]

Code: Select all • Expand view

/usr/lib/libopenal.so.0

Seems you're using the old OpenAL (0.0.8). Though I don't know why it would be crashing, it's known to be rather buggy. Being in 64-bit would just make things worse. The code it's crashing with is standard initialization, and I'm not sure what can be done unless you can get a backtrace from OpenAL.

Otherwise, you can try OpenAL Soft. It's better maintained, has newer features, and better complies with the spec. Distros are moving toward using it in place of the old implementation, since the last release of the old version was a couple years ago.

[Blzut3]

Ahh, I went and got the Ubuntu Intrepid OpenAL library and it works fine in 64-bit.

I noticed two things, the music seems to freeze momentarily on map load. Its not too bad, but it does seem a bit strange. The other is the music sound slider seems to need to be scaled up if possible. I currently have the music on max and sound effects at about 25% which doesn't seem right.

[Chris]

Ahh, I went and got the Ubuntu Intrepid OpenAL library and it works fine in 64-bit.

Cool.

I noticed two things, the music seems to freeze momentarily on map load. Its not too bad, but it does seem a bit strange. The other is the music sound slider seems to need to be scaled up if possible. I currently have the music on max and sound effects at about 25% which doesn't seem right.

The music freezing is due to ZDoom not calling SoundRenderer::UpdateSounds during a screen fade. The music is polled in that function, and since it doesn't get called for a time, it runs out of data to play and stops (until it's called again and resumed).

The volumes are a different matter. SetSfxVolume calls alListenerf(AL_GAIN..), which effectively scales the volume of all sources (a master volume control, in effect). Since music is played through the sources, it's affected as well. The way around this would be to set each source's gain to the sfx volume, but the source gain is already used to "emulate" rolloff. I'd need to store a second gain for each source, which I obviously can't do with OpenAL. There's a couple things I might be able to do, though, which I'll look into.

[Chris]

I seem to have the sfx/music volume issue sorted. I'm now working on getting reverb working. and so far so good. The eax.wad demo is producing nicely comparable results. I'm having an issue, however, understanding how snd_waterreverb (and "underwater reverb" in general) is supposed to interact with environment reverb. Only one reverb effect can be active at a time, so what is supposed to happen? I'm having a difficult time understanding what the FMOD code is doing.

The way I'm seeing it, it first checks to see if the environment has changed, and set the new reverb properties if so. Then if the listener is marked as being underwater, or the environment is tagged as "SoftwareWater", it sets a custom lowpass filter and reverb effect even if snd_waterreverb is off. Won't this cause a problem if the listener is marked as underwater, and there's an environment set?

[Csonicgo]

I cannot thank you enough, Chris

[randi]

EAX-compatible reverb and the underwater effect are done using separate DSP units. Since I decided to forego hardware support, I have maximum flexibility and also maximum compatibility in the way effects are processed. Good luck reproducing this effect with OpenAL, because EAX is insufficient.

Here are some screenshots of ZDoom's DSP graph that may help. (Ignore that the FMOD ChannelGroup Target Unit is disabled in all of these. That's just because I alt-tabbed away in order to take screenshots of the profiler.)

This is the graph without any effects.

nofx.png (11.06 KiB) Viewed 968 times

This is the graph with the water effect.

water.png (11.24 KiB) Viewed 966 times

This is the graph with EAX-compatible reverb. Note the new SFX Reverb unit that has been added to the graph.

eax.png (17.22 KiB) Viewed 965 times

Enabling the water effect and the EAX effect at the same time is just a matter of enabling the corresponding DSP units simultaneously.

[Chris]

That's about as confusing as the code itself. :/ Considering I've never worked with FMOD before, I don't understand its terminology or what simply happens to a sound when it plays. In OpenAL, you basically have something like:

Code: Select all • Expand view

buffer->source---->filter---->output
          |                     ^
          |                     |
          v--->filter-->effect--^
          |                     |
          ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
          |                     |
          >--->filter-->effect--^


where the number of filter->effect chains is dependant on the number of auxiliary sends you have (software currently implements just one). You always get at least one filter as long as you have EFX (on the direct/dry path), though, so with one send, you get two filters, plus an effect (and the reverb effect has its own filter parameters). A filter can be a low-pass, high-pass, or band-pass (software currently only has low-pass), and an effect can be eax-style reverb, standard reverb (subset of eax reverb), chorus, echo, etc (though software currently only has one or both reverb types).

EDIT to note, the number of sends you have is the number of different active effects you can have.. so with one send, every source would use the same effect, or not use an effect; though each source can have it's own set of filters). /EDIT

Currently, I have water setting a dry path low-pass filter and reducing the pitch on "pausable" sfx, while the environment takes a filter->effect chain which currently applies to all sfx (it too can be made to apply only to "pausable", though the FMOD renderer doesn't seem to do that; the environment reverb is applied to all sounds, including the menu).

[Chris]

Here's the latest patches, against r1293. The music and sfx volumes are independant, the proper libs are added to the cmake win32 path (I hope), and reverb is mostly working with "standard"/I3DL2-compatible reverb. I plan on optionally using EAX-compatible reverb so all the reverb properties will be potentially used, but I haven't implemented this in OpenAL Soft yet so I can't test it.

Note that if you use OpenAL Soft, the last release will probably produce horrible reverb (the GIT/SVN version has a much nicer reverb implementation). For that, I'll probably be releasing a new version of the lib by the end of the week. Creative's software drivers should have a good reverb, and for the "Generic Hardware" (ie. DSound3D wrapper) device, or another hardware driver, it should use your hardware's reverb.

[Blzut3]

The music and sfx volumes are independant

Much better!

[bagheadspidey]

Here's what happens when I run this:

Spoiler: =(

owner@vaio-fs:/usr/src/zdoom-svn$ ./zdoom
ZDoom v2.2.0 - SVN revision 1291M - SDL version
Compiled on Nov 18 2008

M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
adding /usr/src/zdoom-svn/zdoom.pk3
adding ./doom2.wad (2919 lumps)
I_Init: Setting up machine state.
CPU Vendor ID: GenuineIntel
Name: Intel(R) Pentium(R) M processor 1.73GHz
Family 6, Model 13, Stepping 8
Features: MMX SSE SSE2
I_InitSound: Initializing FMOD
FMOD Sound System, copyright � Firelight Technologies Pty, Ltd., 1994-2008.
HSample rate 4000 is unsupported. Trying 48000.
V_Init: allocate screen.
S_Init: Setting up sound.
ST_Init: Init startup screen.
P_Init: Checking cmd-line parameters...
G_ParseMapInfo: Load map definitions.
S_InitData: Load sound definitions.
Texman.Init: Init texture manager.
TEAMINFO_Init: Load team definitions.
LoadActors: Load actor definitions.
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init miscellaneous info.
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
Resolution: 640 x 400
zdoom: /usr/src/zdoom-svn/src/sdl/i_system.cpp:168: void I_FreezeTimePolled(bool): Assertion `TicFrozen != 0' failed.
Aborted