The WIP Thread

[Chris]

So I sat down and did some tweaks to dpJudas's software sound mixer he made for Chocolate to get things like MIDI working, and I did some recordings comparing it to the OpenAL sound code to get a direct comparison. Here's OpenAL vs native

I think I like the native version more, but I need to be too weary comparing just to DosBox, since I don't quite know how accurate it is. The native version definitely "feels" a lot better when it comes to things like the explosions.

The first thing I notice is that native has more aggressive distance attenuation. Sounds are more quiet as they go into the distance, which gives closer sounds more impact. OpenAL can do a sharper rolloff like that, but if you're going for accuracy, you'll first want to find how native calculates a sound's distance volume. Something else to consider is the resampler being used, as that will subtly-or-no-so-subtly change the sound's perception. OpenAL Soft defaults to linear, though has options for nearest (point), cubic, and a couple sinc filters. If native uses nearest resampling, you may want to set that for comparing.

[InsanityBringer]

Interestingly so far as I can tell the only distance falloff effect is a linear modification to gain, though I'm not certain if the effects of gain are linear in OpenAL Soft (it's just a sample * volume in the native mixer). The OpenAL source is just a source with all attenuation turned off and oriented smoothly around the player, since the only input into HMI SOS from the Descent code is a pan angle. With regards to the resampler, I'll give that a try. The native mixer is using nearest and I'll suspect that HMI SOS is doing something similar. Devices like the SB16, after some searching, had an output of 22050hz in stereo mode and I assume it's using that mode and then doing nearest resampling for the original game's 11025hz sources.

[Chris]

Interestingly so far as I can tell the only distance falloff effect is a linear modification to gain, though I'm not certain if the effects of gain are linear in OpenAL Soft (it's just a sample * volume in the native mixer).

The effect of gain is linear in OpenAL Soft, yes (out_sample = in_sample * gain). If the OpenAL code just handling a gain and pan, and not calculating the distance attenuation itself, I'm not sure why the volume seems different. How exactly did you turn off attenuation?

[dpJudas]

Devices like the SB16, after some searching, had an output of 22050hz in stereo mode and I assume it's using that mode and then doing nearest resampling for the original game's 11025hz sources.

There is a very good chance that the original sound heard on a DOS computer is best produced by doing a nearest scale from 11khz to 22khz. Best done by doubling each sample when uploading it to OpenAL. Then have OpenAL itself use the default linear, or possibly the higher quality cubic/sinc filters to get it from 22khz to 48khz.

DOSBox may not be representative of how it sounded on a real audio card because afaik it relies on the Windows resampler getting from 22khz to 48 (or whatever your sound card is set to use in Windows). If it uses a nearest rescale internally, effectively what my mixer code did, then that most certainly would not match what came out of speakers back in the 90's.

In general keep in mind my code uses the easiest and most dumb way possible to get some audio output. It often gets closer to what they did in the 90's simply because it is also the fastest way, but it in no way guarantees this is what the Descent audio library did back then.

[Graf Zahl]

My stance of "original sound from the 90's" is that it's impossible to define. Different sound cards had different capabilities and we'll never know how these cards dealt with upsampling, it may differ just as much as other features on these cards. I still have an OPL recording from Doom.exe on a trusty old Sound Blaster card on CD and it sounds nothing like all those OPL emulators out there. Who says that it is different for digital sound effects?

I just repeat what I said when the upsampling became an issue with Raze: A lot of what's defined "original" is just the result of poor emulation of this old hardware. I've never seen any emulator get it right.

[leileilol]

DOSBox doesn't implement SB audio filters, but PCem does. You might want to check out Descent in that, the status window should also report back the sampling rate currently given to the card (for Descent 1 it's 11025Hz 8-bit stereo for the SB16 driver, and for Descent II it's 22050Hz 16-bit stereo for the SB16 driver)

The filters implemented for the SB16 on that does satisfy one particular vocal SB16 accuracy purist, so there's that... there's also the factor that Creative's ~1994 DOS drivers for SB16 (with the big bloaty TSRs) also set a higher default bass and treble setting.

[InsanityBringer]

Yeah, I'm a bit weary about using DosBox as my only comparison. I suppose at a really academic level, it might be somewhat representative of what HMI SOS is outputting before the card does anything to it, but obviously the card's a whole different beast here. Probably as good a time as any to finally work out PCem. I do also happen to have an old 386 in my house, it's not a great device for actually playing games like Descent on, but it's loaded with a GUS and I have a Sound Blaster 16 around these parts so it might be good for potentially getting reference audio recordings. If it still works, that is...

