[taylor]

First test build of new sound code.  There are several known problems, but as there is more to something like this than just the code, early test builds are needed to work out the finer details quickly.  This code is intended for post-3.6.12, so there is plenty of time to test things out and get it all working before the code hits SVN.  These test builds will be kept in sync with the 3.6.12 RC process so as not to force the use of one build over the other, however just remember that any sound related bugs are NOT to be filed in Mantis when using these test builds.


Windows builds here (debug SSE, release SSE2):  http://icculus.org/~taylor/fso/testing/20100422-win32.7z

Mac builds Inferno and Standard based on Antipodes 5941 with patch from 2010-02-23 (chief1983)

Patch:  http://icculus.org/~taylor/fso/misc/new_sound.7z
(NOTE:  This is a git diff, not a svn diff.  TortiseSVN will not accept it as a valid patch, but Linux and OS X patch utilities should handle it just fine.  Apply with "patch -p1 < new_sound.diff".)


Changes from 20100216 build:

• Sync with RC1
• fix buffer leak
• fix reverse doppler (maybe)
• fix looping for streaming audio
• fix fade/cutoff for steaming audio (should fix the gap between music tracks)
• voice capture disabled in code
• various minor fixes and improvements

Few notes about the changes in this build:

• All of the DirectSound code has been removed.  The code is now 100% OpenAL
• 3D sound is fully implemented, but maybe not fully working.  It's difficult to test such things using only headphones.
• Code should be slightly more efficient and with a few less (and new) bugs
• Capture support is implemented (for multi voice), however you are advised to not test it just yet
• New initialization setup should reduce problems with using faulty OpenAL devices
• EFX support (ie. EAX 2.0).  See notes below.

Also, the following Mantis bugs should/may be fixed:

1854: Effects volume is muted at the second dot, instead of the first one
1632: ambient music doesn't return after fighters warp out
1769: play-sound-from-file: sound file is re-played after Alt-TAB
1047: Game cannot play more than one beam charge sound at once
0058: Flyby sound interupted


Notes regarding specific feature changes:

EFX:  EFX is supported, but only in the basic sense.  There is still a question over exactly how retail actually made use of EAX effects in the first place.  The thinking is that some of that code was ripped out of the original source release, but the code that does exist as well as various comments in the code indicate that this may not be true.   So if nothing was ripped out, then what is currently implemented is just like in retail.  If anyone has any further info on whether or not this code actually functions the same please let me know.

Because EFX in software can be rather CPU intensive, it is disabled by default.  To enable it in Windows, create a new key under "Volition\FreeSpace\" named "Sound", under which create DWORD value "EnableEFX" set to 1.  For Linux/OSX, edit your fs2_open.ini file and add a "[Sound]" section, with "EnableEFX=1" in it.  If this makes the game too choppy then you can try lowering the sample rate to improve performance by putting "SampleRate=22050" in the "Sound" key/section.

New device detection:  The device specified in the Launcher is no longer used.  The code will now try all available devices and simply use the first one that works (supports enough sound sources for the game).  You can set a preferred device with "PlaybackDevice=<device_name>" in the "Sound" key/section mentioned previously.  During init it will try the preferred device, the default device, and everything else, in that order.  So there is no guarantee that your preferred playback device will be the one chosen by the game.  The debug log will show exactly which device is in use however, and a value of "+OpenAL" in the debug_filter.cfg file will additionally list all available devices that the game is checking.

3D sound:  This has only been tested with headphones to this point, so testing it on a good 7.1 surround sound setup would be nice.  Any audiophiles are also encouraged to test and give feedback on how this sounds.  The settings could be off and need tweaking, since while I know the technical aspects of the code, I don't know the technical aspects of sound mechanics.

Voice capture:  The capture code is implemented and working, however the voice capabilities have been disabled for the foreseeable future.  Although the new capture code itself is working fine, the rest of the retail code which handles voice is a horrible mess of bugs, memory errors, and wild assumptions about how any function will work.  Fixing this will require ripping out and rewriting various parts of the retail code.  As such this feature has been disabled in the code until that work has been done.  There is currently no time frame for this to be done however.

[chief1983]

Awesome.

[Vasudan Admiral]

Wow, I've not heard FS sound like that before - made the battles sound brilliant! Doppler pitch shifiting effects and no cutoff of one sound when the next one plays that I could hear for anything (I think shockwaves used to do it lots too). The flak in particular sounded a lot more frightening than I've ever heard.

Not sure if these are the kind of things you deal with, but a couple of slight problems I noticed:
1) Sometimes seemingly dependant on your orientation and proximity to a large ship, your own weapons would be played as though they were coming only from one side of your ship.
2) 3d directional sound really shouldn't apply to messages - it was playing from the direction of the ship speaking, which just seemed really really odd.
3) Some effects really shouldn't have the doppler effect - in particular beams and the warp sound effect because the pitch shift really sounds quite bad - and it gets really noticable with the warmdown sound effects of beams which don't match the beam firing sound effect in pitch or volume.

[Darius]

Had a test with beta version of Age of Aquarius, "Universal Truth".

Apart from the obvious improvement in sound quality, not much else to report except music playback from play-sound-from-file doesn't loop when previously it did, and heard a slight delay between the battle tracks when switching from one track to the next.

[chief1983]

VA, some of those sounds that do or don't have effects may be controlled by the retail sounds table, wouldn't they?  We might not exactly have control over that in retail.  If the original tables said it should use 3d sound, then the only fix would be to change it in the mediavps I think.  Could be wrong though.

