[General Battuta]

And I believe that was exactly the complaint behind the decision that it sounded awful.

[sigtau]

Well, to say that "it sounded awful" would imply that the whole damn thing sounds awful, so if there's any way to fix the code so that certain sounds are not affected--that may be the golden fix for it.

Again, when you said "it sounds awful" it implied to me that you were referring to everything in-game (aside from music, since it's not affected by the new sound code) sounding awful.

[Snail]

Maybe we could have an option in the sounds.tbl or something that allows one to toggle Doppler effect on or off for certain sounds, so that Doppler effect on those that "sound awful" can be disabled.

[chief1983]

At about 1:15 in this video, this is about the effect I think of.

Yeah, that be kind of neat I think to have as an option.

[FUBAR-BDHR]

My 2 cents.  If your going to do it add an additional mission property for density so that sounds can arrive at variable speeds or not at all depending on if you are in Earth atmosphere, under water, Mars, etc. 

[swashmebuckle]

The doppler effect is actually simulated to an extent within the current sound system (pre-overhaul).  You can observe it when flying past other 3D sounds at high speed (most obviously with engine noises, where switching off flyby noises makes it seem more pronounced).  Some of the early problems with the new sound code were that it applied pitch shifting effects to non-3D sounds like certain cockpit noises, and that the effect seemed to be far more wide-ranging than it was previously (maybe it was actually more "realistic", but I didn't think it sounded particularly good), but an approximation of the doppler has been there from the beginning.  I've been crossing my fingers that the new code can get it back under control, cause it fixes a lot of other problems for me as well

[Mobius]

Thanks for your posts, people. This thread's interesting.

I'd say to find a compromise in terms of feature availability: setting speed of sound as an option in FRED would somehow force people to deal with it, even those who don't want to. That's why I suggested a script in the first place, and also proposed a way to make it work. I would have created the script myself if only I had more experience with scripting.

As for the doppler effect, that's also a nice thing to discuss. As far as I remember, I played at least one game that featured it, and I can ensure that many sounds become odd when closing. It's the price of realism.

How does the doppler effect work in FSO, by the way? Does it depend on angles?

Delay in sound arrival, I think, would actually be kind of cool.  I think anyone who enjoys watching thunderstorms might agree.

You're great.

[The E]

Thanks for your posts, people. This thread's interesting.

I'd say to find a compromise in terms of feature availability: setting speed of sound as an option in FRED would somehow force people to deal with it, even those who don't want to. That's why I suggested a script in the first place, and also proposed a way to make it work. I would have created the script myself if only I had more experience with scripting. [/lightblue]

Why do I get the impression that you didn't actually understand what Sushi or I have said?
If anything like this gets implemented, it will be in the form of any number of other additions to FSO. That is to say, unless a modder or FREDer specifically turns this on, it will not be used.

You should also maybe (and this is just a hint) try out the Audio test builds posted on the Test builds forum. Those still have the Doppler effect in them. How it works? Ask the OpenAL spec. Which I think says that OAL Doppler works just like real-life Doppler, or as close to it as it can manage.

[Herra Tohtori]

I would say most of the problems with doppler shift in the sound overhaul are related to

-some effects getting it backwards
-too low speed of sound values for what the players perceive (violates rule of perception), which results in way too much doppler shift.

To sound "good", the values need to be adjusted so that practically nothing in the game exceeds speed of sound in the fictious medium.


Also, there's a slight difference in doppler pitch in scenarios where the sound source moves and player stays still (relative to the fictious medium), or where sound source stays still in the medium and player moves through it, having relative velocity in the medium, and the most complex of all situations, where both move in the medium and have relative velocity between themselves.

The simplest way to simulate doppler pitch mathematically is to assume the player to stand still in the origo of the reference frame in which the sound moves; this essentially simulates how EM-radiation doppler shift works. It will also work with sound to certain extent, and might be sufficient to our purposes, but it IS somewhat different from reality which is a lot more complex, but I really really don't see fully realistic doppler shift system as a plausible solution. A slightly more advanced method would be to assume the game coordinates as a fixed medium for sound to propagate through and calculate all doppler effects based on that...

For example, theoretically if you have a fixed point source of sound and you fly away at Mach 2 you receive the waveform in reverse. And there are a lot of singularities to be expected if you allow even relative speeds of Mach 1+.

[Mobius]

What about a speed of sound that is equal to 500ms^-1? That should solve most, if not all of the problems caused by relative movements.

[Herra Tohtori]

What about a speed of sound that is equal to 500ms^-1? That should solve most, if not all of the problems caused by relative movements.

Only testing can possibly result in meaningful values, as this is something that has to be "played by the ear", if you wish.

Of course, doppler pitch and sound delay are two separate issues that are still to some extent interacting and complicating each other's implementation.

For example, if you utilize the sound delay and you end up with something like 1 second delay on a sound as it starts (if speed of sound is 500 m/s, distance would be 500 m) and the ships have a velocity of closure of 250 m/s (both ships afterburning at 125 m/s or so).

Fighter 1 produces a sound at t=0 s and the sound propagates towards Fighter 2's position at v = 500 m/s. At t=1s, the sound has reached the position where Fighter 2 was at t=0, but Fighter 2 has moved 125 metres on a line towards Fighter 2 and would have met the sound waves before the pre-calculated delay time has fulfilled.

And now you have a problem, computatively, that is. Do you want to make the delays acurate? Then you need to do some fairly fancy calculations with each sound produced by anything in range of the player, and in effect simulate the waveform spheres colliding with the player ship to calculate the delays accurately, and to determine the time to start the playback of the sound.

Then you would in addition to this have to calculate the velocity of objects that produced the sound and keep tracking that while the sound is produced, then apply that knowledge to how the player ship moves through the waveform...


Actually, the easiest brute force solution would be to detect the player ship's "collisions" with each sample of each waveform but you can see how that would be somewhat inappropriate and unfortunately expensive computationally. Basically you would have to do on-the-fly interpolation of each sample by changing the pitch of the sound based on how much the time between the samples differentiates from the original time between samples, and seeing how you would need to operate at around 44 kHz, that means 44100 samples per second per sound, and then you can have any number of sounds to simulate simultaneously...

 

[Mobius]

indeed.

I'd like to hear Wanderer's opinion on this, he may find a way to sort it out.

[chief1983]

It seems to me that OpenAL would already have methods for this, as they have doppler shift, I'd think they would also have sound delay implemented.  This shouldn't be something we have to calculate on our own.  If OpenAL can't do it, then we'll just have to stick with Doppler shift alone as far as I care.

[Wanderer]

Bad idea. Well nice one but bad.

Of course that depends on the level at which the thing is done. Proper version would require 'collision tests' with expanding sound spheres and player/camera pos to get the distance and position  for the sound....  Of course there are the shockwave 'collisions' already which (haven't checked that code yet) which might make the trick

Bad... As HT said.