The effect of gain is linear in OpenAL Soft, yes (out_sample = in_sample * gain). If the OpenAL code just handling a gain and pan, and not calculating the distance attenuation itself, I'm not sure why the volume seems different. How exactly did you turn off attenuation?

I do a

Code: Select all

alSourcef(source, AL_ROLLOFF_FACTOR, 0.0f);

when creating sources and then I position them like so: (the listener is always at 0, 0, 0 with default orientation)

Code: Select all

	float x, y;
	float flang = (angle / 65536.0f) * (3.1415927f);

	x = (float)cos(flang);
	y = (float)sin(flang);

	alSource3f(sourceNames[handle], AL_POSITION, -x, 0.0f, y);

and setting the volume is a

Code: Select all

	float gain = volume / 32768.0f;
	alSourcef(sourceNames[handle], AL_GAIN, gain);

With the original interface the game used to HMI SOS, you only have a pan angle to work with, so the positional sound is pretty basic. If I ever "crispy-ify" this, I want to do full positional 3D audio with OpenAL, since with the right features it could sound really nice I feel. The full source I wrote can be found here, it's not the greatest code and it shows a lot of signs of just "get it working"

Ah, this accuracy diversion really came out of nowhere with regards to the project, but ever since I've gotten the texmapper to be faster and more accurate to the original game (in its thousands of bugs and oddities glory), it feels like as good a time as any to address these things.

[Chris]

I do a

Code: Select all

alSourcef(source, AL_ROLLOFF_FACTOR, 0.0f);

when creating sources

Looks right.

and then I position them like so: (the listener is always at 0, 0, 0 with default orientation)

Code: Select all

	float x, y;
	float flang = (angle / 65536.0f) * (3.1415927f);

	x = (float)cos(flang);
	y = (float)sin(flang);

	alSource3f(sourceNames[handle], AL_POSITION, -x, 0.0f, y);

This looks weird. I'm going to presume it works since I didn't hear any panning oddities in the example, but this means an angle of 0 is directly left, and 90 degrees (flang=+pi/2, or angle=+32768) is directly behind. A quick look at other parts of the code, though, I notice a couple places that do this:

Code: Select all

alSource3f(MusicSource, AL_POSITION, 1.0f, 0.0f, 0.0f);

which is placing the source directly left of the listener. It doesn't do anything for stereo sounds (they're non-positional by default), but mono sounds would play from the left. It would be better to use 0,0,0 for sounds that shouldn't be positional.

and setting the volume is a

Code: Select all

	float gain = volume / 32768.0f;
	alSourcef(sourceNames[handle], AL_GAIN, gain);

Assuming volume is in the range of 0 (silence) and 32768 (max volume), that looks correct. Is that the expected range?

[InsanityBringer]

yeah, 32768 should be correct, its what the volume gets set to when a attenuation-free sound is played with the master volume slider is at max (IE, ui sounds). The angle code should be correct, I believe the interface to HMI SOS used a unsigned WORD for the pan angle. The position for music sources and the like is definitely bogus, I probably just copied something around and didn't notice what I was doing. MIDI music generally won't be stereo, but it's possible HQ music (the game can currently load OGG music substitutions, and since there's a comparable "contained in header" loader I want to add FLAC too) isn't so it's worth correcting.

and as a side thing, have a nightmare video conceived from the depths of failed texture mapper experiments contained in the game's source code release

[Chris]

yeah, 32768 should be correct, its what the volume gets set to when a attenuation-free sound is played with the master volume slider is at max (IE, ui sounds).

Then unless the volume is not representing a linear gain, that's correct.

The angle code should be correct, I believe the interface to HMI SOS used a unsigned WORD for the pan angle.

In that case, 0 would be left-panned and 65535 would be right-panned. You'd want to change that to

Code: Select all

float flang = (angle / 65535.0f) * (3.1415927f);

as a WORD couldn't get to 65536 for a full right pan (it'd be very subtle and probably not detectable, but still technically..). Also in that case you'd want to negate the y value, since -Z is front in OpenAL (like OpenGL). As it is currently, y will range from 0...+1...0, making it rotate behind the listener so someone with surround sound or HRTF would get the wrong perception.

[ImpieTwo]

updated this dumb mod.

[AFADoomer]

Playing around with model-based detailing...

[Captain J]

Certainly retrospective to Aperture science pattern. Even that shiny platform too!

[Tormentor667]

This looks awesome AFA!

[Morgondagen]

Enemies react when their attacks are blocked
[youtube]https://youtu.be/iWnlF-a6aGs[/youtube]