[Spoon]

I tested it with my 2.1 setup. Once the beams start shooting and the flak starts firing, sounds like your own weapons firing will no longer work. Voices also stop working then, the debug says that there are no soundfiles for that line.

[taylor]

I tested it with my 2.1 setup. Once the beams start shooting and the flak starts firing, sounds like your own weapons firing will no longer work. Voices also stop working then, the debug says that there are no soundfiles for that line.

Post your debug log and I'll take a look.  No ideas what the problem is at the moment though.  That behavior is the sort of thing I might expect from the old code, where it runs out of sources, but the new code doesn't allow for that (it would totally disable sound in such a case).

[Fury]

As much as I love to test and debug things, I really would like to get SSE2 r-builds too so that I can enjoy better audio when my focus should be testing or playing missions. Pretty please?

[chief1983]

When the diff starts working this might be a good Antipodes branch candidate.  Not sure what else in the pipeline is currently ready.

[Zacam]

I was planning on utilizing Antipodes for INF integration testing (so as not to break Trunk) followed by SDK'ing the current pre-compiled libs, but I think we can stick this in between those two.

[taylor]

I don't really plan on making use of Antipodes for these sound code changes.  Merging this stuff back into trunk when it's done would be a pain, particularly considering the number of little commits it's going to take to tweak all of the settings.   I don't really have the time to mess with all of that.  It's quicker and easier for me to just work with it in my git repo and then make a single commit to trunk when it's all working.

The other thing that I'm working on would probably be a prime candidate for Antipodes though, since it's definitely going to break things, and will be good to have more than one pair of eyes on it.

[chief1983]

It was more because antipodes would give us a chance to make sure it builds on all platforms, especially since there's probably file additions/removals going on we'll need to update project files, etc.  Just hate breaking trunk until someone manages to get all the projects sorted out.

[taylor]

It was more because antipodes would give us a chance to make sure it builds on all platforms, especially since there's probably file additions/removals going on we'll need to update project files, etc.  Just hate breaking trunk until someone manages to get all the projects sorted out.

Hmm, good point.  What I can probably do is, when the code is stabilized otherwise: commit it to Antipodes, let the project files get verified/updated, merge those changes back into my git tree, then squash it down for a single commit to trunk.  That should be pretty painless for all of us.

[taylor]

As much as I love to test and debug things, I really would like to get SSE2 r-builds too so that I can enjoy better audio when my focus should be testing or playing missions. Pretty please?

I'm not really set up to do Windows builds these days, so it takes a lot of time and effort to just get those two debug builds done.  When I post the patch (hopefully tonight) somebody might make the other builds though.

[Cobra]

While I like how some of the new sounds are like now (like the countermeasure sound being more of a 'boom', or the beams having a shriller sound and sound that much more menacing), I've noticed that some of the other sounds seem totally different. The subspace opening sounds don't really sound at all like they used to, for example.

[taylor]

While I like how some of the new sounds are like now (like the countermeasure sound being more of a 'boom', or the beams having a shriller sound and sound that much more menacing), I've noticed that some of the other sounds seem totally different. The subspace opening sounds don't really sound at all like they used to, for example.

Yeah, I've noticed that one as well.  There are a few sounds which seem a little odd with the new code.  I'm not a sound guy though, so exactly what affects that isn't something that I know.  But that's one of the main reasons this build is here, to help me figure out what sounds weird, why, and how to fix it.  I'm also not sure if the sounds are simply different from how they were in the previous code, or if they actually differ from retail (the original DS/DS3D behavior which this code is trying to replicate).

[Cobra]

Well, when I think about it, it sounds as if it's defaulted to 3D Sound, since I remember once  turning A3D on in FS1 and getting similar subspace vortex noises.

[chief1983]

Hmm, good point.  What I can probably do is, when the code is stabilized otherwise: commit it to Antipodes, let the project files get verified/updated, merge those changes back into my git tree, then squash it down for a single commit to trunk.  That should be pretty painless for all of us.

Sounds good to me.  I can help with any cross-platform build testing since I usually have immediate access to all 3.  Oddly Windows is sometimes the hardest for me too since I'm on my MacBook more than my PC and the linux box is my friend's always-on server.  At least my MacBook has a Windows 7 VM but it's running VS2010 RC1 which still has its own issues.

[Zacam]

It was more because antipodes would give us a chance to make sure it builds on all platforms, especially since there's probably file additions/removals going on we'll need to update project files, etc.  Just hate breaking trunk until someone manages to get all the projects sorted out.

Hmm, good point.  What I can probably do is, when the code is stabilized otherwise: commit it to Antipodes, let the project files get verified/updated, merge those changes back into my git tree, then squash it down for a single commit to trunk.  That should be pretty painless for all of us.

You also don't have to do it all you know. I can sync Trunk and Antipodes via creating a diff between the two. So you can put the code into antipodes (or provide the DIFF and I can sync Antipodes and then commit the diff), more people than just you can poke around with and build with it and then, when everybody is happy, it can be sync'd back to trunk. (See PNG and all it's little commits and how it moved to Trunk as an example).

And hell, there is no reason it can't be done now and put in to trunk once .12 is final, or if we get it done during the RC phases to folks satisfaction, actually have it IN Final.

[Fury]

Oh boy. Yeah, I think we'll be needing those r-builds 'cause playing BP at 12fps is no fun.