[Goober5000]

I'm in favor of that.  Let's merge the last few bug fixes and get 3.6.12 out the door.  The sound code can wait until the next release.  (And there really isn't a .patch for it because the code is still in flux.)

The next release should also have the OGG code building from a sub-project instead of a static lib.  I think that can be done in short order.

I can merge the patches in the 3.6.12 thread on Sunday if no one does it before then.

[Fury]

Could someone be as kind as to compile new audio builds based on latest trunk?

[chief1983]

Might want to fix the retail breakage first

[Fury]

What retail breakage?

[chief1983]

2185.  Looks fixed now actually.

[taylor]

First post updated with new build link, also available here: http://icculus.org/~taylor/fso/testing/20100422-win32.7z

Aside from any new bug reports the new sound code is now feature complete.  There are still a few things to work on the in future but I don't plan to start coding on that stuff for a few months at least.  Diffs will be available by the weekend; one that is a complete patch against the 3_6_12 branch and another which just has the changes from the last patch for Antipodes.

As far as whether or not this code gets into 3.6.12 or not, it doesn't really matter to me.  I didn't originally plan to have it included in 3.6.12 in the first place so if it doesn't make then that is fine with me.  I will just leave it up to chief to decide if it goes in or not.


Changelog from the previous build:

• Sync with latest 3_6_12
  
  
• Fix a memory issue in CFILE (not sound code related)
  More memory was allocated than needed to be when doing a file search with multiple extensions.
  
  
• Fix possible endless loop in set-energy-pct SEXP (not sound code related)
  
  
• Fixes for ADPCM code:
  
  • Less memory usage for decoding
  • Support both 8 and 16-bit decoding instead of just 16-bit
  • Improve error handling
  
  
• Add support for IEEE FLOAT PCM format
  This can be used natively if the OpenAL implementation supports it, otherwise it will be converted to something that will work on any system.
  
  
• Add a "Quality" ini/registry option for sound
  This is added under [Sound] in the ini file (Linux/Mac) or under the "Sound" key in the registry (Windows).  It is a DWORD value and can be set to 0 (Low), 1 (Medium) or 2 (High), with "1" being the default.  The default value is the same as it has always worked before.
  
  
  • The low setting ("0") will convert IEEE PCM, Vorbis, and ADPCM files to 8-bit when loading.  Also the default sample rate will be set to 22050 Hz.
  • The medium setting ("1") will convert IEEE PCM, Vorbis, and ADPCM files to 16-bit when loading.  The default sample rate will be set to 44100 Hz.
  • The high setting ("2") will convert ADPCM files to 16-bit when loading.  IEEE PCM and Vorbis files will be left in their native 32-bit float format if the OpenAL implementation supports it, otherwise they will be converted to 16-bit.  The default sample rate will be set to 48000 Hz.
  
  The quality setting simply sets the default sample rate, it will still use whatever is specified with the "SampleRate" setting if it is set.
  
  
• If a sound is flaged as being for 3D, and it is stereo, then it will be converted to mono
  Stereo sounds can not be used with positional audio, so this is required for it to actually be usable as a 3D sound.  The previous build just failed over to using 2D playback for such sounds.
  
  
• Fix an issue where audio format conversions are done but values are not updated
  This is not a big problem, but it throws off certain things where math based on sound format values would be different from what actually ended up getting loaded.
  
  
• Add support for specifying custom sound environments (EFX/EAX) to sounds.tbl
  An sample is attached to this post.  It includes three examples: a completely new effect, an effect based on an existing one but modifying a few values, and setting a default effect to use when no other one is specified.
  
  
• Add mission specific sound environment support
  In the mission specs editor in FRED there is now a "Sound Environment" button.  This will give you a dialog with which to pick a sound environment, modify a few values, and test it out.  When selecting a different environment/effect it will show the default values for volume, damping, and decay time.  Those values are optional and are not included in the mission file unless you change them from the default.  You can preview you changes by selecting an audio file and then hitting the play button.  It is recommended to try several different audio files out however, as different sounds can be affected a bit differently based on the settings in use.
  
  
• Add SEXPs for modifying sound environment
  "set-sound-environment" will set one of the sound environments as active with optional values for volume, damping, and decay time.  The order of the optional arguments is not important, however it is important that each be followed with a numerical value (a value multiplied by 1000).  "update-sound-environment" will change the values of volume, damping, and/or decay time for the current sound environment.  These SEXPs can be used to change the sound environment based on proximity to certain objects like ships or asteroids, or various other uses.
  
  
• Modify play-sound-from-file SEXP to have an additional option
  This additional option will tell it to play the file as a sound effect and therefore apply the current sound environment to that sound.  Normally sounds played from this SEXP are treated as music types and will not have any of the environment effects applied to them.
  

... I think that basically covers it.  If there are any new bugs let me know.  I think that pretty much everything has been worked out though. *crosses fingers*

[attachment deleted by admin]

[Fury]

Add a "Quality" ini/registry option for sound

Couldn't we have this in the launcher instead? I don't think a lot of people will be aware of this otherwise.

Add support for specifying custom sound environments (EFX/EAX) to sounds.tbl

You say sounds.tbl, but attached file seems to be sound_env.tbl. Are those default values in your example that are used even without this tbl-file?

All in all, sounds very impressive and can't wait to try it out.

[taylor]

Add a "Quality" ini/registry option for sound

Couldn't we have this in the launcher instead? I don't think a lot of people will be aware of this otherwise.

It can be set via the launcher (once added to it) just like the rest of the sound options in the registry.  It's never going to be a cmdline option though, if that is what you were thinking.

You say sounds.tbl, but attached file seems to be sound_env.tbl. Are those default values in your example that are used even without this tbl-file?

No, that's just how I named it.  It is just a snippet of the entry for sound environment which goes into sounds.tbl.

The default values listed for the "EFX Defaults" entry and the values used for anything that you don't specify in an effect that you create.  But by default the EAX 2.0 effects are hard coded to always be available: Generic, Padded cell, Room, Bathroom, Living room, Stone room, Auditorium, Concert hall, Cave, Arena, Hangar, Carpeted hallway, Hallway, Stone corridor, Alley, Forest, City, Mountains, Quarry, Plain, Parking lot, Sewer pipe, Underwater, Drugged, Dizzy, Psychotic.

The "$Template" option the tbl will allow you to base a new effect on one of those existing ones and then you can modify one or more of the values to create an entirely new effect for use in a mission or via SEXP.

[Nemesis6]

Sounds interesting(get it? sounds?). One tiny thing I was thinking about - Huge explosions echoing. Anyway, gonna try out the new build and see if I can find some errors.

[taylor]

Here are the promised diffs...

against trunk (r6075): new-sound-trunk.diff

against 3_6_12 (r6069): new-sound-3_6_12.diff

from previous change patch (doubt it will apply cleanly to Antipodes, sexp code will probably conflict): changes4.diff


The trunk patch had a few conflicts but I think that I got all of that worked out so that it will still build properly on Windows (test build seemed fine on Linux).

[Spoon]

Click link in first post:

> look
It is pitch black. You are likely to be eaten by a grue.

> find link
You stumble around trying to find http://icculus.org/~taylor/fso/testing/201000422-win32.7z, but your hands grasp nothing except dirt and rock. You eventually touch something solid, and lift it up. As you bring it to your eyes, you squint to find that it is a fully stocked dagger of lightning.

> quit
Your score is 25 out of a possible 375. This gives you the rank of hoser.
Are you sure you want to give up [y/N]? : y

404 not found

wut

Oh and for the record, the latest build still instantly crashes the launcher for me. So something is pretty wrong with it.

*edit, no that anyone seems to care but 5.5f seems to be at fault here somewhere. Directly running the build or using 5.5e works

[QuantumDelta]

I found an odd problem with this one, I'm still using 5.5e (mostly, because 5.5f wont run my str folders mod.ini for some reason, gonna try it with another mod / retail in a sec).

Basically, Fraps while set to record windows sound (= all sound basically) still wont pick up any sound from either the 6069 build that was custom done for the WiH beta people, nor the 201000422 windows INF SSE2 build.

[chief1983]

Windows Sound might be DirectSound, whereas this might bypass that and call through the driver directly using OpenAL.  Just a thought.

[QuantumDelta]

Windows Sound might be DirectSound, whereas this might bypass that and call through the driver directly using OpenAL.  Just a thought.

The impression I was given was that the "Record Win7 sound" button just sent all sound from your default playback device to the raw file being recorded, I have no way of telling for sure, and the only other option is to record from is 'record external input' which again, is just the default device.
Fraps doesn't have much at all that will let a user work around the problem. :<

[QuantumDelta]

Also, a few things;

Coming back from alt-tab makes music play regardless of music volume (read; if it's set to 1 light(off) it plays at significant volume still) - although this doesn't seem to happen in mission, only in the interface screens (confirmed it in mainhall and command brief at least)


I really, really, dislike the sound distortion on quite a lot of the sound effects.. any nearby engine sound sounds reallllllllllllllly bad the moment you hit afterburners, and several weapons sound terrible too.
Realism, it may be, but if you insist on having sound effects this obnoxious could you make the doplar effects launcher-flags please?
I could probably write pages about all the sounds that are just wrong because of the doplar distortion but I may as well just say 'all of them'.

Onto the good;
The surround sound on 7.1s (when not distorted) is pretty much perfect, I love it, awesome work.
Multiple sound sources seem to be working great too.
EAX SEEEEEEEEEEEMs to be working well, it's kinda hard to tell ;P

[Fury]

Those who have problems with the 5.5f beta launcher, should report problems here: http://www.hard-light.net/forums/index.php?topic=68369.0

Those include Spoon, QuantumDelta and Dilmah G and whoever else have experienced problems with the beta launcher.

[QuantumDelta]

Been using this build a bit more, I still hate all the pitch/tone shifting, but God DAMN Taylor nice work on the 7.1 implementation.

I really, really hope this stuff ends up working with fraps + with a flag simply for the doppler stuff.
'Tis awesome work, really.

[chief1983]

Engine sounds shouldn't be using doppler (I'm guessing they're 2d sounds, which none of them should be?), and it does sound like a lot of people would like to see the overall doppler effect lessened.  I still haven't put it through its paces but if it's going to screw up FotG's TIE sounds then yeah, I'd definitely like some sort of control over that too.

[Herra Tohtori]

Well, doppler effect depends on relative speeds [EDIT: when the speed of waves in medium is fixed]... If you want less doppler shift, reduce the speeds.

I would like to ask one thing though. Do the doppler shifts assume space as a medium for sound to travel in, or does it work using the player co-ordinates as a fixed reference frame and simply calculate them using relative velocities compared to player ship?

I mean, in an atmosphere there's a difference in doppler shifts based on whether you're moving through the medium in which sound traverses in, or whether the sound source is moving in the medium and you're stationary...

I'm assuming that the latter option is true, since the more complex way of calculating doppler ****s involves taking the speed of the observer relative to medium into account and, well, sounds in FS2_Open seem rather instantaneous anyway...

EDIT: Actually...

f = (c / (c + v)) f₀

...where c is the speed of sound, v is the relative velocity (positive for target moving away, negative for target moving towards), f is observed frequency and f₀ is the root frequency of the sound. This is the formula for calculating doppler effects for a listener who is stationary relative to the medium, which will work well enough for FS2_Open.

By changing the assumed speed of sound, it's fairly simple to change the overall doppler effect, so I retract my earlier statement and refine it a bit.

Special circumstances arise when relative velocity == wave motion velocity...

And, of course, this is an approximated formula. True solution of doppler shifts would possible cause sound effects to play backwards[/b] when moving away from the sound source at mach 2. Though that would probably be a bit... complicated to implement in this sort of case.

[chief1983]

Actually we have a ship that does fly at ~350 m/s I think currently, so if they passed each other they'd be flying away from each other at roughly mach 2...