[taylor]

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?

[Mehrpack]

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

[chief1983]

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.

[taylor]

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.

[chief1983]

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.

[taylor]

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!".

[swashmebuckle]

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.

[chief1983]

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.

[The E]

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:

Code: [Select]

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!



[Fury]

Yeah, same here. I no longer know if I fired a cm or not because there's almost unnoticeable audio feedback.

[taylor]

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.

[Herra Tohtori]

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)?

[Zacam]

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?

[taylor]

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.

[Fury]

Sorry taylor, the countermeasure issue The E and I mentioned was due to edited sounds.tbl.

[taylor]

HA!  I knew was code was perfect! 




 

[The E]

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.

[taylor]

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.

[Herra Tohtori]

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:

Code: [Select]

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...

[taylor]

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]