[Herra Tohtori]

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.

[chief1983]

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.

[jr2]

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. 

[The E]

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.

[taylor]

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

[chief1983]

It's because the server has some strange security settings that apparently include blocking of retrieving files with the .log extension.  Try this.  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.

[QuantumDelta]

See here 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? :<

[The E]

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

[taylor]

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.

[QuantumDelta]

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

[QuantumDelta]

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

[taylor]

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.

[chief1983]

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.

[QuantumDelta]

Similar screen in vista/7, but that was covered in my tests, (unless you're talking to taylor ), 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).

[QuantumDelta]

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.

[taylor]

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. 

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

[QuantumDelta]

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.

[Fury]

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.

[Fury]

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

[QuantumDelta]

Fury; can you confirm what the launcher says you're using for a sound source on ALC889A please?