Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: taylor on February 16, 2010, 09:40:57 pm
-
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 (http://icculus.org/~taylor/fso/testing/20100422-win32.7z)
Mac builds Inferno (http://swc.fs2downloads.com/builds/OSX/FS2_Open_newsound_INF.tar.bz2) and Standard (http://swc.fs2downloads.com/builds/OSX/FS2_Open_newsound.tar.bz2) 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.
-
Awesome.
-
Wow, I've not heard FS sound like that before - made the battles sound brilliant! :D 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.
-
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.
-
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.
-
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.
-
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).
-
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? :)
-
When the diff starts working this might be a good Antipodes branch candidate. Not sure what else in the pipeline is currently ready.
-
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.
-
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.
-
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.
-
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. :)
-
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.
-
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.
-
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).
-
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.
-
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.
-
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.
-
Oh boy. Yeah, I think we'll be needing those r-builds 'cause playing BP at 12fps is no fun. :p
-
Well, it's just sound related, you could probably test with a mod that's a little less intense :)
-
BP2 has several new sound effects which are truly awesome with this audio code. I don't want to miss out the aural sensation it gives. :(
-
BP2 has several new sound effects which are truly awesome with this audio code. I don't want to miss out the aural sensation it gives. :(
Here are SSE2 release build versions: http://icculus.org/~taylor/fso/testing/20100216-win32_sse2.7z
-
Yeah some of the doppler shifting is sort of funky on the beams and warp in and outs. But the rest, oh god, the rest. Fly bys sound awesome and the sound beams make when they impact a hull? Ultra-satisfying.
My only... not really a complaint but something I noticed. The some music seems to be a lot quieter, maybe its just me or maybe its just that the sounds are a lot louder now. But I had a harder time hearing music if a play-sound-from-file is being used. I checked with a retail mission and music played through the music.tbl sounds about right.
-
Yeah some of the doppler shifting is sort of funky on the beams and warp in and outs.
If anyone has any ideas on how to deal with this I'd be interested in hearing about them. I can make some tweaks, but I'm basically just flying blind on this since I don't really know how manipulating the settings will actually affect sounds.
My only... not really a complaint but something I noticed. The some music seems to be a lot quieter, maybe its just me or maybe its just that the sounds are a lot louder now. But I had a harder time hearing music if a play-sound-from-file is being used. I checked with a retail mission and music played through the music.tbl sounds about right.
I'll give it a look, but I'm not sure that any changes were made which would affect that (unless it's a bug of course). If anyone else notices this same thing please let me know.
-
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.
Confirming this. It is really most annoying.
-
O hai, DarthGeek from IRC here. Been testing this for a few minutes and I've already noticed a bug: Doppler effects seem to be reversed. When I'm flying towards them, they're lower-pitched, and when I'm flying away, they're higher pitched.
Also, it may be just me but the doppler shifting seems way too pronounced. IMO it should be a bit more subtle, so it sounds more immersive but you don't really notice it unless you're listening for it.
Other than that, great addition to the codebase! I never noticed just how outdated the sound engine is until now. :)
-
O hai, DarthGeek from IRC here. Been testing this for a few minutes and I've already noticed a bug: Doppler effects seem to be reversed. When I'm flying towards them, they're lower-pitched, and when I'm flying away, they're higher pitched.
Yeah, I get that too. I still like the countermeasure sound though.
I also forgot to mention that in one of my later playthroughs I noticed that while there was a LOT of stuff going on, a fighter that exploded right next to me was either completely drowned out or the sound didn't play at all. Just throwing that out there.
-
To add to my previous comment, it seems that the 3d sounds aren't attenuating like they should. If I turn Effects volume to the 2nd lowest, (since lowest mutes it), the effects my own fighter makes are as clear as day but and effects from something like switching weapons are near silent. Other 3d sound effects also seem to ramp up a lot as I get close to them. They can be real quiet but then get real loud if I approach them.
-
a slight delay between the battle tracks when switching from one track to the next.
I've always had this problem (I'm on a Mac) with the music for SWC--a small (maybe 1/4-1/2 second) halt both before the music cuts in at mission outset and between every transition. I just assumed it was the way the engine worked and the reason why all FS music fades out every normal and battle track instead of using direct segues. Getting seamless transitions to work on all platforms would be huge.
-
First post updated with new build. And with any luck that will be the last build before it hits SVN. :)
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
To add to my previous comment, it seems that the 3d sounds aren't attenuating like they should. If I turn Effects volume to the 2nd lowest, (since lowest mutes it), the effects my own fighter makes are as clear as day but and effects from something like switching weapons are near silent. Other 3d sound effects also seem to ramp up a lot as I get close to them. They can be real quiet but then get real loud if I approach them.
I wasn't able to reproduce this with the updated build, but I didn't try to reproduce it with the old build either. Give it a try with the updated build and see if it's any better.
Some of that may just be how the code works though. Distance culling is done in the code for 3d effects based on what is specified in the tables. If a sound is further away than that distance then it will not play. Unfortunately, when it is within that distance it can just suddenly be loud. That stuff is just set in the tables, so if the tables are off then there isn't a whole lot that I can do with the code. I'll see if I can tweak the settings a bit more to try and compensate better for it though.
-
Awesome, will test this as soon as I get home from work. :D
-
And for those who don't want to manually apply the patch that are using TortoiseSVN:
AudioCode.patch (http://www.mediafire.com/file/h2itmwmwnyj/AudioCode.patch)
-
Also, it may be just me but the doppler shifting seems way too pronounced.
I noticed this too, when flying along the hull of a capship while rolling around the forward axis. As I roll on, the sound from the capship engines wobbles a lot more than one would expect.
-
Well, pronounced doppler effects might be MORE realistic. The reason being:
I figure that since there is no sound in space, your fighter must be playing the audio for you, sort of like an in-cockpit surround system, in order for you to get a tactical advantage. It would turn its scanner/sensor findings into sounds that the pilot would hear and recognize. In the case of scanners failing, optical sensors would perform the task as well. I'm sure by the time we have giant lazor beams of death, we'll have computers capable of handling this. An increased doppler effect would make it easier to judge the velocity of sounds relative to you, increasing your tactical awareness.
-
And for those who don't want to manually apply the patch that are using TortoiseSVN:
AudioCode.patch (http://www.mediafire.com/file/h2itmwmwnyj/AudioCode.patch)
Applying the patch works, but the resulting code breaks FRED building:
2>..\..\code\fred2\management.cpp(382) : error C2660: 'snd_init' : function does not take 4 arguments
That line probably needs to be changed from
snd_init(0, 0, 44100, 16);
to
snd_init(0, 44100);
-
But we do have lasers of death, and they're _airborne_ (http://www.youtube.com/watch?v=MmkYcEcSLvA).
-
I was playing a very intense mission and halfway through it many sounds became garbled. Didn't happen on the older build.
-
Well, pronounced doppler effects might be MORE realistic. The reason being:
I figure that since there is no sound in space, your fighter must be playing the audio for you, sort of like an in-cockpit surround system, in order for you to get a tactical advantage. It would turn its scanner/sensor findings into sounds that the pilot would hear and recognize. In the case of scanners failing, optical sensors would perform the task as well. I'm sure by the time we have giant lazor beams of death, we'll have computers capable of handling this. An increased doppler effect would make it easier to judge the velocity of sounds relative to you, increasing your tactical awareness.
You really want to go there!? :p
Anyway, its not a big issue, and in the end, having pronounced effects is better than getting no effects at all.
-
I noticed this too, when flying along the hull of a capship while rolling around the forward axis. As I roll on, the sound from the capship engines wobbles a lot more than one would expect.
Doppler is supposed to be disabled for capship engine sounds. If it's not then it's a bug. I'll give it a check to make sure it's set properly.
Applying the patch works, but the resulting code breaks FRED building:
I can't build FRED, so that's not surprising. :) I'll be sure and fix it before the code ends up in SVN though.
I was playing a very intense mission and halfway through it many sounds became garbled. Didn't happen on the older build.
A debug log from when it does that would be very helpful.
-
Actually, as we have a diff now, to test it's Mac abilities (since I'm pretty sure it works in linux) I was going to go ahead and put this into Antipodes.
This will also help with Profiling the code and running Team "Analyze" on it as well.
If you'd rather I didn't, I won't as it is your code, but I think it'll provide the fastest turn around time and the fullest development in it.
-
Actually, as we have a diff now, to test it's Mac abilities (since I'm pretty sure it works in linux) I was going to go ahead and put this into Antipodes.
This will also help with Profiling the code and running Team "Analyze" on it as well.
If you'd rather I didn't, I won't as it is your code, but I think it'll provide the fastest turn around time and the fullest development in it.
That's fine with me. I was going to ask someone to test it under OS X anyway. I'll keep up with any changes that you make to it in Antipodes, just please don't commit it to trunk. I'll take care of that once the code is truly finalized.
-
Roger that.
-
I noticed this too, when flying along the hull of a capship while rolling around the forward axis. As I roll on, the sound from the capship engines wobbles a lot more than one would expect.
Doppler is supposed to be disabled for capship engine sounds. If it's not then it's a bug. I'll give it a check to make sure it's set properly.
Ok. Btw, something I forgot to mention earlier, it only happens if player ship is in motion (camping besides a capship and rolling won't produce the effect).
-
Ok. Btw, something I forgot to mention earlier, it only happens if player ship is in motion (camping besides a capship and rolling won't produce the effect).
Yeah, the formula is based on the position and velocity of both the source and the listener, so as long as just one is moving it will produce the effect.
But, after checking the code it did turn out that doppler was not disabled for capital ships when it should have been. I had made intended to fix that for this recent build, but apparently I made that change while in desperate need of sleep because I managed to screw up both the doppler disable and the attenuation rolloff for 3d sounds. :rolleyes:
So that turned out to just be a code bug. It shouldn't be a problem in future builds though. :)
-
Committed to Antipodes in 5933, with The E's FRED fix in 5934.
Added MSVC 6 and 2005 changes for compiling, leaving Mac OS-X project changes for compiling.
-
Looks like a couple of file changes are missing from that commit (may have been mistakes in the patch):
"code/sound/openal.h" was added
"code/directx/vdsound.lib" was removed
It appears that the project files have the full changes, it's just that those two file changes were not made to SVN.
-
Tried out the new build, the effects slider seems like it has a more noticeable effect (I don't know if you did anything, maybe its just me. Though its still not as quiet from the original sound engine on the second lowest setting). But my comment about the sounds being louder is still sort of there. I think part of it might be before you just had about one sound being played at a time, but now that you have like 30 sounds playing at the same time so all their loudness adds up and drowns out the background.
But I did some investigating and its probably the music I was using. It's relatively quiet compared to what's normally in game and after listening to something like Forced Entry in BP, the music there isn't drowned out at all. I guess its off to the audio editor with me.
So I'll withdraw my complaint and give you a new one. :p I find that if a sound goes from left to right, like if I roll near a capship, the sound goes quite abruptly from the left channel to the right. It doesn't sound like its gradually going from one channel to another. (Using headphones to test all this btw)
-
The OpenAL stuff, does it have any sort of built in support for telling it what the listening mode is, or does it just take that from the OS somehow, or what? Like headphones vs 7.1 vs 2channel speakers (headphones and 2channel speakers can be very different)
-
Looks like a couple of file changes are missing from that commit (may have been mistakes in the patch):
"code/sound/openal.h" was added
"code/directx/vdsound.lib" was removed
It appears that the project files have the full changes, it's just that those two file changes were not made to SVN.
Fixored. No idea why that took place, since the data is in the patch, but the work machine just failed to fully follow through.
-
The OpenAL stuff, does it have any sort of built in support for telling it what the listening mode is, or does it just take that from the OS somehow, or what? Like headphones vs 7.1 vs 2channel speakers (headphones and 2channel speakers can be very different)
I think that it gets the defaults from the OS, but it can be overridden by a config file. That is with OpenAL-Soft at least, not sure exactly what Creative's stuff does but it's probably about the same. Looking at one of the files in OpenAL-Soft I see that the DirectSound back-end does read the DS config by default and then override it with the user settings if they exist. So, I'm assuming that it will use whatever speaker config you have set in the control panel on Windows by default. And I'm betting that Creative's version does the same thing.
And I'm thinking that is the cause of Axem's new issue, it's just isn't set for 2-channel/headphones/whatever.
-
And, double post because it is relevant.
Fun Time with Warnings; the following output occurs on building Debug builds in MSVC 2008 Team:
5>d:\scp\builds\antipodes\code\sound\acm.cpp(188) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data
5>d:\scp\builds\antipodes\code\sound\acm.cpp(512) : warning C4244: '=' : conversion from 'int' to 'ushort', possible loss of data
5>d:\scp\builds\antipodes\code\sound\dscap.cpp(222) : warning C4018: '<' : signed/unsigned mismatch
The most important one there is the signed/unsigned as that may be multiplatform (all of them that I have seen have been at least)
The following occur on Analyze (preFAST) output on Debug (also MSVC 2008 Team):
1>d:\scp\builds\antipodes\code\sound\sound.cpp(481) : warning C6011: Dereferencing NULL pointer 'gs': Lines: 469, 470, 472, 474, 477, 479, 481
1>d:\scp\builds\antipodes\code\sound\sound.cpp(556) : warning C6011: Dereferencing NULL pointer 'gs': Lines: 543, 544, 545, 546, 547, 549, 552, 554, 556
1>d:\scp\builds\antipodes\code\sound\sound.cpp(665) : warning C6011: Dereferencing NULL pointer 'gs': Lines: 653, 654, 655, 657, 658, 660, 663, 665
1>d:\scp\builds\antipodes\code\sound\sound.cpp(740) : warning C6011: Dereferencing NULL pointer 'gs': Lines: 726, 727, 728, 730, 732, 735, 737, 740
1>d:\scp\builds\antipodes\code\sound\rtvoice.cpp(578) : warning C6386: Buffer overrun: accessing 'Rtv_output_buffers', the writable size is '8' bytes, but '16' bytes might be written: Lines: 567, 568, 570, 571, 573, 578
1>d:\scp\builds\antipodes\code\sound\rtvoice.cpp(579) : warning C6385: Invalid data: accessing 'Rtv_output_buffers', the readable size is '8' bytes, but '16' bytes might be read: Lines: 567, 568, 570, 571, 573, 578, 579
1>d:\scp\builds\antipodes\code\sound\rtvoice.cpp(590) : warning C6385: Invalid data: accessing 'Rtv_output_buffers', the readable size is '8' bytes, but '-16' bytes might be read: Lines: 588, 590
1>d:\scp\builds\antipodes\code\sound\rtvoice.cpp(611) : warning C6385: Invalid data: accessing 'Rtv_output_buffers', the readable size is '8' bytes, but '-16' bytes might be read: Lines: 609, 611
1>d:\scp\builds\antipodes\code\sound\rtvoice.cpp(612) : warning C6386: Buffer overrun: accessing 'Rtv_output_buffers', the writable size is '8' bytes, but '-16' bytes might be written: Lines: 609, 611, 612
1>d:\scp\builds\antipodes\code\sound\ds.cpp(693) : warning C6011: Dereferencing NULL pointer 'si': Lines: 661, 662, 663, 667, 668, 673, 674, 676, 677, 678, 679, 680, 681, 685, 686, 687, 688, 689, 692, 693
1>d:\scp\builds\antipodes\code\sound\ds.cpp(809) : warning C6011: Dereferencing NULL pointer 'final_size': Lines: 661, 662, 663, 667, 668, 673, 674, 676, 677, 678, 679, 680, 681, 685, 686, 687, 688, 689, 692, 693, 694, 695, 696, 697, 709, 786, 788, 789, 791, 792, 808, 809
1>d:\scp\builds\antipodes\code\sound\acm.cpp(320) : warning C6011: Dereferencing NULL pointer 'pwfxSrc': Lines: 319, 320
1>d:\scp\builds\antipodes\code\sound\acm.cpp(434) : warning C6011: Dereferencing NULL pointer 'dest_len': Lines: 319, 320, 321, 322, 323, 325, 327, 328, 330, 331, 332, 334, 335, 336, 338, 339, 340, 341, 343, 352, 353, 356, 364, 365, 366, 369, 370, 371, 372, 373, 374, 375, 377, 378, 381, 382, 384, 390, 391, 394, 395, 396, 399, 403, 413, 415, 416, 420, 422, 424, 434
1>d:\scp\builds\antipodes\code\sound\acm.cpp(450) : warning C6011: Dereferencing NULL pointer 'pwfxSrc': Lines: 449, 450
1>d:\scp\builds\antipodes\code\sound\acm.cpp(514) : warning C6011: Dereferencing NULL pointer 'stream': Lines: 449, 450, 451, 453, 455, 457, 458, 459, 461, 462, 464, 470, 471, 472, 475, 476, 477, 478, 479, 480, 481, 483, 484, 487, 488, 490, 496, 497, 500, 507, 509, 510, 511, 512, 513, 514
1>d:\scp\builds\antipodes\code\sound\acm.cpp(526) : warning C6011: Dereferencing NULL pointer 'str': Lines: 524, 525, 526
1>d:\scp\builds\antipodes\code\sound\acm.cpp(540) : warning C6011: Dereferencing NULL pointer 'str': Lines: 534, 535, 540
1>d:\scp\builds\antipodes\code\sound\acm.cpp(551) : warning C6011: Dereferencing NULL pointer 'str': Lines: 545, 546, 551
1>d:\scp\builds\antipodes\code\sound\acm.cpp(574) : warning C6011: Dereferencing NULL pointer 'str': Lines: 556, 557, 558, 559, 561, 562, 563, 565, 567, 568, 569, 571, 574
1>d:\scp\builds\antipodes\code\sound\acm.cpp(582) : warning C6011: Dereferencing NULL pointer 'dest_len': Lines: 556, 557, 558, 559, 561, 562, 563, 565, 567, 568, 569, 571, 574, 575, 576, 579, 582
-
When running SSE2 INF Debug build in windowed mode, I focus out of FSO (which pauses it)
When I click back on the still paused FSO, I get a brief audio playback of the mainhall music as if it's still being tracked and looped in memory.
EDIT: Followup:
Unhandled Exception at 0x00000000 in fs2_open_ant_6d_inf_sse2.exe:
0xC00000005:
Access violation reading location: 0x00000000
(break into debugger, returns to here:)
ds.cpp
line 1765
Action performed: Calling in a support ship
Data in log:
Loaded TC_help.wav
playing head Head-CM2c for Command
ANI Head-CM2c.ani with size 160x120 (6.3% wasted)
Mission: Player Ship: Ulysses. Default Retail Loadout
Additional Ships: GTCv Deimos named 'Test", goes nowhere, does nothing, set as "Escort" to test script (which is off)
Support Ships Allowed: Yes
-
hi,
sound really nice, but i have a problem.
everytime if is there a normal radiomessage (with audio or without audio make no different) played the game immediately freeze.
i tried it medias and without medias, some mods and with both release and the debugbilds, everytime the same, as far theres a message = freeze.
it didnt freeze if there a message with the blue font, like in at the training on the start of the freespace 2 main campaine.
the 3.6.12 RC1 runs without problem.
my soundcard is a: Creative X-FI Titanium PCIe
latest openal driver and creative driver are installed.
the rest of the system: Vista 64 Bit, Geforce GTX 280, Intel Core-i7 920 and 6 GB Ram.
Mehrpack
[attachment deleted by admin]
-
(break into debugger, returns to here:)
ds.cpp
line 1765
Can you verify that line is a call to alGetBufferiv()? And can you post the OpenAL init section of your debug log too.
everytime if is there a normal radiomessage (with audio or without audio make no different) played the game immediately freeze.
I think that this is related to the crash that Zacam reported. I can't really explain why it crashes/freezes because of that function but I made a couple of changes to see if it makes a difference and I'll put out an updated build in the next 10-12 hours. Hopefully whatever the problem is will be worked out then.
-
Initializing OpenAL...
OpenAL Vendor : Creative Labs Inc.
OpenAL Renderer : SB X-Fi Audio [AC00]
OpenAL Version : OpenAL version 1.1
Available Playback Devices:
SB X-Fi Audio [AC00] *default*
Generic Software on Speakers (3- Creative SB X-Fi)
Generic Software on SPDIF Out (3- Creative SB X-Fi)
Available Capture Devices:
Microphone (3- Creative SB X-Fi *default*
"What U Hear" (3- Creative SB X
Digital-In (3- Creative SB X-Fi
Line-In (3- Creative SB X-Fi)
Auxiliary (3- Creative SB X-Fi)
Sample rate: 48000 (44100)
EFX enabled: NO
Playback device: SB X-Fi Audio [AC00]
Capture device: Microphone (3- Creative SB X-Fi
... OpenAL successfully initialized!
Failed to init speech
Initializing OpenGL graphics device at 1024x768 with 32-bit color...
This happened both on you provided build and on one I did with (so far only) sound.cpp's dereference warnings resolved.
-
[...]I think that this is related to the crash that Zacam reported. I can't really explain why it crashes/freezes because of that function but I made a couple of changes to see if it makes a difference and I'll put out an updated build in the next 10-12 hours. Hopefully whatever the problem is will be worked out then.
hi,
thx, ok.
will test it out after you release it :).
Mehrpack
-
[11:35] <chief1983> here's the highlights from the xcode build as far as I can tell
[11:35] <chief1983> http://fsscp.pastebin.com/V6APMBdX
[11:36] <chief1983> and the full log
[11:36] <chief1983> http://fsscp.pastebin.com/NASj6XSA
[11:36] <chief1983> enjoy
[11:36] <chief1983> oh one more thing
[11:37] <chief1983> http://swc.fs2downloads.com/files/XcodeAudioPatch.diff
Might as well put that here too, in case Taylor has any ideas. Not sure if the changes you've made affect this or not, this is with the latest stuff we managed to get into Antipodes, which is compiling for Windows. I believe I added the files correctly to the project.
-
Might as well put that here too, in case Taylor has any ideas. Not sure if the changes you've made affect this or not, this is with the latest stuff we managed to get into Antipodes, which is compiling for Windows. I believe I added the files correctly to the project.
code/sound/audiostr.cpp is missing from the project (or is set to not build). Adding that should fix things again.
-
That's odd. Wasn't removed by me, or listed as added/removed in the Windows one. I'll add it and update.
Odd, I noticed that dscap was inserted but not set to build for 'code' either, and sure enough, just adding audiostr.cpp still had the following:
Ld build/FS2_Open.build/Release/FS2_Open.build/Objects-normal/i386/FS2_Open normal i386
cd /Users/cliffgordon/fs2_antipodes/projects/Xcode
setenv MACOSX_DEPLOYMENT_TARGET 10.4
/Developer/usr/bin/g++-4.0 -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -L/Users/cliffgordon/fs2_antipodes/projects/Xcode/build/Release -L/Users/cliffgordon/fs2_antipodes/projects/Xcode/build/Debug -F/Users/cliffgordon/fs2_antipodes/projects/Xcode/build/Release -FFrameworks -filelist /Users/cliffgordon/fs2_antipodes/projects/Xcode/build/FS2_Open.build/Release/FS2_Open.build/Objects-normal/i386/FS2_Open.LinkFileList -mmacosx-version-min=10.4 -dead_strip -framework SDL -lSystemStubs -framework Cocoa -framework OpenGL -framework GLUT -framework OpenAL -framework SDL -ljpeg -lcode -llua -lpng -lzlib -framework Ogg -framework Vorbis -framework Theora -o /Users/cliffgordon/fs2_antipodes/projects/Xcode/build/FS2_Open.build/Release/FS2_Open.build/Objects-normal/i386/FS2_Open
Undefined symbols:
"dscap_start_record()", referenced from:
rtvoice_start_recording(void (*)(), int)in libcode.a(rtvoice.o)
"dscap_close()", referenced from:
snd_close() in libcode.a(sound.o)
"dscap_max_buffersize()", referenced from:
rtvoice_get_data(unsigned char**, int*, int*, double*, unsigned char**, int*)in libcode.a(rtvoice.o)
"dscap_get_raw_data(unsigned char*, unsigned int)", referenced from:
rtvoice_get_data(unsigned char**, int*, int*, double*, unsigned char**, int*)in libcode.a(rtvoice.o)
"dscap_stop_record()", referenced from:
rtvoice_stop_recording() in libcode.a(rtvoice.o)
rtvoice_start_recording(void (*)(), int)in libcode.a(rtvoice.o)
rtvoice_close_recording() in libcode.a(rtvoice.o)
"dscap_supported()", referenced from:
rtvoice_start_recording(void (*)(), int)in libcode.a(rtvoice.o)
"dscap_release_buffer()", referenced from:
rtvoice_close_recording() in libcode.a(rtvoice.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
Gonna see what happens when I add dscap.cpp too. How'd this work before, or what's going on here?
Yup adding dscap.cpp to the code target (was already tracked by the project like audiostr.cpp) took care of it, builds now. Xcode project in antipodes should work for anyone curious.
-
There were two audiostr's, one was Windows specific and the other was for OpenAL. I renamed the *-openal.cpp versions of everything to the normal names. I believe that previously when I was handling the Xcode project I had everything added to the project file but would just set it not build the Windows specific stuff. Same basic thing with dscap, except that stubs for all of the capture functions were in ds.cpp and dscap.cpp simply wasn't built.
-
Ah ok, so dropping audiostr-openal.cpp out of the project removed it from the code target too of course, but audiostr.cpp was tracked and just not set to be built now. Makes sense. Well, working now I think, will test the build later. Might put out a full set before I go home for testing. Course, your up to date changes would be nice for that :)
-
Here is a diff of the changes from the previous patch. Mostly just the warning fixes, but also has the possible bug fix for the crash/freeze, fixes doppler on capships, and has a slightly better rolloff.
[attachment deleted by admin]
-
Cool. Committed to Antipodes and adding links to Mac builds based on that to the first post.
-
First post updated with new Windows builds as well.
This new build will hopefully fix doppler being applied to sounds that aren't supposed to have it, guess at a proper rolloff for 3d sounds so that they will fade out properly over the specified distance, and possibly fix the crash/freeze that was reported.
Also I would be interested in knowing how many people are using EFX and how it is working. For people with X-Fi cards EFX should be hardware accelerated, so it should perform pretty well in that case. I just haven't heard any bug reports about EFX and the only logs that I've seen were from people that had EFX disabled so I'm a bit curious to know if anyone is actually testing that part of the code. :)
-
I have an X-Fi, I'm assuming just enabling it in the X-Fi's own control panel is enough for the game to pick it up and use it?
-
Release Builds (or at least SSE2 INF) reports the following:
5>..\..\code\sound\ds.cpp(2019) : warning C4101: 'err' : unreferenced local variable
-
I have an X-Fi, I'm assuming just enabling it in the X-Fi's own control panel is enough for the game to pick it up and use it?
I'm not sure if you can actually override it with the drivers, but if so it wouldn't be the same thing that the game does. For the game to use it you would have to enable it via the registry. Obviously a change to the Launcher would be good to do that with, but as I'm stuck with VC 2008 Express, I can't work on or build MFC apps. :sigh:
Release Builds (or at least SSE2 INF) reports the following:
5>..\..\code\sound\ds.cpp(2019) : warning C4101: 'err' : unreferenced local variable
Yeah I saw that one. It's error handling with a try/catch block, with "err" being a function name that couldn't be loaded which is sent to the debug log with mprintf() (so it's unused in release builds). Not really sure what to do about it though. Any ideas?
-
Well, can't just #ifdef it, since that would move the problem and you still need it to flag up something for release builds if extensions are not found I'm guessing.
I'll have a think on it while I test the builds.
Edit: On Analyze, the rtvoice warnings are still present. I'm checking to see if the warnings in the gmsnd have any bearing on any issues (supposing that I run into any)
EDIT 2: Comms menu no longer crashes. non-Beam (Laser) Turrets have a firing sound, but no impact sound (at least not when hitting the player)
Engine Wash seems to be a little tempermental as to when it will kick on or not, and while that is not related to this, quick taps of AB or jockying of thrusters will cut Engine Wash effect out even though the HUD still displays that you should be hearing it.
-
Edit: On Analyze, the rtvoice warnings are still present. I'm checking to see if the warnings in the gmsnd have any bearing on any issues (supposing that I run into any)
Yeah I didn't make any changes there. I have rtvoice disabled so I don't think those functions should ever be called now. That code is just so messed up that I am just going to rewrite it for post-3.6.12 and replace the compression codec with Speex.
-
Yay!
-
Any plans to work with the CMU Sphinx stuff? I always thought it looked promising to replace the SAPI crapola.
-
hi,
yeah the fix work, not freeze :D.
to EFX: i search a bit around in the internet and it seems that all newer driver of creative have a bug, so only after a fresh install and the first start of a program EFX work (so post it a member in the creative forum), after that he didnt work anymore.
but i dont really found much about this problem, i think the most people didnt regonice it, because theres not many games with 3D sound support around anymore (i didnt regonice it too :( ).
i will further invesgitage, maybe a found a "work" around, if you i will post it here.
Mehrpack
Edit: ok find in the moment no solution, tried to use an older ct_oal.dll verion, but thats didnt work, maybe the install of the orginal cd driver would work, but then maybe other errors and in the moment i didnt want to try it out, with deinstallation and new installation of this old driver.
-
Taylor, if a regedit is necessary, could you provide some details for the key to add/edit? Or perhaps a .reg file that does it for us? I'm comfortable with the registry, not sure about anyone else.
Edit: NM got it myself. EnableEFX looks like the key. Need to create HKEY_LOCAL_MACHINE\Software\Volition\FreeSpace2\Sound, and then create a DWORD named EnableEFX with a value of 1. Then FS will read that I believe. Also, SampleRate is now in Sound. Default is a decimal value of 44100. Might make a tweak to the launcher for this stuff later.
-
hi,
thanks for the tip and i try it out, but didnt work.
maybe some other have more success.
but if you use windows vista/ windows 7, the keys are store in the virtualstore unter hkey_users.
Mehrpack
-
64bit also has to worry about the key being somewhere else as well.
-
Well, it should go wherever your freespace keys already are. There should already be some present.
-
Any plans to work with the CMU Sphinx stuff? I always thought it looked promising to replace the SAPI crapola.
No plans for that at the moment. I might look into it at some point but I don't have much time for stuff these days so don't count on it.
Taylor, if a regedit is necessary, could you provide some details for the key to add/edit? Or perhaps a .reg file that does it for us? I'm comfortable with the registry, not sure about anyone else.
Edit: NM got it myself. EnableEFX looks like the key. Need to create HKEY_LOCAL_MACHINE\Software\Volition\FreeSpace2\Sound, and then create a DWORD named EnableEFX with a value of 1. Then FS will read that I believe. Also, SampleRate is now in Sound. Default is a decimal value of 44100. Might make a tweak to the launcher for this stuff later.
That info was in the first post actually. :p
The launcher changes would be nice though, since I can't make those myself.
-
Ugh. I guess it seemed like more of a TL;DR moment to me. That's what I get.
-
Also, changing the existing launcher would probably make it incompatible with previous builds' settings. Unless both are settable somehow.
-
Done properly would make the sound tab in the launcher a little bit messy, code wise, but it's certainly possible to get full support for all of it.
I set up something so that I could build the Launcher and try getting this code going, but apparently to Launcher code is totally screwed up and doesn't build at all. Do you know if what is there is supposed to work? Or should I just grab an earlier checkout and make my changes to that?
-
hi,
to EFX: man im really blind chicken :( work now, the next time i should read the text better, sorry for making so much hot steam :(.
Mehrpack
-
Launcher 5.5e is r5158, either without r5150, or with 5355, but nothing else between 5158 and 5355. Unfortunately there's no one revision to get 5.5e though.
-
First post updated with another new build. You can safely skip this one unless you just really want it though. The only differences are that is is compiled with newer Ogg, Vorbis and Theora static libs to get rid of a crash with some Theora movies, and a temporary -enable_efx cmdline option to more easily test out EFX with.
Launcher 5.5e is r5158, either without r5150, or with 5355, but nothing else between 5158 and 5355. Unfortunately there's no one revision to get 5.5e though.
Ok, thanks. I'll see what I can do about getting an updated Launcher ready that supports the new sound setup.
-
Ideally the exe would identify itself as using the new sound setup in the flags.lch, and the launcher would recognize this and only show one or the other. We'd also like similar behavior done to move Windows to using ini instead of registry, etc. But just setting all possible options works too.
-
Give this updated Launcher and try and see if it works:
http://icculus.org/~taylor/fso/testing/Launcher.7z
Note that the version is the same, but the exe name has the date in it so that you can easily use both the official 5.5e version and this new test version. If it all works out then we can release the new one officially as "5.5f - The Amazing Float!". :)
-
Not sure if the latest changes made it into the mac build that Chief added to the original post, but when I tested it it seemed like the Doppler effect was applied to the aspect missile tracking and lock on sounds. Also, the effect seems far too pronounced at the high speeds SWC ships cruise at--TIE fighters that used to do the proper sweeping "whoosh" effect now sound like someone changing the speed on a reel-to-reel tape system from chipmunk territory down to super-slow-mo. The issue of battle tracks not transitioning seamlessly appears to have been resolved though, and I really can't exaggerate how much that improves the experience--awesome stuff.
-
Well, after the post here:
http://www.hard-light.net/forums/index.php?topic=68146.msg1348103#msg1348103
Is where I added the patch to SVN, and then build the Mac builds based on that. There haven't been more patches in this thread since then I don't think.
-
With the latest Audio build, I almost lose the CM launch sound effect. It's just not really noticeable for me, thus losing a vital piece of audio feedback.
Here's the audio portion of my log, in case you need it:
Initializing OpenAL...
OpenAL Vendor : Creative Labs Inc.
OpenAL Renderer : Software
OpenAL Version : 1.1
Available Playback Devices:
Generic Software on Speakers (High Definition Audio Device)
Sample rate: 44100 (44100)
EFX enabled: NO
Playback device: Generic Software on Speakers (High Definition Audio Device)
Capture device: <not available>
... OpenAL successfully initialized!
-
Yeah, same here. I no longer know if I fired a cm or not because there's almost unnoticeable audio feedback.
-
Must be an issue with the rolloff changes. Basically the sound is just fading out too quickly. I'll tweak it a bit and see if I can get that worked out.
-
Let me just confirm that there should be absolutely no difference compared to RC1 with regards to how difficult missions should be (AI performance and behaviour most notably)?
-
Let me just confirm that there should be absolutely no difference compared to RC1 with regards to how difficult missions should be (AI performance and behaviour most notably)?
This is RC1 with just audio changes. Or, it might be RC1 with the 3 commits that were backported to the RC branch, but none of them should have any effect what-so-ever on the AI over RC1. (Check the Escort list if the word "Monitoring" is present, then it's RC1+Fixes)
Question on the SampleRate value: is this also supposed to work in the registry? Because I've set both String and DWORD to 44100 and it's still listing 48000.
And is the a diff for the latest changes to allow EFX via cmdline for the launcher to use? And additionally, a DIFF on the launcher code so that IssMneur and kkmic can impliment it into their Alpha launcher?
-
Let me just confirm that there should be absolutely no difference compared to RC1 with regards to how difficult missions should be (AI performance and behaviour most notably)?
As Zacam already said, this is just RC1 with the new sound code. There should be no changes to AI or anything else.
Question on the SampleRate value: is this also supposed to work in the registry? Because I've set both String and DWORD to 44100 and it's still listing 48000.
The sample rate is basically just a hint, the sound card drivers can use something different. That is why the sample rate in the log contains what the sound device is actually using as well as having what you requested in parenthesis. There really isn't a way to force it to use one sample rate over another, it's just that the requested sample rate should be the minimum that the device would use. It would have been using 48000 with the old code as well, but now you actually know.
And is the a diff for the latest changes to allow EFX via cmdline for the launcher to use? And additionally, a DIFF on the launcher code so that IssMneur and kkmic can impliment it into their Alpha launcher?
As I already put out a Launcher which can control the EFX value in the UI I'm not going to release a diff with the cmdline option. I've already removed those changes from my git tree even.
The Launcher changes will hit SVN in the next couple of days though and those guys will be able to make the necessary changes to the new Launcher from that. I'm working on a couple of Mantis bugs concerning the Launcher at the moment and when that is done I'll get everything in SVN. And I'll make a note of that in the new launcher thread so that they are aware of that. The support for the new sound stuff itself is pretty straight forward, it's having to support retail/pre-OpenAL, old-OpenAL and new-OpenAL at all once that complicates things. :)
-
Sorry taylor, the countermeasure issue The E and I mentioned was due to edited sounds.tbl. :p
-
HA! I knew was code was perfect! :D
:nervous:
-
Hmm. When changing states, or when switching from FS2 to another application and back, I notice that the game tends to replay the last few seconds of the previous track, then fading into the new BGM.
This seems to be confined to the normal menu stuff only, though.
Confirmed as well when alt-tabbing during gameplay.
-
Hmm. When changing states, or when switching from FS2 to another application and back, I notice that the game tends to replay the last few seconds of the previous track, then fading into the new BGM. This seems to be confined to the normal menu stuff only, though.
Confirmed as well when alt-tabbing during gameplay.
Thought that was fixed. I'll give it another look. It's not really something that I can test however, so I don't really know what the problem is or how/if it can be fixed. My one guess at the problem was obviously wrong since it's still happening.
-
If you're stationary, the countermeasure voice is much stronger than when you're moving; my guess is that the sound source stays at the place where the CM is released, and if you're moving at high speed it simply attenuates so fast that you don't hear it.
Also, I've noticed that pretty much all SFX that originates from your own ship is much weaker in volume than with RC1 compared to external SFX; afterburner sounds, engine sounds, energy management sounds, targetting/aspect lock sounds... and of the external SFX, especially explosions seem really really out of bounds loud almost regardless of the distance. Another thing is that communications seems very low in volume as well, but I can't tell if this is some kind of 3D effect based on the position and distance of the transmitting ship - although if it is, I really think it shouldn't exist as the speakers/helmet headset move along with the player's ship, and so the volume of messages should be constant. I earlier noticed that selecting General Hardware instead of General Software has this effect among other minor things, and you earlier said that it now automatically selects the first option that supports enough samples. And sure enough, without forcing General Software it does this:
Initializing OpenAL...
OpenAL Vendor : Creative Labs Inc.
OpenAL Renderer : Software
OpenAL Version : 1.1
Available Playback Devices:
Generic Hardware on ASUS Xonar DX Audio
Generic Software on ASUS Xonar DX Audio
Available Capture Devices:
ASUS Xonar DX Audio *default*
Microsoft LifeCam VX-1000.
Sample rate: 44100 (44100)
EFX enabled: NO
Playback device: Generic Hardware on ASUS Xonar DX Audio
Capture device: ASUS Xonar DX Audio
... OpenAL successfully initialized!
I probably should test how it sounds with registry settings prioritizing General Software, but I'd like to know why a registry setting is used to change this instead of an INI file? Or is this just an intermediate solution?
Also, should there even be any change at all between General Hardware and General Software with the new audio code? I'll get back to this when I have time to run some tests with registry changes in place.
Another thing, is there an upper limit to the sample rate? I realize that practically none of the files themselves used in FS2_Open have higher sample rate than 44.1 kHz, but setting that higher should still improve the volumetric sound calculations and other processing accuracy, and my sound card supports 192 kHz output to all 7.1 speakers... :nervous:
-
First post updated with new build. Not much specific to the new sound code in this one, just trying to avoid a separate build for a couple of bug tests.
Attached is a diff of the sound related changes to get the code in Antipodes in sync with this latest build.
Changelog:
- sort capture device list properly
- try to be sure that doppler is disabled for 2D sounds
- clean up launcher flags (Mantis #2074, partially)
- fix memory handling bugs with cmdline args
- make cmdline_fso.cfg size handling dynamic
- be sure to close out properly with end-mission sexp (Mantis #2144)
[attachment deleted by admin]
-
Also, I've noticed that pretty much all SFX that originates from your own ship is much weaker in volume than with RC1 compared to external SFX; afterburner sounds, engine sounds, energy management sounds, targetting/aspect lock sounds... and of the external SFX, especially explosions seem really really out of bounds loud almost regardless of the distance.
This has been mentioned before, but I can't reproduce it. All of those sounds are just as loud as they used to be in my tests.
Another thing is that communications seems very low in volume as well, but I can't tell if this is some kind of 3D effect based on the position and distance of the transmitting ship - although if it is, I really think it shouldn't exist as the speakers/helmet headset move along with the player's ship, and so the volume of messages should be constant.
Messages are 2D sounds, so there should be no sort of 3D effect going on there.
I probably should test how it sounds with registry settings prioritizing General Software, but I'd like to know why a registry setting is used to change this instead of an INI file? Or is this just an intermediate solution?
Registry, INI file, same thing. It's just where the game settings go. It will eventually be moved out of the registry on Windows to an ini file just like on the other platforms though.
Also, should there even be any change at all between General Hardware and General Software with the new audio code?
So long as the device can support the number of sources that the game wants then it will use it. That is the only difference between how the game deals with different sound devices. How your system handles it is a completely different thing though. It really just depends on your drivers as to how all of that works.
Another thing, is there an upper limit to the sample rate? I realize that practically none of the files themselves used in FS2_Open have higher sample rate than 44.1 kHz, but setting that higher should still improve the volumetric sound calculations and other processing accuracy, and my sound card supports 192 kHz output to all 7.1 speakers... :nervous:
The game has nothing to do with the sample rate other than to ask the sound device to initialize at a particular value. What works, or doesn't, depends entirely on what your hardware and drivers allow. However, the higher the sample rate the more CPU is required to do sound, so it is possible to overpower your system if you try and push it too much, particularly if you also enable EFX. If you raise the sample rate and then notice a huge hit to FPS, you'll know that you have to use a lower some. :)
-
Not really planning a new build right now, just wanting to post an updated diff with the fixes since the previous build...
- Add -no_3d_sound cmdline option to force use of old playback method for 3D sound.
This will only use panning and not full 3D spatialization. Basically just the way that the OpenAL code worked before.
- Fix replay bug with streaming audio that was supposed to be paused.
A screw up in the code caused the last couple of seconds of audio to replay in paused streams. This might be the cause of the ALT-TAB issues in the new code. This bug is specific to the new code however, so if the ALT-TAB problem is really fixed now then it was originally caused by a bug that I had already fixed and this new bug simply hid that fact.
- Send a warning message to the debug log when playing multi channel audio in 3D.
Only mono audio sources can be played with 3D spatialization so this will help debug problem sound encoding. In order for a sound to play in 3D the audio file will have to be converted to mono.
[attachment deleted by admin]
-
Sounds.tbl has two options for 3D audio, stereo and Aureal. With this new sound code, is there any difference between the two at all? If there is, what difference exactly as I've had multiple people test differences and they didn't notice any.
-
Sounds.tbl has two options for 3D audio, stereo and Aureal. With this new sound code, is there any difference between the two at all? If there is, what difference exactly as I've had multiple people test differences and they didn't notice any.
There is no difference. Even if A3D was still there it really wouldn't offer any benefit with the capabilities of current sound cards and drivers.
-
As soon as Icculus becomes available again, I'll put this into Antipodes.
-
Or rather, once it get's up AND I have a spare minute to breathe. :-(
Some slight whitespace (space vs tabs) changes were made by me when converting it from .diff to .patch, but it is otherwise unchanged and in Antipodes now.
-
The build crashes launcher 5.5f for me
no log written, no assertion or anything given. We checked cmdlines on IRC (I got an ARGS assertion earlier but after removing -res that disappeared) so I don't think that's causing it.
-
Rename \launcher6.ini to launcher6.ini-old and \data\cmdline_fso.cfg to cmdline_fso.cfg-old. Then check your FS2 directory if you see a small file that has no file extension, I've forgotten what name it has. Either way, if you find a file without extension, open it in notepad. The file quite likely contains command line options for the launcher, if so delete the file. Then try launcher again.
-
There was no small file without extension to be found
-
The launcher might occasionally create such a file temporarily, but if it becomes permanent, it should be deleted as it seems to override cmdline_fso.cfg or cause other weirdness. It's okay if you don't have it.
-
We haven't had any new audio builds for long time, they're lacking far behind RC2 and trunk. :(
-
Please put this into 3.6.12 Final. I beg of you. This is pure epic win, and I was truly shaken by how FS sounded when I played that. So much variation...
-
I'll be synchronizing Antipodes (hopefully) sometime before this weekend.
-
Please put this into 3.6.12 Final. I beg of you. This is pure epic win, and I was truly shaken by how FS sounded when I played that. So much variation...
Taylor's still finalizing the code. It will be done anywhere from a few days to a month from now. It depends on how long people want to wait.
-
Can we get full .patch containing the latest audio code so that those we are able to compile builds, can apply the patch to RC2 or trunk builds?
-
This is basically why I don't want to wait on it for 3.6.12. It's not done, and there's no real idea of a deadline for it. We have several patches sitting around ready to go into 3.6.12 final, if the audio code makes it in that would at least warrant an RC3. If we get 3.6.12 final out with the last few existing patches we can get the audio code in shortly, making sure it's clean and get 3.6.14 out, hopefully with some project file and libraries cleanups too. Then we can hopefully get the pilot code going. But I just want to get 3.6.12 out. I know the audio code is nice, but since it's not done I really don't want to let the 3.6.12 branch become useless.
-
Would the audio itself (along with any other patches / cleanups that make it in time for the audio completion) warrant a 3.6.14? If so, I don't see why not finalize 3.6.12 then release 3.6.14 with the audio update. If not, then I can see why holding up 3.6.12 might be desirable - you don't want to wait 6+ months for an audio update that's been done for 5 of those months. xP (Talking about people that don't use trunk / RC builds)
-
I think it would warrant another version, especially combined with libs cleanup and getting VS2010 to work.
-
Agreed.
In the end, we are supposed to get off the 3.6.xx track and move on to 3.7; Even if the new Pilot code is not ready by then, I believe we can get the new sound code tested for that one.
-
Yeah I don't care as much what we call it, I just want to get _this one_ out the door and start working on the _next one_.
-
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.
-
Could someone be as kind as to compile new audio builds based on latest trunk?
-
Might want to fix the retail breakage first :P
-
What retail breakage?
-
2185 (http://scp.indiegames.us/mantis/view.php?id=2185). Looks fixed now actually.
-
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]
-
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. :)
-
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.
-
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.
-
Here are the promised diffs...
against trunk (r6075): new-sound-trunk.diff (http://icculus.org/~taylor/fso/misc/new-sound-trunk.diff)
against 3_6_12 (r6069): new-sound-3_6_12.diff (http://icculus.org/~taylor/fso/misc/new-sound-3_6_12.diff)
from previous change patch (doubt it will apply cleanly to Antipodes, sexp code will probably conflict): changes4.diff (http://icculus.org/~taylor/fso/misc/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).
-
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
-
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.
-
Windows Sound might be DirectSound, whereas this might bypass that and call through the driver directly using OpenAL. Just a thought.
-
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. :<
-
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
-
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.
-
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.
-
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.
-
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)) f0
...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 f0 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. :p Though that would probably be a bit... complicated to implement in this sort of case.
-
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...
-
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...
Mach is a relative term and refers to speed of sound in current medium. On Earth at sea level, it's about 330 m/s.
FreeSpace is not on sea level, so the speed of sound would be selected completely arbitrarily. Basically, what sounds good. It would practically have to be a figure much larger than relative speeds encountered in the game, because that would mean less strangeness with div by zero workarounds etc.
Since the TIE fighter sound effect is a mix of elephant's trumpeting and the sound of car wheels on a wet highway. Highway velocities would be about 25-30 m/s, so that makes it about 10 % of the speed of sound (330 m/s).
Therefore I would propose a starting test value of roughly 3000 m/s as the speed of sound for this Doppler implementation. That would mean that with a relative velocity of 300 m/s, you would get much similar effect as a car on a highway would down here on Earth.
Reducing the speed of sound would increase the doppler pitch delta, while increasing it would reduce the apparent doppler effect.
-
So then I'm all for increasing the speed of sound. In fact I'm betting it currently is something close to the speed of sound at sea level and that might be why such strange effects are being noted.
-
Sound travels much faster through subspace. You can hear ship sounds because of the resonance that your subspace drive makes and receives from other ships' subspace drives as they are always in standby, staying in tune with the subspace frequency to reduce time needed to re-tune to subspace if powered down. Or somesuch trash. :lol:
-
On a different note, there seems to be an issue with too many Sources being generated on occasion.
http://blueplanet.hard-light.net/log/sound.log
This eventually kills the music, which is sort of not good.
-
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?
See here (http://connect.creativelabs.com/openal/Documentation/OpenAL%201.1%20Specification.htm#_3.5.2._Velocity_Dependent) for the OpenAL formula for the doppler effect. The doppler factor is set to 1.0 (the default, and same as retail) on the source if it has a velocity, otherwise it is set to 0 (disabled, supposedly). The speed of sound is just the default for OpenAL. I have no problems changing one or both of those values, but I need someone with the right skills to tell me what to put in as I can't properly judge what sounds/works best myself.
On a different note, there seems to be an issue with too many Sources being generated on occasion.
http://blueplanet.hard-light.net/log/sound.log
This eventually kills the music, which is sort of not good.
Link gives an internal server error.
-
It's because the server has some strange security settings that apparently include blocking of retrieving files with the .log extension. Try this (http://swc.hard-light.net/logs/sound.txt). In fact I think we've bumped to a new version of mod_security that's perhaps a bit too overzealous as it's breaking several things I've been working on.
-
See here (http://connect.creativelabs.com/openal/Documentation/OpenAL%201.1%20Specification.htm#_3.5.2._Velocity_Dependent) for the OpenAL formula for the doppler effect. The doppler factor is set to 1.0 (the default, and same as retail) on the source if it has a velocity, otherwise it is set to 0 (disabled, supposedly). The speed of sound is just the default for OpenAL. I have no problems changing one or both of those values, but I need someone with the right skills to tell me what to put in as I can't properly judge what sounds/works best myself.
Would user control be too much to ask for?
Also, any ideas on the FRAPs recording problem? :<
-
+1 for either killing the doppler shift entirely, or moving it to a commandline/launcher/sounds.tbl flag.
It just messes up perfectly good sounds for little gain.
-
Would user control be too much to ask for?
Yes. It will either be fixed to work properly (better) or be disabled entirely. Most likely it will just be disabled.
Also, any ideas on the FRAPs recording problem? :<
It's a FRAPs issue or a system issue, or a combination of the two. You can try selecting a different playback device for OpenAL and see if that helps.
-
I doubt 'properly' is possible in this context unfortunately.. most of the sound effects in FS aren't tuned for pitch shifting...
As for fraps, with some testing and some help from ChronoReverse (who has an identical setup to me bar the soundcard) it seems to be a soundcard/fraps/OAL issue.
Which is most tragic because my soundcard (Audigy 2 ZS) is part of the reason your 3d 7.1 sound is absolutely mindblowingly brilliant on my PC/speakers.
I will be trying it with my onboard sound when I get the chance (wont be now got work in a few).
Tried the two devices for feedback on the launcher before posting when I originally for the problem.
Okay, having done some testing.
Your build has absolutely no sound on my onboard soundcard, which leads me to believe that it's actually the onboard sound that windows has been recording, despite my audio being routed through the Audigy (the onboard one would be off, cept I use the mic port on it because it has very slightly less EM interference from my GPU).
-
I've tested every permutation of software and hardware configuration I can think of now.
I BELIEVE the issue IS with my onboard sound, but that's purely because while using the onboard sound your build produces none.
While using the onboard with the audigy unplugged the result is the same.
While using the audigy with the onboard disabled, the exe produces sound that I can hear but does not get recorded to fraps (the rest of windows sound still gets recorded to fraps).
While using the audigy with the onboard enabled, the result is the same.
During this testing I have noted results that lead me to presume the configuration drop down window in the launcher (5.5f) for audio, which has 3 options; generic software, SB Audigy 2 ZS Audio [CF00] and no sound - actually does nothing at all (well, no sound "works").
-
During this testing I have noted results that lead me to presume the configuration drop down window in the launcher (5.5f) for audio, which has 3 options; generic software, SB Audigy 2 ZS Audio [CF00] and no sound - actually does nothing at all (well, no sound "works").
Well, the launcher setting does "work", but it merely specifies a preference, not necessarily what the game will end up using. If the game can't properly initialize your preference then it will fall back on whatever else is available until it finds something that it likes. You have to check the debug log to figure out what it actually ends up using.
But it really doesn't sound like you are actually using the 5.5f launcher, since it won't have a "no sound" option when using one of these new sound builds. If you don't see two drop-downs, one for "Preferred Playback Device" and one for "Preferred Capture Device", then you either aren't using the 5.5f launcher or you don't have a new sound build selected.
That does actually point out a slight bug in the new sound code though. If using an old launcher or build and you set it to "no sound", then using a new launcher and build will not give you the opportunity to change it and yet still force sound off. I'll get that fixed when I commit the code to SVN later this week.
-
I believe Windows itself has a way to restrict sound to only your preferred device, and this may conflict with attempting to set a preference in OpenAL if enabled. I'm not sure where that is in Vista or 7 but in XP it was in the Audio Properties.
-
Similar screen in vista/7, but that was covered in my tests, (unless you're talking to taylor :P), I went beyond that even, by BIOS disabling the onboard sound when I disabled it, and physically removing the Augidy, when I "disabled" that.
Their default setup is however;
Onboard on, default device for Recording ((Microphone)).
Audigy on, default device for Playback ((Speakers)).
I am 100% confident that Win7 "default device for Playback" is FRAPs' Win7 record.
I'm 90%~ confident that FSO is trying to use the onboard for some reason, here's where I get wobbly;
however windows seems to be routing it back through the Audigy so that I can hear it when the Audigy is my default device, regardless of the sound configurations the only time FRAPs matches up to what *I* hear, is when I've got the onboard as default playback (in which situation both FRAPs and the build which is called; fs2_open-20100422T-INF_SSE2.exe are both silent.
Also, you're quite right! I for some reason had slipped back to 5.5e, I think I forgot to change my shortcut, oops!
Time to test it again.. well, I'll test to see if it works with my default setup real quick imma head to bed after.
Edit; Okay, I should probably be adding that it was only for the last two posts I was using 5.5e, basically in the process of rebooting I stopped purposefully using the 5.5f launcher outta my directory instead of the 5.5e shortcut I have on my Rocket Dock, lol :<
Andddddd........
It still plays silently, I will run the same set of tests tomorrow if I have time (it might have to wait 'til friday).
-
Also, I don't think you'll be surprised from what you said in an earlier post, but the troubleshoot flag to use 2d sound doesn't restore fraps functionality.
I ran the debug throwing the log up here;
http://pastebin.com/RqgcZQVn
I'm beginning to think actually the OpenAL Renderer : SB Audigy 2 ZS Audio [CF00]
SB Audigy 2 ZS Audio [CF00] *default*
Lines 87 and 91 respectively, are the hints to the problem since this 'device', isn't my default, and I'm not sure what the CF00 is actually referencing.
Edit;
CF00 is a midi-related part of the Sound card, and actually has little to do with my windows default device, I also do not believe it capable of handling the FS2 engine properly, I don't know why your build prefers it.
Gonna compare to a trunk build.
Confirmed, trunk builds use; Using 'Generic Software on Speakers (Creative SB Audigy 2 ZS (WDM))' as OpenAL sound device...
http://pastebin.com/YLzPVb0R
Line 85.
Though this leaves me even MORE puzzled as to why your build produces no sound at all on my onboard sound system, I had assumed the Audigy wasn't causing the fraps problem, but it seems the Audigy is related to the FRAPs problem and the onboard sound problem is completely different.
Freaky stuff considering onboard works perfectly with trunk too.
-
Lines 87 and 91 respectively, are the hints to the problem since this 'device', isn't my default, and I'm not sure what the CF00 is actually referencing.
It is the default *OpenAL* device. It doesn't access what your system defaults are at all, it simply uses OpenAL device enumeration to figure out both what is available to OpenAL and what OpenAL has set as the default. The "CF00" part is just what the device string is as far as OpenAL is concerned, and the device string is most likely not exactly what Windows would list for the same device. I've always thought that was a bit strange personally, but that is just how it works. :sigh:
Confirmed, trunk builds use; Using 'Generic Software on Speakers (Creative SB Audigy 2 ZS (WDM))' as OpenAL sound device...
The way old builds initialize will prefer something with "Generic Software" since the code couldn't reliably handle other devices. The new code doesn't have that problem so it will use whatever OpenAL recommends by default. In the case of the old code, using the "Generic Software *" device, means that it is running through DirectSound in software whereas in the new code it will by default use the hardware accelerated device (which is subsequently faster and uses less CPU).
-
Both the devices listed are available on the 5.5f launcher, but ignores my choice on the launcher and uses the CF00 anyway when I try to tell it to use the Generic Software(which, to be honest, isn't generic software, it's still hardware accelerated on the WDM Audigy drivers for Win7..) on Speakers.
CF00 is the very first I/O Range Setting, the entire range is CF00-CF3F.
That's the only reference I could find for CF00 on my actual system, it is only visible from device manager in the cards resources manager.
Gonna hit the sack but... I was out of my depth pages ago, simply trying to offer up as much information as I can to help really.
-
Also tested with Audigy 2 ZS, Windows 7 64-bit. Latest OpenAL API and Audigy drivers. No sound is captured whenever a build containing taylor's audio code is used.
-
After several reboots I can now also confirm that FRAPS is able to capture audio when onboard Realtek ALC889A is used.
ALC889A - 1
Audigy 2 ZS - 0
-
Fury; can you confirm what the launcher says you're using for a sound source on ALC889A please?
-
Preferred playback device: Generic software
-
Having now tested both my ALC889A, and my Audigy 2 ZS, I would suggest that the merger of this code into trunk was premature.
Despite duplicating what fury did with the ALC889A, the device failed to initialise.
Predictably thereafter I get no sound what-so-ever.
The error isn't particularly helpful but here it is;
http://pastebin.com/ykhVAsGX
The ALC889A with new drivers produces this error on my box.
Sound works fine everywhere else (games/applications/etc) (on both cards).
The Audigy gets further;
http://pastebin.com/pddU4Bhx
However produces several errors.
-
So I got beepa involved (fraps' creators) and their reply was this;
Thanks for your inquiry, and I'm sorry to hear that you are having trouble. From your description it sounds like you are using the Creative ALchemy software or CMSS3D for 3D audio in your games?
Unfortunately, there will be issues when the in-game audio is being processed via these technologies as it will bypass the new audio architecture in Windows 7 and Vista (in regards to using the "Record Win7/Vista sound" option in Fraps).
Due to this, you should be able to work around the issue by configuring Fraps to use the "Record external input" option. You will also need to open the Recording Devices settings via the Windows mixer and then set the recording device you would like to capture audio from as the default recording input. For a Soundblaster card the most suitable recording input to use is called "What U Hear".
Once you have set the default recording input/device, you will need to restart Fraps and then set the "Record external input" option under the Movies tab.
Alternatively, if you find that this does not help, I'd suggest that you try disabling or shutting down the ALchemy/CMSS3D software. Fraps should then be able to capture audio using the "Record Win7/Vista sound" setting. Hope this helps!
Having done all these suggestions still leads to nothing usable (what u hear leads to a noisey mess, and CMSS3D has no effect).
I've replied to tell them as much but I thought I'd drop this here to keep Taylor updated.
-
Actually, Taylor committed a few fixes to the sound code in the past day or two (mostly initialization / cleanup fixes). See if you can get ahold of a bleeding-edge build.
-
The_E thankfully made a build for me almost immediately after the commits were made, unfortunately, to no avail - the situation was completely un-changed :<
-
I can confirm that recent trunk builds work with Asus Xonar and Fraps can capture audio as well.
Just as a reminder, let me quote my earlier post in this topic.
Also tested with Audigy 2 ZS, Windows 7 64-bit. Latest OpenAL API and Audigy drivers. No sound is captured whenever a build containing taylor's audio code is used.
-
Addendum. Fraps cannot capture audio on Xonar if DS3D GX is enabled. When this mode is enabled, FSO launcher detecs Xonar as Generic Hardware. When disabled, launcher detects Xonar as Generic Software and Fraps can capture audio.
-
Interesting problem. . .
Prelude: I wanted to test out the 3D sound enabled by Taylor's sound test on my system. I am running an Auzentech X-Meridian 7.1 connected via Optical to a DDL 5.1 stereo, and the card is in DDL mode. Windows can ping each individual speaker correctly and this works properly with pretty much everything else. I have OpenAL 2.07 installed, Windows is Win7 x64.
I am unable to get anything other than plain jane Stereo sound out of this card with this game. The Launcher (5.5f beta) detects the card as "Generic Software" - thinking this might be a driver issue, I downloaded and installed the latest Oxygen HD driver from C-Media's website. It is a little newer than the latest on the Auzentech website (Rev .777 as opposed to rev .772). No difference.
At this point I just figured that perhaps a hardware renderer was required. It just so happens, I have a Sound Blaster Audigy sitting in a drawer. Trouble is, there is no way for me to get the 3D sound out of this card to the stereo (no optical out on the Audigy). I ran across a neat piece of software that addresses this, though. It is called Velbac.
Velbac is a spiffy bit of programming that links a Creative sound card to any other sound card via ASIO interception. Essentially, you set your default sound card in Windows to be the Creative card, set it up for 5.1, run Velbac and have it use the Creative ASIO driver to intercept the processed audio. It then sends it (via system RAM) to a sound card of your choice, such as my X-Meridian, which hardware encodes it into DDL and sends it to the stereo. Drawback is a bit of added latency to sounds (no where near as bad as you'd think, either).
First off - it actually works! I tested it with FEAR and was able to enable EAX HD (via Creative Alchemy) and get 5.1 surround in this game for the first time ever. Next up, I tried Taylor's sound test build dated 4/22/10. Well - it kinda works. You get the 3D sound, and it is nothing short of completely stunning how much more immersive the game is with it. Only problem is that foreground sounds (pre-mission speech, main lobby sound fx, pilot speech in game, gun shots, etc) come out of the right side speaker. I can hear the other pilots flying around me just fine, and explosions all appear to be placed correct other than this exception. It is just the foreground sounds that come out of the right side speaker. Odd.
Anyone else have any kind of problems like this?
-
Well, I upgraded the realtek drivers, (5.10.0.6083, ALC882 on a asus p5w dh) turned off every possible setting I could think of but no matter what, the new sound code continues to sound like a hollow cave. With sounds completely disappearing when shooting in certain directions and a lot of effects just sounding distorted.
I've never had any kind of sound issues with this rig on any kind of game. Its just with this new sound code. And I'd really like to see this fixed (or hell, for now I'd settle for being taken seriously instead of being ignored/being told 'its just you') especially considering this has been thrown into the trunk (and I take it that means there is no way to just continue using the old sound with new builds)
-
Well, I upgraded the realtek drivers, (5.10.0.6083, ALC882 on a asus p5w dh) turned off every possible setting I could think of but no matter what, the new sound code continues to sound like a hollow cave. With sounds completely disappearing when shooting in certain directions and a lot of effects just sounding distorted.
I've never had any kind of sound issues with this rig on any kind of game. Its just with this new sound code. And I'd really like to see this fixed (or hell, for now I'd settle for being taken seriously instead of being ignored/being told 'its just you') especially considering this has been thrown into the trunk (and I take it that means there is no way to just continue using the old sound with new builds)
Try running with the -no_3d_sound option. That will make it behave basically the same as the old code. Also make sure that EFX is turned off in the launcher, as that can certainly make the "hollow cave" you are describing.
-
Enabling EFX or disabling it makes no difference, adding -no_3d_sound to the flag list unfortunately does nothing either.
-
Please post your log file for me to look at.
And as far as old code vs. new code, look, the old code is still there and is almost entirely unchanged. I fixed and enabled 3D sound, I fixed and enabled the enumeration support, I fixed and enabled the EAX type of effects from retail, I fixed the Mantis bugs that people kept complaining about, and I cleaned out the old Windows-only sound code that was no longer used. That's it. The rest of the code, the majority of the code that was in-use before, is exactly the same as it was. The EAX effects are optional and disabled by default, the 3D sound stuff is default but can be disabled to make it work exactly like the "old code" with the -no_3d_sound option. There really just isn't anything to "fix" after that to make it work right for you, because at that point it is almost exactly the same code that has always been there.
-
a Debug log or?
Well even if you say that...
http://www.youtube.com/watch?v=lBCB-d-Qxyk
http://www.youtube.com/watch?v=iR4H75ODu2w
it sure doesn't sound the same on this machine. :ick:
And that's with the -no_3d_sound flag enabled (which doesn't seem to do much of anything for me)
-
Please post an fs2_open.log, Spoon.
-
http://pastebin.com/0JieyAiK
edit: derp
-
One of the main changes in the new code is the proper enumeration support. This basically ends up changing the default sound device from a best guess for OpenAL 1.0 support to allowing OpenAL 1.1 choose what works best for it. So your problem is most likely just an issue of the system having different settings and the game with the new code using a different sound device. I think that there is a control panel applet or something of that sort for configuring your Realtek HD card, so that would be the first thing you should probably look at. If it has any sort of effects enabled on it or an improper speaker configuration then it would definitely attribute to your problem. I've have dealt with some buggy Realtek HD installs before so you should also just trying to reset the driver config to defaults (should be an option in the control panel applet if I'm not mistaken) and restarting your computer to see if that makes a difference. Another thing to check is selecting different playback devices in the launcher (5.5f+) and see if there is an improvement there.
Basically the old code was just wrong and the new code is smarter about device selection. Unfortunately that means that there could be a configuration issue on your system which you didn't know about and the old code was too stupid to even trigger. It's just that you are aware of the problem now where as you weren't before. This is the same thing that happened when the shader code was introduced: some models didn't render properly due to geometry problems even though they worked perfectly in the older code; the problem was always there, it just wasn't known.
I'm not saying that the new sound code is perfect, but too many of the reported issues/problems so far are just system issues and not really something that can be addressed in the code (unless the code gets broken to make the wrong things work).
If you want something else to test then I can suggest using OpenAL-Soft and seeing if that does anything useful. I'm attaching an OpenAL32.dll that you can put in the game directory (DO NOT install it system wide) which should override your system OpenAL with the current version of OpenAL-Soft. Note that this will also disable any special OpenAL support from your sound drivers too, so you won't get hardware accelerated sound or anything with this present. But if the problem is your system-wide OpenAL install or some OpenAL specific issue with your sound drivers then this should make it work.
[attachment deleted by ninja]
-
One of the main changes in the new code is the proper enumeration support. This basically ends up changing the default sound device from a best guess for OpenAL 1.0 support to allowing OpenAL 1.1 choose what works best for it. So your problem is most likely just an issue of the system having different settings and the game with the new code using a different sound device. I think that there is a control panel applet or something of that sort for configuring your Realtek HD card, so that would be the first thing you should probably look at. If it has any sort of effects enabled on it or an improper speaker configuration then it would definitely attribute to your problem. I've have dealt with some buggy Realtek HD installs before so you should also just trying to reset the driver config to defaults (should be an option in the control panel applet if I'm not mistaken) and restarting your computer to see if that makes a difference. Another thing to check is selecting different playback devices in the launcher (5.5f+) and see if there is an improvement there.
Yeah I already tried every single thing in the drivers options, that's why I came complaining here :p
If you want something else to test then I can suggest using OpenAL-Soft and seeing if that does anything useful. I'm attaching an OpenAL32.dll that you can put in the game directory (DO NOT install it system wide) which should override your system OpenAL with the current version of OpenAL-Soft. Note that this will also disable any special OpenAL support from your sound drivers too, so you won't get hardware accelerated sound or anything with this present. But if the problem is your system-wide OpenAL install or some OpenAL specific issue with your sound drivers then this should make it work.
:yes2: :) :yes:
Throwing this file in the freespace folder seems to be the magical key I was looking for.
Now I can enjoy the new sound goodies too :D
Thanks Taylor
-
:yes2: :) :yes:
Throwing this file in the freespace folder seems to be the magical key I was looking for.
Now I can enjoy the new sound goodies too :D
Good to hear, though it does indicate a problem with the system installed OpenAL. I think it would help others out if we can debug it a little further and try to better figure out when in the system setup is causing the problem. If you are willing to try out a couple of other things let me know and I'll PM you the details.
And would you mind putting up another debug log from using the new dll for comparison?
-
I've actually been curious about moving to a OpenAL-Soft binary instead of the Creative reference build for the last several months. What kind of downsides are there to installing an OpenAL-Soft binary system wide as opposed to using the Creative-supplied one? I was under the impression the -Soft implementation was 100% backwards compatible with the reference 1.0 implementation.
-
Good to hear, though it does indicate a problem with the system installed OpenAL. I think it would help others out if we can debug it a little further and try to better figure out when in the system setup is causing the problem. If you are willing to try out a couple of other things let me know and I'll PM you the details.
And would you mind putting up another debug log from using the new dll for comparison?
http://pastebin.com/BkDV4md9
Sure thing, I'll be awaiting your pm.
Edit: Fred complains on start up that it cannot initialize audio. Silly Fred, you don't use audio.
-
I've actually been curious about moving to a OpenAL-Soft binary instead of the Creative reference build for the last several months. What kind of downsides are there to installing an OpenAL-Soft binary system wide as opposed to using the Creative-supplied one?
Here is a quote from the docs which explains all of that pretty well:
Note that it is still expected to install the OpenAL redistributable provided by Creative Labs (at http://openal.org/), as that will provide the "router" OpenAL32.dll that applications talk to, and may provide extra drivers for the user's hardware. It will also provide 64-bit DLLs. The DLL provided here will simply add additional devices for applications to select from. If you do not wish to use the redistributable, then simply rename soft_oal.dll to OpenAL32.dll.. just be aware this will prevent other system-installed OpenAL implementations from working.
So, OpenAL-Soft isn't meant to replace, or be used instead of, the Creative stuff. If you did replace it (like what I had Spoon do, although just for FSO in that case) then you wouldn't have access to hardware acceleration or any special features afforded by sound card driver OpenAL support. Whether installing it just in it's recommend form, as an addition to the router dll, would help in Spoon's case I don't really know (that is one of things I'm going to have him test).
Edit: Fred complains on start up that it cannot initialize audio. Silly Fred, you don't use audio.
Actually FRED does use audio and it will try to initialize and use EFX too. This is because some (or all at this point?) of the audio preview stuff in dialogs goes through the games sound system. And in the case of EFX, there is options now to set the sound environment for a mission in FRED and it allows you to preview what it will sound like.
I would be interested in seeing a FRED debug log to try and figure out why it's not working.
-
I have no idea why, but the fred error stopped showing up.
Maybe FRED got to his senses
-
Taylor, thanks for that. Then my other question is, what about compiling against the new OpenAL Soft libraries? It seems some Linux distros already include the -soft dev libs, and binaries compiled against one don't play nicely on other systems without the proper simlinks in place. But since linux has been moving to -soft for a dev lib, what about doing the same with Windows? Any advantage there?
-
I think it would be something of a support nightmare actually. The way OpenAL is set up under Windows just makes it rather difficult to solve the problem at hand without causing issues for many others. Have a look at this, the "Application Deployment" section:
http://connect.creativelabs.com/openal/OpenAL%20Wiki/Enumeration%20with%20OpenAL%20on%20Windows.aspx
The "problem", I guess, with OpenAL-Soft on Windows is that it really isn't provided as something that normal people should use. It would have to be installed and updated manually. It doesn't have to be installed system wide, putting soft_oal.dll in the game directory would allow it to be used and not disable anything else. It would also only be used for any extra devices that it provides, the Creative lib would still provide the "Generic" devices. So basically, installing OpenAL-Soft properly on Windows may not actually fix many of these problems by default, but could offer something of a fix if the user selects the right device in the launcher.
Having OpenAL-Soft installed should allow for most of the reported problems to be fixed though. The user would have to specify one of the OpenAL-Soft devices in the launcher (none of which actually say "OpenAL Soft" btw), but then it should work for most everyone if they can't otherwise use hardware acceleration, of if the drivers for hardware acceleration are the problem. I believe that it will provide a "DirectSound" device at least and that would be about the same as "Generic Software" except that it would go through the OpenAL-Soft lib and should always run through DirectSound. That would probably also address the FRAPS problems, since FRAPS doesn't support OpenAL and if the OpenAL playback device doesn't route through DirectSound properly like FRAPS insists on then it can't get sound.
There really is no win-win in any of it though; nothing we can do to solve all of the problems for everyone. It's work on the user any way we go. :sigh:
-
Loaded main_amb.wav
OpenAL ERROR: "Invalid enum parameter passed as an argument to an AL call." in d:\scp\builds\fs2_open\code\sound\ds.cpp, line 1640
Loaded user_o.wav
OpenAL ERROR: "Invalid enum parameter passed as an argument to an AL call." in d:\scp\builds\fs2_open\code\sound\ds.cpp, line 1640
Loaded commit.wav
OpenAL ERROR: "Invalid enum parameter passed as an argument to an AL call." in d:\scp\builds\fs2_open\code\sound\ds.cpp, line 1640
Got event GS_EVENT_MAIN_MENU (0) in state GS_STATE_INITIAL_PLAYER_SELECT (37)
AUDIOSTR => Successfully opened: Aquitaine.ogg
Loaded Camp_on.wav
OpenAL ERROR: "Invalid enum parameter passed as an argument to an AL call." in d:\scp\builds\fs2_open\code\sound\ds.cpp, line 1640
Loaded Camp_off.wav
OpenAL ERROR: "Invalid enum parameter passed as an argument to an AL call." in d:\scp\builds\fs2_open\code\sound\ds.cpp, line 1640
Loaded Exitopen.wav
OpenAL ERROR: "Invalid enum parameter passed as an argument to an AL call." in d:\scp\builds\fs2_open\code\sound\ds.cpp, line 1640
Loaded user_c.wav
OpenAL ERROR: "Invalid enum parameter passed as an argument to an AL call." in d:\scp\builds\fs2_open\code\sound\ds.cpp, line 1640
Got event GS_EVENT_QUIT_GAME (5) in state GS_STATE_MAIN_MENU (1)
Thoughts?
-
Other than Mantis 2262 (http://scp.indiegames.us/mantis/view.php?id=2262)? No.
-
It is annoying in the logs, but is due to nothing more than Creative's screwed up implementation of their own documented feature. If you use OpenAL-Soft then it works fine since they support it properly. It's pretty stupid when Creative's own feature is implemented properly by everyone except Creative. :rolleyes:
Right now I think that doppler is disabled since I didn't have time to get it working 100%, but the eventual plan is to get it back at some point and make it a value settable by the mod maker. So removing those lines really isn't an option since they will just have to be added back later anyway. Outside of just making the error message ignored, which is a crappy way to handle it, I'm not sure what else to do.
But ultimately this is just a bug on Creative's side and something that they need to fix.
-
This new sound code is pretty awesome :pimp: . I tested it using the latest nightly build (rev 6418) and I figure you could use some feedback.
My mobo is an ASUS M2NPV-VM with SoundMax integrated HD audio, using drivers 6.10.2.6585 and an earlier version which both behave similar.
The good:
- Brilliant on nebula missions (THUNDER, THUNDER, THUNDER!!! :D )
- Finally! concurrent beam sounds!
Some issues though:
- Using the oal_soft library (directsound device) results in choppy audio with certain sounds, so at the moment its unusable
- Specifying the sound device on the launcher doesn't appear to work (image attached), instead it chooses the first device on the list. I can work around this by deleting certain openal files (such as soft_oal)
- Lightning/thunder noises don't work at all when using a debug build (other sounds seem to work fine)
- Certain sounds will cancel each other out. For instance in 'A Game of Tag', when you tag a fighter and the beams start firing, sometimes either the beam firing sounds wont start, or they do start but the thunder noises stop, but then there will be times that both sounds run fine (this is a case by case basis every time a new beam starts firing)
- Not a freespace issue, but a soundmax issue: A soundmax driver which I installed created another openal device which basically lists the sound device without specifying whether it is generic software or directsound (it just directly says the device), this device appears to work in debug but the sound quality goes back to sub-retail level. If any other soundmax users get a similar a thing happening, I recommend they not use this device, or uninstall it (appears as Host OpenAL device in programs, it will have been installed by the driver not openal)
Still, brilliant work so far. There should be no going back from here ;)
EDIT: Problem solved, removed attachment
-
Using the oal_soft library (directsound device) results in choppy audio with certain sounds, so at the moment its unusable
What version of OpenAL-Soft are you using?
Specifying the sound device on the launcher doesn't appear to work (image attached), instead it chooses the first device on the list. I can work around this by deleting certain openal files (such as soft_oal)
What you specify in the launcher is just a preference, it doesn't mean that the game will actually end up using it. It will test the devices, starting with your launcher preference, then the default device, then all others, in order to find the one that meets the basic requirements that the game wants. Generally this means that it couldn't create enough sound sources on the device (it wants at least 48), although the logs don't really indicate that it skips using a device for failing a test.
Lightning/thunder noises don't work at all when using a debug build (other sounds seem to work fine)
But they work in a release build? It really shouldn't make a difference.
Certain sounds will cancel each other out. For instance in 'A Game of Tag', when you tag a fighter and the beams start firing, sometimes either the beam firing sounds wont start, or they do start but the thunder noises stop, but then there will be times that both sounds run fine (this is a case by case basis every time a new beam starts firing)
It will only play 32 sound simultaneously, so if a lot is going on then it will cut some sound out in order to play another one. That isn't new, the old code did the same thing, but the new code allows for multiple copies of the same sound to play at one time (i.e., not cutting off fly-by sounds, concurrent beam sounds, etc.). So that problem isn't new, you just notice it differently now.
-
What version of OpenAL-Soft are you using?
Latest version as downloaded here http://kcat.strangesoft.net/openal.html . EDIT: I've tried a version you uploaded earlier in the thread and it does the same thing.
What you specify in the launcher is just a preference, it doesn't mean that the game will actually end up using it. It will test the devices, starting with your launcher preference, then the default device, then all others, in order to find the one that meets the basic requirements that the game wants. Generally this means that it couldn't create enough sound sources on the device (it wants at least 48), although the logs don't really indicate that it skips using a device for failing a test.
Well I'm sure its just picking the first in the list, for instance when I had that soundmax openal device it appeared at the top and always picked that first regardless, even though it gave bad quality. And I'm able to force any device I want just by uninstalling the overriding devices.
-
Well I'm sure its just picking the first in the list, for instance when I had that soundmax openal device it appeared at the top and always picked that first regardless, even though it gave bad quality. And I'm able to force any device I want just by uninstalling the overriding devices.
Strange. If you have a debug_filter.cfg file then add +OpenAL to it, if you don't have one then grab mine (http://icculus.org/~taylor/fso/misc/debug_filter.cfg) (right-click and save as...) and put it in your data/ directory. Run a debug build and then check the debug log, it will give you the full list of devices in the order that it checks them. If it doesn't look right then let me know.
-
Edit: Found the problem! In regedit I created a new key folder called "Sound" and put the Quality, PlaybackDevice options in there.
It seems the launcher (5.5f) is creating values called "Sound/Quality", "Sound/EnableEFX" etc, while Freespace 2 is expecting the values to be in their own key directory Sound. So either the launcher or the fs code needs to be modified accordingly.
[attachment deleted by admin]
-
Hmm. So, 3.6.12.1 or 5.5g? :P
-
Wow. How in the hell did I miss that. :wtf:
Here we go with 5.5g (http://icculus.org/~taylor/fso/misc/Launcher55g.7z). Not needed for 3.6.12 builds of course (except this one), but will be needed for future builds so you may as well get it now.
@chief1983: Fixes will be in SVN shortly, if you want to do another build or whatever. If not then you can just copy the one I posted to where ever you like for official builds to be.
-
Sliding doors in the FS2 Aquitaine main menu have their sound entirely, or close to entirely, on the right sound channel for Anti6. I'm guessing that it's a result of the audio code work that is being discussed here, but I could be wrong. I didn't actually read the rest of this thread, and was told to bring it up here by The E.
-
Trying out the antipodes 6 build, I'm getting the following assertion: "snd->info.n_channels == 1" at sound.cpp:644
The code there says:
// any stereo sounds will not play in proper 3D, but they should have
// been converted to mono already!
Assert( snd->info.n_channels == 1 );
Does that mean that there's a stereo sound trying to play, that the game would prefer to be a mono sound?
If so, it would be handy to have a warning message telling you exactly which file is causing the issue.
-
Sliding doors in the FS2 Aquitaine main menu have their sound entirely, or close to entirely, on the right sound channel for Anti6. I'm guessing that it's a result of the audio code work that is being discussed here, but I could be wrong. I didn't actually read the rest of this thread, and was told to bring it up here by The E.
Unless there is a new problem that I'm not aware of, it's just the mainhall.tbl that is causing that. The retail tbl had incorrect sound positions for some of the doors so it sounds strange. That problem existed with the old code as well though.
Trying out the antipodes 6 build, I'm getting the following assertion: "snd->info.n_channels == 1" at sound.cpp:644
The code there says:
Does that mean that there's a stereo sound trying to play, that the game would prefer to be a mono sound?
If so, it would be handy to have a warning message telling you exactly which file is causing the issue.
Yeah, that's pretty much what it means, it wants a mono sound but isn't getting it. That Assert() is there out of some last ditch error checking though, I didn't think it would actually get hit unless something was done wrong in the tbls or something. And there is debug message when it converts a sound from stereo to mono, but it doesn't give the filename.
Is this a particular mod? It is most likely an incorrect entry in sounds.tbl, where it is attempting to play a sound in 3D that isn't flagged as being 3D. It will only do the mono conversion if a sound is flagged as 3D, so if that didn't happen then the file was already mono (which it obviously isn't) or the tbl entry is wrong.
Either way it points out several issues with the way the code handles things. I'll try and get that resolved later today, adding some extra handling of 3D sound playing and fix up the debug messages as well.
-
Yeah, that's pretty much what it means, it wants a mono sound but isn't getting it. That Assert() is there out of some last ditch error checking though, I didn't think it would actually get hit unless something was done wrong in the tbls or something. And there is debug message when it converts a sound from stereo to mono, but it doesn't give the filename.
Is this a particular mod? It is most likely an incorrect entry in sounds.tbl, where it is attempting to play a sound in 3D that isn't flagged as being 3D. It will only do the mono conversion if a sound is flagged as 3D, so if that didn't happen then the file was already mono (which it obviously isn't) or the tbl entry is wrong.
It seems to be caused by an engine sound in the Ancient-Shivan War. In case anyone has the ASW pack lying around, I've attached a test mission: the assert will trigger when you close in on the destroyer. The odd thing is, that I can't seem to reproduce it out of ASW. I made a test mod that made the Orion use the same engine sound, and nothing happened. It played just fine, without any warnings whatsoever. Tried it both with and without MVPs, to no avail.
The file is stereo (attached), and it's flagged as a 3D sound in sounds.tbl:
$Name: 131 engineloop001.ogg, 0, 0.80, 1, 400, 800 ; ASW cruiser engine (3d sound)
[attachment deleted by admin]
-
Try changing the 5th value from 1 to 0. I had to do that for a few sound effects in Diapora when first using the new sound code.
-
Hmm, changing that to a 0 removed the error, alright, but it also removed the sound. The ship is completely quiet with a 0 there.
-
So after playing a few missions, I do notice a increase in fps, but the sound is messed up. Sometimes when I shoot my primaries, I don't hear them or when my wing mates are talking, their voices cuts off mid sentence. It only seems to happen when I am in the thick of battle.
Quoted from Anti6 thread.
I also noticed primary sounds not playing during very, very, intense battles with several sounds all playing at once. This might be retail behavior though, since previously beam (and I think flak) turrets sometimes fired silently if too much was going on. Edit: I noticed this was addressed a page back. Now I'm wondering if there's a way to prioritize player sounds, since silent primaries are a lot more immersion breaking than not hearing all 5-6 explosion sounds playing at once.
As a side note, when lots of similar sounds are played together, such as when lots of beams are being fired, or when a ship explodes, I get the impression that there's some garbling going on. It sounds gravelly/bumpy, almost as if the sound levels got blown/maxed out or something.
-
Why did the sound code need a rewrite?
-
/me points at first post in the thread
-
Why did the sound code need a rewrite?
Because it sucked.
-
/me points at first post in the thread
I read the first post, and I see we have a few new features, but I didn't think that those features alone would justify a rewrite, so I wanted to know if there was any other reason.
*sheesh* :)
-
Why did the sound code need a rewrite?
There was no rewrite.
The old DirectSound code hadn't been used in years, so it was ripped out to make the code easier to maintain. The OpenAL implementation was never actually finished, so it got finished. New options were added for modders to have more control over sound. New options were added for users to get better sound quality, if they want and if their system can handle it. Sound bugs reported in Mantis got fixed.
About 90% of the "new" code is exactly the same as the "old" code. The other 10% is either what was missing previously, the new options mentioned earlier, or bug fixes. It just got cleaned up, bug fixed, and missing functionality finally got added. That's it.
-
So we're now back to retail FS2 sound levels, but with more moddability?
-
Why did the sound code need a rewrite?
There was no rewrite.
The old DirectSound code hadn't been used in years, so it was ripped out to make the code easier to maintain. The OpenAL implementation was never actually finished, so it got finished. New options were added for modders to have more control over sound. New options were added for users to get better sound quality, if they want and if their system can handle it. Sound bugs reported in Mantis got fixed.
About 90% of the "new" code is exactly the same as the "old" code. The other 10% is either what was missing previously, the new options mentioned earlier, or bug fixes. It just got cleaned up, bug fixed, and missing functionality finally got added. That's it.
o
-
So we're now back to retail FS2 sound levels, but with more moddability?
Basically, yeah. Modders can now use higher quality sounds (like 32-bit float) as well as control the sound environment (EAX) globally, per mission, and via sexp. Users can make use of those higher quality sounds (including full quality of OGG files which we didn't support before) if they have the hardware for it, or if every bit of memory and CPU cycles really count then they can take advantage of lower quality sound to get just a little bit of extra performance out of the game.
There are some issues with Creative's version of OpenAL which we are hitting against (missing documented features, static-y sound) and that is causing some problems. There is also some sort of issue with the prioritization changes for sounds which is causing important ones to not get played when they should be getting played in place of lower priority sounds.
The main issues that everyone is getting now can be attributed to one or both of those two problems. The first we can't really do much about, aside from telling people who have issues with sound quality to use OpenAL-Soft instead. The priority problem is a code issue on our side, it's just difficult to replicate for testing a fix. There are tweaks that can be made however and some future test builds will hopefully get at least that problem sorted out.
-
Does the new system have any kind of binaural functionality?
-
code\sound\ds.cpp(903) : warning C4701: potentially uninitialized local variable 'pcm' used
code\sound\audiostr.cpp(871) : warning C4701: potentially uninitialized local variable 'pcm' used
I forget if I had mentioned these already, this is Output for MSVC 2008 Debug Builds.
Release Builds only output the following:
code\sound\ds.cpp(2370) : warning C4101: 'err' : unreferenced local variable
-
So after playing a few missions, I do notice a increase in fps, but the sound is messed up. Sometimes when I shoot my primaries, I don't hear them or when my wing mates are talking, their voices cuts off mid sentence. It only seems to happen when I am in the thick of battle.
Quoted from Anti6 thread.
I also noticed primary sounds not playing during very, very, intense battles with several sounds all playing at once. This might be retail behavior though, since previously beam (and I think flak) turrets sometimes fired silently if too much was going on. Edit: I noticed this was addressed a page back. Now I'm wondering if there's a way to prioritize player sounds, since silent primaries are a lot more immersion breaking than not hearing all 5-6 explosion sounds playing at once.
As a side note, when lots of similar sounds are played together, such as when lots of beams are being fired, or when a ship explodes, I get the impression that there's some garbling going on. It sounds gravelly/bumpy, almost as if the sound levels got blown/maxed out or something.
I guess I should post this here instead of in the Anti6 thread. Me and Kolgena seem to have the same problems. By downloading the OpenAL Soft that is posted in the Anti6 thread, I was able to fix the missing sound effects but like Kolgena, I get the ugly gravelly maxed out sounds. As well, All pilots/command speak as if they are talking from inside a cave. It's kind of like a very short echo overlapping their voice. If I pause the game during mid-sentence, their voice returns to normal but the moment I un-pause the echo returns. The echos only occur in-game, never during briefings.
-
Update on that issue I was having: converting the sound to mono did the trick. It now plays, without asserts. File attached.
Edit for clarity: it's flagged as "stereo 3d" file in the table, meaning the fifth entry is a 1.
[attachment deleted by admin]
-
I guess I should post this here instead of in the Anti6 thread. Me and Kolgena seem to have the same problems. By downloading the OpenAL Soft that is posted in the Anti6 thread, I was able to fix the missing sound effects but like Kolgena, I get the ugly gravelly maxed out sounds. As well, All pilots/command speak as if they are talking from inside a cave. It's kind of like a very short echo overlapping their voice. If I pause the game during mid-sentence, their voice returns to normal but the moment I un-pause the echo returns. The echos only occur in-game, never during briefings.
Is "Enable EFX" checked in the launcher? That's what your description of the problem sounds like to me, like you have EAX effects enabled.
Update on that issue I was having: converting the sound to mono did the trick. It now plays, without asserts. File attached.
Edit for clarity: it's flagged as "stereo 3d" file in the table, meaning the fifth entry is a 1.
I've been trying, but I haven't been able to reproduce the problem with that sound file. It always converts properly from stereo to mono in all of my tests and plays just like it's supposed to. I'm going to dig up ASW data and try to reproduce it again. It must be data related in some way because I simply can't find any issue with the code. If there is a bug in there it's hiding pretty well.
-
I guess I should post this here instead of in the Anti6 thread. Me and Kolgena seem to have the same problems. By downloading the OpenAL Soft that is posted in the Anti6 thread, I was able to fix the missing sound effects but like Kolgena, I get the ugly gravelly maxed out sounds. As well, All pilots/command speak as if they are talking from inside a cave. It's kind of like a very short echo overlapping their voice. If I pause the game during mid-sentence, their voice returns to normal but the moment I un-pause the echo returns. The echos only occur in-game, never during briefings.
Is "Enable EFX" checked in the launcher? That's what your description of the problem sounds like to me, like you have EAX effects enabled.
I get the same clipping with or without EFX. (What does EFX do for FSO anyways? Doppler, dropoff, and reverb? It seems to eat some fps.)
I just thought of turning the effects volume way down in the options menu and seeing how that works. I can't try that out now, but it might do something useful. (It's set at max right now)
-
I get the same clipping with or without EFX. (What does EFX do for FSO anyways? Doppler, dropoff, and reverb? It seems to eat some fps.)
It's an open interface to EAX type effects, reverb in the basic sense. You reported echoing, as if in a cave, and that is the default effect when EAX/EFX is enabled.
And it will eat up a good bit of CPU time too. With a Creative card, and using the hardware accelerated device, all of the effects should be done in hardware and it should have very little impact on game performance. If not then it will be done in software and is a rather expensive thing to use. Without a pretty fast CPU it can really hurt FPS when done all in software.
-
Does it do anything else aside from reverb? I know you were working on sound dropoff and doppler, but are those reliant on enabling EFX?
-
Does it do anything else aside from reverb? I know you were working on sound dropoff and doppler, but are those reliant on enabling EFX?
The dropoff and doppler are just the 3D sound effects, not related to EFX. EFX is disabled by default, but 3D sound is enabled by default. You can use the -no_3d_sound cmdline option to go back to the way the old code worked.
-
Update on that issue I was having: converting the sound to mono did the trick. It now plays, without asserts. File attached.
Edit for clarity: it's flagged as "stereo 3d" file in the table, meaning the fifth entry is a 1.
I've been trying, but I haven't been able to reproduce the problem with that sound file. It always converts properly from stereo to mono in all of my tests and plays just like it's supposed to. I'm going to dig up ASW data and try to reproduce it again. It must be data related in some way because I simply can't find any issue with the code. If there is a bug in there it's hiding pretty well.
Found it. The problem is that engineloop001.ogg is listed twice in sounds.tbl: the first time as 2D, the second time as 3D. The code won't load the same file twice, so it just returns the entry for the 2D version of the sound when attempting to load/play the 3D one. Checking for such a case and loading a duplicate of the sound if necessary should fix it.
-
Is "Enable EFX" checked in the launcher? That's what your description of the problem sounds like to me, like you have EAX effects enabled.
Enable EFX was selected. Disabling it did remove the echo from the voices, Thank you. The only thing giving me trouble now is the super maxed out, blow your speakers, sound effects.
-
You can independently control FX vs Music vs Voice volume, is that not quite cutting it?
-
You can independently control FX vs Music vs Voice volume, is that not quite cutting it?
Effect volume becomes cripplingly loud in a way it didn't under the old sound code or retail. Multiple ships warping in nearby simultaneously sounds...bad.
-
Effect volume becomes cripplingly loud in a way it didn't under the old sound code or retail. Multiple ships warping in nearby simultaneously sounds...bad.
Yes, go play "Lion At The Door" and have a listen to what 48 hornets (6 Herc's double firing in one salvo) pounding a poor rakshasa cruiser all at once sounds like. Believe me, It's not pretty.
-
Effect volume becomes cripplingly loud in a way it didn't under the old sound code or retail. Multiple ships warping in nearby simultaneously sounds...bad.
Does it still happen if you use the -no_3d_sound cmdline option? Can you, or anyone else, make a quick test mission which demonstrates this problem so that I can easily replicate it for testing purposes?
I am assuming that this is related to the 3D sound code, where the volume is either attenuated too high for some reason or there is a positioning issue between listener and source. Attenuation should be capped, so I find it hard to believe that would actually be a problem. Still there could be something in there that is causing an issue, or there is some problem with doppler being disabled which is creating an issue. If I can easily test for and reproduce it then I should be able to come up with some sort of solution though.
-
The -no_3d_sound cmdline has no effect. Unfortunately I can't Fred a mission worth a damn.
-
Found it. The problem is that engineloop001.ogg is listed twice in sounds.tbl: the first time as 2D, the second time as 3D. The code won't load the same file twice, so it just returns the entry for the 2D version of the sound when attempting to load/play the 3D one. Checking for such a case and loading a duplicate of the sound if necessary should fix it.
Ahh, I see. Glad you found it :yes:
-
I'm using a pair of 5.1 headphones and when I maneuver around a beam the sound jumps from one side to the other ignoring the center channel. The beams windup and winddown for instance goes left, center, right, but the beam itself jumps from left to right. Beams are the only thing I've noticed this behavior with since it's such a drawn out effect.
-
i dunno if anybody else got this issue, but after a mission, the second one loses music almost completely... closing fso and starting it up again fixes it.
EDIT: Solved by downloading and installing openAL soft and selecting it in the launcher, still checking to see if anything else crops up.
Some other stuff has cropped up, sometimes, when the battle gets intense and i get a bit of a hit on the FPS, all of the sounds start stuttering and it doesn't stop for a while, sometimes alt-tabbing or doing other stuff that silences the music solves it.
-
I'm using a pair of 5.1 headphones and when I maneuver around a beam the sound jumps from one side to the other ignoring the center channel. The beams windup and winddown for instance goes left, center, right, but the beam itself jumps from left to right. Beams are the only thing I've noticed this behavior with since it's such a drawn out effect.
Yeah I get this same thing happening. Beams seem to only play on the right or left channel of my stereo sound. It snaps back and forth between them suddenly as you rotate your ship to change where the sound should come from. The other beam sounds are fine.
Definitely got OpenAL 1.1 and the log indicates it's using the 'Generic software on Realtek HD Audio Output'. (Yeah, just crappy onboard sound here :( )
-
Since we're bumping anyways...
+1 for beam sound positioning problems as of the latest Ant7. (Popping and crackling still happens, too, almost as if the engine is running a different sample rate than the sound file)
-
Using Ant7, lots of popping and crackling here too
-
If you don't have a nice sound card, try turning off 3d sound.
-
If you don't have a nice sound card, try turning off 3d sound.
EFX? Cause that isn't on for me
-
Perhaps try the OpenAL Soft DLL (http://kcat.strangesoft.net/openal.html). Instead of putting the soft_oal.dll in the System folder like the readme says, put it in your Freespace2 folder.
-
Well it all worked fine and dandy with OpenAL soft before!
But then *something* changed from nightly r6626 to r6627. r6626 works A-okay. r6627 completely borks up my sound. Once my framerate drops in the 30-40 range, the sound and music start cracking up, stuttering and popping.
ugh :sigh:
Edit: updated my Realtek drivers to 5.10.0.6257
Did nothing for me.
-
I guess I forgot you were already on OpenAL Soft from before. At least we know the exact commit that changed it. Too bad that commit is the go_faster code.
-
I've decided to post a couple of sound-related bugs here, since they are likely related to this new sound code. They may have been reported already, but I don't have the patience to read through 12 pages of posts to find it, and if there is a simple solution, then perhaps someone can bring it to my attention.
The first involves lightning. It used to be a background rumble, now it is a continuous clattering, which will even prevent some audio from playing during the "thunder" sound, such as in-game voices and sound effects. Afterward, it will also severely dampen some of the interface sounds, such as the little bleeps you get when you pass the pointer over a button, or select it. I've tried all three of the audio playback selections to me, and to my knowledge, I've already installed OAL.
The second involves the loss of mission briefing audio. This appears to occur after one or two missions worth of continuous gaming. Suddenly the audio for a mission stage and all following ones will not play. It can happen with command briefings or mission briefings. I think that the amount of missions required for this bug to manifest itself depends on the total number of stages in the missions leading to that point. I haven't done enough testing at this point to know if any of the other audio settings have any effect on it. The only way to clear it is to shut down FS2 and restart it.
As for which builds generate this problem, it's difficult to say. I've only resumed playing FS2 for a short while now, having been away from playing for about three years. I haven't played with any build less recent than the Ant6 series, but I've played with many knightly builds since and encountered the same problems with all builds. I will try to revert to the 3.6.12 release build and see if that makes any difference.
I'll keep you updated but hopefully someone will present me with the solution.
System:
AMD Athlon XP 2600+
1GB DDR SDRAM
ASUS A7V motherboard
ASUS V7100 ATI 9600XT-128MB
Creative Labs Sound Blaster Audigy 2 PCI
Windows XP SP2
Be advised, I haven't done any driver updates in some time, as I have had limited success with ATI's own video drivers and have been using the Omegas which are no longer kept up to date.
Later!
-
Double Post
I tested it out on the release INF-SSE 3.6.12, and while the thunder still sounds different than I remember, (which is probably due to an MVP improvement), it no longer clatters around and drowns out or overrides other sounds or effects.
-
Well, as you have sound issues, I'd recommend upgrading your sound card drivers. Creative has done a lot to improve OpenAL support, although it may not be as noticeable on XP. Still, if there are newer drivers, I'd try them out. There are drivers for the Audigy 2 as new as April of this year.
-
Updating of the sound drivers seems to have solved both issues... as far as I can tell. Thanks.
-
No problem!
-
Using anitpodes 8, all I get is stereo sound with tons of reverb. Is that the general consensus or am I missing some sort of setup?
-
http://www.youtube.com/watch?v=W5okZuGHIds&hd=1
And this is what my sound is like.
man, I just love the new sound code <3
Fix please?
-
Yeah, i get that too...
-
Is that mission using retail data? Or at least just FSU? If so, please upload.
-
Is that mission using retail data? Or at least just FSU? If so, please upload.
uh you are awesome Mr. Chief don't get me wrong buuuuut I don't see how you can possibly have watched the video and then needed to ask that question. :wtf:
-
I'm at work, I literally just listened to it while it was playing in a tab I wasn't watching, only took a very short glance at it. Anyway, if that's a neg, can we get a retail mission that behaves similarly?
-
If with similarly you mean, a lot of sound going on at once. Then sure, have my greatest masterpiece of fredding ever.
http://www.youtube.com/watch?v=QejYoVdyBOc
[attachment deleted by admin]
-
Thanks, I might try this on my mac to see how bad it sounds, I know it has a pretty crappy sound card.