Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Spoon on August 21, 2011, 09:12:01 am

Title: Let's talk about the sound code... again.
Post by: Spoon on August 21, 2011, 09:12:01 am
I know, I know. I've complained about the sound code so many times now. And I will probably keep doing so until something changes.

Right now the new sound code will do some absolutely horrible things with sound. If you let a wing of 6 fighters warp in close to the player, you had better cover your ears. Because it will not sound like 6 fighters warping in. It will sound like 6 banshee's wailing as they crawl their way out of the deepest pits of the abyss. Battuta actually had to move a wing of fighters away from the player's starting point in WiH R2 exactly because of that. It will absolutely demolish your ears.

Same goes for turrets on salvo mode. As clearly evident here: http://youtu.be/41l9wwBrxrs?hd=1 during the first few seconds you will hear a turret firing 4 shots at once. It's a horrible clipped bgggghhhzz kinda noise. Not pretty at all.

Now I won't claim I know anything about the code or sound terms. But I would really love to see for one of you awesome super cool coders to either make it so that once a sound plays more then once on the same frame it will only play one time. Or that it will simply not be amplified the way it gets now and causes that bad clipping.
Title: Re: Let's talk about the sound code... again.
Post by: headdie on August 21, 2011, 09:36:01 am
I know it's dated now but my SB Audigy with Creative Inspire speakers cant cope with it so please can the code be tweaked to fix this if possible.
Title: Re: Let's talk about the sound code... again.
Post by: QuantumDelta on August 21, 2011, 10:50:55 am
Same goes for basically any nebula with lightning.
It sounds ridiculous, it's almost completely unplayable, you really only have one option; turn the sound off and play without it.

http://www.youtube.com/watch?v=DG9arxDnth4&lc=x4DnxsmXjbZxiwERXp81OIObn2e9dsii7V0kie8wW38&feature=inbox

T____________T
Title: Re: Let's talk about the sound code... again.
Post by: Commander Zane on August 21, 2011, 10:53:46 am
I actually don't remember what the original lightning sounds like anymore...
Title: Re: Let's talk about the sound code... again.
Post by: The E on August 21, 2011, 10:56:15 am
We'll get back to you once we get someone who knows this stuff.
Title: Re: Let's talk about the sound code... again.
Post by: Reprobator on August 21, 2011, 11:11:30 am
Well since the new soundcode (1 year ago or more) i eared problem with beam as well.
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 21, 2011, 12:57:35 pm
We'll get back to you once we get someone who knows this stuff.
Despair  :(
Title: Re: Let's talk about the sound code... again.
Post by: MatthTheGeek on August 21, 2011, 01:22:33 pm
thats no good you most make an update
Title: Re: Let's talk about the sound code... again.
Post by: JGZinv on August 21, 2011, 03:24:09 pm
Instead of asking/demanding an update... why not request info on what skills are needed in said person for the sound code...
then start looking around the net for one.

Complaining about the problem when there's no one to fill the need won't make him poof into existence here and fix it any sooner.
Title: Re: Let's talk about the sound code... again.
Post by: ssmit132 on August 22, 2011, 02:18:10 am
I think MatthTheGeek was just joking around there.
Title: Re: Let's talk about the sound code... again.
Post by: QuantumDelta on August 22, 2011, 04:23:26 am
Indeed he was :P
Title: Re: Let's talk about the sound code... again.
Post by: Fury on August 22, 2011, 04:48:30 am
We'll get back to you once we get someone who knows this stuff.
Considering how big issues are presented by current sound code, it might be worth considering reverting taylor's soundcode back to what it used to be. You gain some, you lose some either way.
Title: Re: Let's talk about the sound code... again.
Post by: Sushi on August 22, 2011, 12:14:21 pm
We'll get back to you once we get someone who knows this stuff.
Considering how big issues are presented by current sound code, it might be worth considering reverting taylor's soundcode back to what it used to be. You gain some, you lose some either way.

I'd be on board with this. It sucks (both from a lose-features and a painful-to-do point of view) but I've had nothing but grief from the sound code ever since it got changed. I've been kicking myself ever since for not paying more attention to Antipodes and not squawking about the problem before it was too late.
Title: Re: Let's talk about the sound code... again.
Post by: QuantumDelta on August 22, 2011, 12:46:40 pm
I put up some fair resistance to it's addition to trunk before it went in... :<
Title: Re: Let's talk about the sound code... again.
Post by: Sushi on August 22, 2011, 02:48:25 pm
I put up some fair resistance to it's addition to trunk before it went in... :<

I remember that, actually.
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 22, 2011, 06:27:05 pm
I wouldn't mind reverting back to the old code.
Yes, on one hand its a shame. But considering the issues the new code has and the fact that nobody understands the code well enough to be able to support and fix these issues...

Also, I complained quite a while when it first went into the nightlies (mostly because how it utterly crapped up the sound on my old pc)
Title: Re: Let's talk about the sound code... again.
Post by: Sobbsy on August 23, 2011, 08:07:59 pm
Could anyone kindly fill me in on what changed with the sound code (and/or what the supposed benefits were to be from switching to it over the old code?). Just curious.
Title: Re: Let's talk about the sound code... again.
Post by: Goober5000 on August 23, 2011, 09:17:54 pm
People complained about the old sound code, and now they're complaining about the new one.  Seriously guys. :p  Let's see if we can do some intentional debugging instead of standing around complaining.  Can someone go through the recent builds and find out when the particular problem appeared?  Start in six month increments and narrow it down.

Also, try running with the -no_3d_sound command line and see if it fixes anything.
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on August 23, 2011, 09:38:22 pm
Could anyone kindly fill me in on what changed with the sound code (and/or what the supposed benefits were to be from switching to it over the old code?). Just curious.
Basically the internals of the sound code were rewritten to make better use of OpenALs capabilities rather than the engine having to baby feed the sound code.  The three largest things, from *my* point of view, that were changed, was how the sound code detects sound cards and microphones, the really poor management of the sounds and (this is what is relevant to this discussion) enabling full 3d, multi-source audio.

The problem with the full 3d, multi-source audio is that, there is no cutoff on the volume and the number of sources in a certain point.  The old sound code, implicitly had them because the old sound code would only attempt to play so many sounds a time (the "baby feeding") so it didn't overload the sound cards of the day (afaict, the old sound code is from retail except for being ported to openAL), whereas the new sound code sends every single sound to openAL and lets it figure out what to do. The end result is things like a wing warping in results in 4-6 warp sounds played at the same time, which being an already loud sound results in the extreme clipping everyone is complaining about.

Unfortunately, though I think I know what the problem is, I am not familiar enough with OpenAL to know how to fix it, and I haven't had time look into it.

People complained about the old sound code, and now they're complaining about the new one.  Seriously guys. :p
Isn't that how it works... :P
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 23, 2011, 10:10:15 pm
People complained about the old sound code, and now they're complaining about the new one.  Seriously guys. :p  Let's see if we can do some intentional debugging instead of standing around complaining.  Can someone go through the recent builds and find out when the particular problem appeared?  Start in six month increments and narrow it down.

Also, try running with the -no_3d_sound command line and see if it fixes anything.
Durr? When did the problems occure? In the revision in which Taylor commited the sound code of course.  :blah:

Thing is, we've got this sound code that apparantly nobody really understand due to the lack of openal knoweldge. It has these really bad issues that several people have raised complaints about. And its not being supported. This last bit should be enough indication imo to just pull it.
The new code could be great with tweaking and fixing, but since that is apparantly not going to happen anytime soon...

Edit: also no, -no_3d_sound does nothing to fix the clipping.
Title: Re: Let's talk about the sound code... again.
Post by: taylor on August 23, 2011, 10:37:36 pm
The problem with the full 3d, multi-source audio is that, there is no cutoff on the volume and the number of sources in a certain point.  The old sound code, implicitly had them because the old sound code would only attempt to play so many sounds a time (the "baby feeding") so it didn't overload the sound cards of the day (afaict, the old sound code is from retail except for being ported to openAL), whereas the new sound code sends every single sound to openAL and lets it figure out what to do. The end result is things like a wing warping in results in 4-6 warp sounds played at the same time, which being an already loud sound results in the extreme clipping everyone is complaining about.
There is a volume cutoff, it's just a question of whether it works properly or not.  [V] tried to get around some DS3D issues and I didn't take that code out since I didn't understand exactly what they were trying to do, how DS3D wasn't working the way they needed it too, or whether/how it's different for OpenAL.

There is also a cut off point for the number of sounds being played.  The old code would, unless a certain flag was set, only allow a particular sound to be playing one at the time.  The new code tries to be smarter about allowing things like that when there are plenty of sound sources free for use.  Also the total number of sounds is only marginally higher than it used to be, 48 compared to 32 in the old code.  And the difference there is because in the original DS code, effects and music used different sources of playback, whereas it all goes through the same OpenAL device and people were having voices and music not play due to sound effects taking up all of the available/allocated sound sources.

Quote
Unfortunately, though I think I know what the problem is, I am not familiar enough with OpenAL to know how to fix it, and I haven't had time look into it.
If you have an idea then spit it out and I'll help you figure out if that's the problem and how to go about fixing it.


Also it should be noted that in the test build thread for the new sound code that someone mentioned that the code broke with the go_faster commit.  And before that point, if up to date drivers were used, along with the OpenAL Soft DLL, then the new sound code worked fine.  So it's possible that there is an issue in there which isn't actually directly related to the sound code.
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 23, 2011, 10:44:28 pm
That was me.
But I've got a new pc now.
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on August 24, 2011, 12:02:30 am
The problem with the full 3d, multi-source audio is that, there is no cutoff on the volume and the number of sources in a certain point.  The old sound code, implicitly had them because the old sound code would only attempt to play so many sounds a time (the "baby feeding") so it didn't overload the sound cards of the day (afaict, the old sound code is from retail except for being ported to openAL), whereas the new sound code sends every single sound to openAL and lets it figure out what to do. The end result is things like a wing warping in results in 4-6 warp sounds played at the same time, which being an already loud sound results in the extreme clipping everyone is complaining about.
There is a volume cutoff, it's just a question of whether it works properly or not.  [V] tried to get around some DS3D issues and I didn't take that code out since I didn't understand exactly what they were trying to do, how DS3D wasn't working the way they needed it too, or whether/how it's different for OpenAL.
Okay. I will have to take a closer look to find where it is done then.

There is also a cut off point for the number of sounds being played.  The old code would, unless a certain flag was set, only allow a particular sound to be playing one at the time.  The new code tries to be smarter about allowing things like that when there are plenty of sound sources free for use.  Also the total number of sounds is only marginally higher than it used to be, 48 compared to 32 in the old code.  And the difference there is because in the original DS code, effects and music used different sources of playback, whereas it all goes through the same OpenAL device and people were having voices and music not play due to sound effects taking up all of the available/allocated sound sources.
Okay, I recall seeing what you are referring to, but the issue is still one of, a sound possibly being played as multiple sources (ie. a wing warping in) at the same spot making what is already a loud sound (the warp and the lightning) that much louder.

Indeed, sorry if I was misleading in this regard, I haven't looked at the sound code in quite a while.  Note, I am not trying to be evasive, I am trying to get some other code done up for the fiction viewer and command briefings that I promised to do long ago.

Unfortunately, though I think I know what the problem is, I am not familiar enough with OpenAL to know how to fix it, and I haven't had time look into it.
If you have an idea then spit it out and I'll help you figure out if that's the problem and how to go about fixing it.
I don't have anything that I haven't already stated with regards to what I outlined above about the multiple already loud sounds being played in close proximity, whereas, as far as I recall/could tell, the old code usually ended up only playing one of the loud sounds at a time.

Also it should be noted that in the test build thread for the new sound code that someone mentioned that the code broke with the go_faster commit.  And before that point, if up to date drivers were used, along with the OpenAL Soft DLL, then the new sound code worked fine.  So it's possible that there is an issue in there which isn't actually directly related to the sound code.
That was me.
But I've got a new pc now.
Do you still have the same problem with those builds?  If the builds have been removed, I can rebuild them for you.
Title: Re: Let's talk about the sound code... again.
Post by: Goober5000 on August 24, 2011, 12:16:50 am
I noticed when playtesting a recent mission that it sounded as if warpin sounds made by a wing very far away were being played with a volume as if they occurred next to the player.
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 24, 2011, 07:32:58 am
Do you still have the same problem with those builds?  If the builds have been removed, I can rebuild them for you.
Not with my current pc I don't. And my old one got salvaged for parts so I can't go back and test it.
What the problem boiled down to was that with the new sound code, it sounded like everything took part in a cave. Then with soft openal installed it was resolved. But then when the go_faster code was commited the sound (and framerate) would become horribly distorted when too many sounds were playing. 
Title: Re: Let's talk about the sound code... again.
Post by: taylor on August 24, 2011, 09:06:39 am
I noticed when playtesting a recent mission that it sounded as if warpin sounds made by a wing very far away were being played with a volume as if they occurred next to the player.
Depending on the sound, that may very well be what happens.  Not everything gets played in 3D, but all sounds occur in 3D space.  So 2D sounds are played relative to the listener's (you) position in space using stereo panning.  Meaning that 2D sounds are literally played right next to you.

So somebody probably needs to look and see if the warp sound is actually played in 3D or not.  Just find where the sound is played in the code and see if it used snd_play() or snd_play_3d().  I know that the nebula lightning is played in 2D, so if the warp sound is as well then that narrows down where the problem might be.
Title: Re: Let's talk about the sound code... again.
Post by: QuantumDelta on August 24, 2011, 12:30:06 pm
Although the lightning issue is partially volume it is mostly frequency.
The nebula was never designed to play the lightning sound every time the lightning showed up, or if it was, it was done with the thought in mind that it wouldn't work.
Playing them allllll is never ever going to work, volume aside.
Title: Re: Let's talk about the sound code... again.
Post by: Nuke on August 24, 2011, 05:51:02 pm
i dont know but i think i always played retail under eax because at the time i had a fairly decent sound blaster and thats what most games were using. but for the last several years ive mostly been satisfied with the onboard sound on whatever mobo i was using at the time. i also got away from the whatever.1 speakers everyone seems to like, last 5 years or so ive just been using full range stereo speaks and whatever analog stereo amp i could find at the time and i say the sound is much better.

anyway sounds like you need some real time gain correction code to level out the levels when you have a lot of sounds playing simultaneously. back in the old days it was one sound, one channel and the sound hardware would do the rest of the mixing for you. if a more modern sound setup tries to cram multiple sounds in the same channel by adding the samples (in the correct phase of course) then the result would be higher amplitude, not an actual mix. you would need to re-normalize the sample so that the amplitude remains constant. of course im not sure if the api works at that low of a level. id hate to roll back to direct sound over openal when the openal implementation can be fixed, given the right skill set.
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on August 25, 2011, 01:22:00 am
anyway sounds like you need some real time gain correction code to level out the levels when you have a lot of sounds playing simultaneously. back in the old days it was one sound, one channel and the sound hardware would do the rest of the mixing for you. if a more modern sound setup tries to cram multiple sounds in the same channel by adding the samples (in the correct phase of course) then the result would be higher amplitude, not an actual mix. you would need to re-normalize the sample so that the amplitude remains constant. of course im not sure if the api works at that low of a level. id hate to roll back to direct sound over openal when the openal implementation can be fixed, given the right skill set.
Well that may be, though I think that OpenAL would already do something like that to help manage sounds.

Although the lightning issue is partially volume it is mostly frequency.
The nebula was never designed to play the lightning sound every time the lightning showed up, or if it was, it was done with the thought in mind that it wouldn't work.
Playing them allllll is never ever going to work, volume aside.
Yes.  It seems this was/is an issue.  The code that is in trunk does not enforce the built in concurrent playcount limits for any sound unless there is pressure on available playback channels.  For example fighter sized ships are only supposed to play two warp-in sounds at a time.  The nebula lightning there should only be two of both lightning variation.

So somebody probably needs to look and see if the warp sound is actually played in 3D or not.  Just find where the sound is played in the code and see if it used snd_play() or snd_play_3d().  I know that the nebula lightning is played in 2D, so if the warp sound is as well then that narrows down where the problem might be.
I can confirm that nebula lightning is played in 2D, but the warpin sounds are defiantly played in 3d unless the 3d sound playback is disabled.



As I mentioned in my reply to QuantumDelta, I think I may have found the problem.  It seems that the concurrent play count limits that are in place on a lot of the sounds (in particular the really loud sounds, aka warpin and lightning) were only being enforced once there was pressure on the available playback channels, which means that as I hypothesized previously about the limit on number of sounds at one time was actually true and in my limited testing (warp sounds in one mission) seems to help with the clipping and/or excessive volume.

So, here is a patch (below) and a release and a debug trunk based build below (remember that debug builds do not have lightning enabled) with the patch applied for everyones testing pleasure :P.

Code: (always enforce the concurrent sound playcount.patch) [Select]
Index: code/sound/ds.cpp
===================================================================
--- code/sound/ds.cpp (revision 7535)
+++ code/sound/ds.cpp (working copy)
@@ -1407,25 +1407,26 @@
  }
  }
 
+ // Make sure that we are not going to play more copies of this sound than we should be
+ if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
+ // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
+ if (lowest_instance_vol <= new_volume) {
+ ds_close_channel_fast(lowest_instance_vol_index);
+ first_free_channel = lowest_instance_vol_index;
+ }
+ }
+
  if (first_free_channel < 0) {
- // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
- if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
- // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
- if (lowest_instance_vol <= new_volume) {
- ds_close_channel_fast(lowest_instance_vol_index);
- first_free_channel = lowest_instance_vol_index;
+ // still don't have a channel and
+ // there is no limit barrier to play the sound, so see if we've ran out of channels
+ // stop the lowest volume instance to play our sound if priority demands it
+ if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
+ // Check if the lowest volume playing is less than the volume of the requested sound.
+ // If so, then we are going to trash the lowest volume sound.
+ if ( Channels[lowest_vol_index].vol <= new_volume ) {
+ ds_close_channel_fast(lowest_vol_index);
+ first_free_channel = lowest_vol_index;
  }
- } else {
- // there is no limit barrier to play the sound, so see if we've ran out of channels
- // stop the lowest volume instance to play our sound if priority demands it
- if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
- // Check if the lowest volume playing is less than the volume of the requested sound.
- // If so, then we are going to trash the lowest volume sound.
- if ( Channels[lowest_vol_index].vol <= new_volume ) {
- ds_close_channel_fast(lowest_vol_index);
- first_free_channel = lowest_vol_index;
- }
- }
  }
  }
 
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 25, 2011, 07:00:03 am
Iss Mneur, you are a king! A King I say!

Using the build you provided, a warp in of 6 fighters no longer makes my ears start bleeding and a turret firing 4 shots at once now sound properly!
Get this **** into the trunk pronto!
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on August 25, 2011, 08:21:04 am
How does this change affect nebula lightning?
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 25, 2011, 08:49:06 am
Nebula lighting doesn't seem to have changed much in frequency, doesn't seem to clip or anything though.
I'm personally content with the current fixes to the warpin and turret sounds. I hardly even recall what the nebula lighting originally sounded like tbh. So I'm going to hand that issue over to QD cause he has a better clue on it.
Title: Re: Let's talk about the sound code... again.
Post by: QuantumDelta on August 25, 2011, 08:03:11 pm
This will, I hope, illustrate the differences;

http://www.youtube.com/watch?v=0yIz0O6jQp0

Sorry about the MVP use.

It is clear though that despite the slightly softer MVP effect, the game produced volume is much louder and much more frequent than with the retail sound code, pre-the new mvp (BP) lightning it could be really rather deafening.
Now it's not quite as bad but still something that could really do with proper re-tweaking.

As you can see however, the go_faster and Iss' re-tweak didn't effect the sound codes issues at all on this matter (warp ins seem fixed? you will probably notice however that one of the clips is completely devoid of warpin sound?).


Edit; for anyone really quick back to this reply, the video is about 10 minutes from finish of upload as of this post and will probably be another 5-10 minutes to fully encode. :P
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 25, 2011, 08:05:49 pm
Okay noticed just now that it's not working 100% perfectly. If you are at a certain range, the turret sounds will still clip like they used to. Its okay if you are close to the turret firing but after you put a certain amount of distance inbetween you and the turret it reverts to its old heathen ways.
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on August 26, 2011, 12:38:38 am
That was very helpful QuantumDelta, it illustrates the issue quite clearly. I was able to replicate the issue.  I don't know how you guys could stand the lightning (I never noticed because I normally end up playing with a debug build).

I think I may have been able to figure out what the problem is, I just don't know how to fix if it is actually the problem and/or how to fix it.  What appears to be the problem with the lightning is that we are not allowing the sounds to play through, so we are always hearing the beginning of the rumble now, rather than having 40 playing at a time.

@Spoon, I have noticed that as well, but I am not really sure what the cause is, I need to look into it more. Do you have an example (with retail assets) that will do it?
Title: Re: Let's talk about the sound code... again.
Post by: Kolgena on August 26, 2011, 12:53:30 am
We can't stand the lightning :P It was just brought up a bunch of times, and those threads all died from inactivity.

I'm very glad that a fix is being looked into.
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 26, 2011, 08:33:02 am
With retail assets? No, as far as I know there is no ship with a 3 or 4 firing point turret in salvo mode.
I could record you a video of the issue though.
Title: Re: Let's talk about the sound code... again.
Post by: chief1983 on August 26, 2011, 09:35:10 am
Wait, so it starts playing a bunch of lightning sounds, but instead of waiting to add another one until the earlier ones are done, it just starts shifting them off starting at the first one played?
Title: Re: Let's talk about the sound code... again.
Post by: Herra Tohtori on August 26, 2011, 09:48:42 am
Okay, this might be a silly question but... it'd be sillier not to ask it.


On GIMP, there are two different layer modes for doing almost the same thing: Addition and Screen.

They have a big practical difference, though - Addition simply adds the pixel values of the layer on top to the pixel values of the layer below, which can result to clipping if the values go over 255 for each channel.

Screen mode is more sophisticated, however. It never causes clipping, because it checks how much room there is available to the clipping point, then scales the top layer's pixel values to fill the available scale proportionally to the top layer's pixel values.


Example: I have two layers; bottom layer is a 75% grey (192,192,192 or #c0c0c0) and top layer is 50% grey (128,128,128 or #808080).

Additive blending mode would count the pixel values directly together and end up with clipped white at 192+128=320>255.

Screen mode first determines how much available values there are before clipping occurs:

255-192 = 63



Then it determines how much it wants to increase the value perceptually. The 50% grey would mean a 50% increase of available values. In this case,

63 * 128/255 = 31.6235294 = ~32



...so the final pixel value is

192 + 32 = 224

and the colour ends up as (224,224,224 or #e0e0e0).

Mathematically, it goes as follows:



RGB(out) = RGB(bottom) + ( [ RGB(white) - RGB(bottom) ] * [ RGB(top) / RGB(white) ] )


Now, for image editing, every RGB variable consists of three numerals for RGB, four with RGBA (but that works a bit differently as the alpha channel of top layer is a multiplier for the RGB values in 0,1 range...) and the range for each channel is 0,255.

For audio, we have only one value (sample) but lots of them coming in at high rate of speed (typically 44100 in one second minimum) and the size of individual sample is usually 16bit, 24bit or 32bit integer. Most commonly the sound data is in 44k16bit format; however while processing the sound, they can either be converted to higher sample size or kept at the same 16 bit (at slight sacrifice of rounding errors).


Regardless, with additive mixing of two samples, the sample values are just added together and if they go over the clipping threshold you end up with clipping sound.


With a "screen" type mixing of samples, you will never get clipping; the volume will just asymptotically approach 0 dB. Of course sound is a bit different as waveform contains both positive and negative values, while image data is limited to positive values; however the equation can probably be adjusted to take negative values into account and prevent clipping for negative values as well.


Now, the questions:

Is there some flaw in my thinking as to why this wouldn't work? If yes, what is it?


If this should theoretically work, then:


Does OpenAL support this type of mixing that never clips? If it is, how to use it?

If this is not possible, then I have to ask... why not? Is it too resource-intensive? It wouldn't seem so, as it's all rather simple maths - you just need to do it pretty fast (at least 44100 times per second multiplied by the amount of sounds used).
Title: Re: Let's talk about the sound code... again.
Post by: Nuke on August 26, 2011, 03:38:39 pm
i think the problem with this is the sound api, which should in theory handle all this low level stuff for you and only gives you control of higher level structures, sounds, channels, etc. of course i never used openal before for anything i ever wrote, nor would i. i would probably just use the sound features of sdl, since im somewhat familiar with it.
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on August 27, 2011, 12:03:05 am
So I have had a chance to think about it.

As I see it, we have three options that may or may not work:

TBH, I will probably try all three variations and see what is liked better.

Wait, so it starts playing a bunch of lightning sounds, but instead of waiting to add another one until the earlier ones are done, it just starts shifting them off starting at the first one played?
Yep.

@Herra Tohtori: I can't see why that wouldn't work, but I have to show my inexperience with OpenAL in this, I don't know if it is able to (though I can't see why not, you can't be the first person to have thought of this).  However, with in the nebula lighting in particular, being able to play 20 lighting sounds (of 48 available) channels seems like a waste to me, I can think of better sounds to be playing in those channels.
Title: Re: Let's talk about the sound code... again.
Post by: Cyborg17 on August 27, 2011, 01:23:15 am
Can you change the code to only play lightning that is within about 250m-500m of the player?  That way the frequency of noise is down, but the closest, (most intense) lightning will always be played.

An added slight glare affect for lightning within that same range might help keep lightning interesting. <-- It's ok if that's too complicated, just adding ideas.
Title: Re: Let's talk about the sound code... again.
Post by: Zacam on August 27, 2011, 09:06:05 am

I do know that the Nebula Lightning is not currently tabled (in retail) as being a 3D sound, so we'd have to force that if we expect it to work on Retail data.

Course, we'll probably also have to check if a mod makes it a 3D sound and use that setting vs forcing it even if set. (This probably doesn't make much sense, I'll see if I can explain it after coffee)
Title: Re: Let's talk about the sound code... again.
Post by: jr2 on August 27, 2011, 02:35:08 pm
How hard would it be to make it a 3D sound and write a table?  Or am I completely missing the point?
Title: Re: Let's talk about the sound code... again.
Post by: Nuke on August 27, 2011, 05:00:38 pm
@Herra Tohtori: I can't see why that wouldn't work, but I have to show my inexperience with OpenAL in this, I don't know if it is able to (though I can't see why not, you can't be the first person to have thought of this).  However, with in the nebula lighting in particular, being able to play 20 lighting sounds (of 48 available) channels seems like a waste to me, I can think of better sounds to be playing in those channels.

you should always try to make use of every sound channel there is. if sounds have a priority you could use up more sound channels for environmental effects when theres not much action going on, then have them use up fewer channels when there is combat. if priority worked like this:

1 self sounds (ship, hud, firing of player weapons etc)
2 combat sounds (beams, guns, missiles, other ships, explosions, etc)
3 environmental sounds (lightning)

priority 1 sounds always play and get first dibs on available sound channels
priority 2 and 3 sounds get 2nd and 3rd dibs on remaining sound channels.

sounds should also be further prioritized by distance from the player, play volume, and age in queue. drop distant and/or quiet sounds of priority 2 or greater. some sounds also need not be played on time, such as low priority sounds or sounds behind you that have no real effect on what your doing (things like shockwave explosions that hit you or that bogey on your six and its weapons would probably be excluded). so sounds are queued up as they are requested, and when this happens sounds are assigned a timestamp for its creation and also when it expires. expired sounds are removed from the queue. but an old sound that hasnt expired yet is a good candidate for de-prioritization.

of course before that happens you cull out a bunch of sounds if you have multiple instances of a single sound playing in close proximity to each other at close to the same time (probably determined using some 4d vector math), then the time and position should be averaged and a single sound played from that location and time (this would require some foreknowledge of what was gonna happen, as if the sounds were sitting in the queue for a couple of frames). this would improve the sounds of simultaneous lightning strikes and ship warpins, and assuming there wont be any clipping the sound could be played at a slightly higher volume (if your typical sound plays at 75% then you could amp the loud sound an additional 25% before clipping occurs). predictable events can even do this before hand making the sound queue smaller.

Title: Re: Let's talk about the sound code... again.
Post by: Dragon on August 27, 2011, 05:10:26 pm
That's a great idea. This should get rid of problems with rapid-fire weapons causing sound problems, as well as improve overall immersion in a sound-rich environment (think a battle with a lot of rapid-fire guns).
Title: Re: Let's talk about the sound code... again.
Post by: Nuke on August 27, 2011, 05:44:42 pm
rapid fire weapons should just run a sound loop that lasts for several shots. youd have to have a real ocd to figure out that you fired fewer shots than shot sounds you heard. if the cables are still too thick you could probibly play part of a loop to represent the loose shots so it doesnt make you pluck your eyes out and eat them. if a loop represents 5 shots and only 3 shots are fired, play 60% of the sound. i think this is what stream was meant to do but either wasnt implemented or didnt work and was made to do nothing so that it didnt break a bunch of tables before the game was released. the fact that the flag mostly appears on rapid fire weapons really makes me think thats what happened.
Title: Re: Let's talk about the sound code... again.
Post by: Zacam on August 27, 2011, 07:28:44 pm
How hard would it be to make it a 3D sound and write a table?  Or am I completely missing the point?

how does that help anybody running in "Retail" mode?
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 27, 2011, 08:36:17 pm
How hard would it be to make it a 3D sound and write a table?  Or am I completely missing the point?

how does that help anybody running in "Retail" mode?

If you are running retail, you don't need a build with the sound code. If you are playing with mediavp's this is a none issue.
Or am I missing something about this "Retail mode" ?
Title: Re: Let's talk about the sound code... again.
Post by: Zacam on August 27, 2011, 08:56:36 pm

"Retail" mode means: FSO exec, sans MediaVPs. Note the quotes around Retail indicating that I don't mean Retail.
Title: Re: Let's talk about the sound code... again.
Post by: MentalPower on August 27, 2011, 11:20:59 pm
Pardon my ignorance, but are the nebula lightning sounds internally (from the engine's PoV) considered objects (models) generating sound or just an environmental thing that has X% of playing every Y seconds? I'm guessing the former based on Zacam's comments, but I just want to know for sure.
Title: Re: Let's talk about the sound code... again.
Post by: jr2 on August 28, 2011, 01:26:32 pm
How hard would it be to make it a 3D sound and write a table?  Or am I completely missing the point?

how does that help anybody running in "Retail" mode?

Put the table as a vp in FS2 Root\tables or wherever they go.
Title: Re: Let's talk about the sound code... again.
Post by: MentalPower on August 28, 2011, 01:31:03 pm
How hard would it be to make it a 3D sound and write a table?  Or am I completely missing the point?

how does that help anybody running in "Retail" mode?

Put the table as a vp in FS2 Root\tables or wherever they go.
That would not work since the SCP doesn't do VPs, only the FSU does VPs. In short, it would go against what the SCP is supposed to do.
Title: Re: Let's talk about the sound code... again.
Post by: jr2 on August 28, 2011, 01:36:20 pm
Not if the table had a conditional to make it only be read by 3.6.xx like the music table for FSPort does.  Then it wouldn't be read unless you were using FSO exes.
Title: Re: Let's talk about the sound code... again.
Post by: MentalPower on August 28, 2011, 02:13:13 pm
Not if the table had a conditional to make it only be read by 3.6.xx like the music table for FSPort does.  Then it wouldn't be read unless you were using FSO exes.
That's not the point. Both FSPort and FSU are content projects, VPs are their purpose. The SCP does code only, so if anyone were to do VPs it would have to be the FSU. However it would then be a moot point since Zacam's entire argument was what to do about people that don't use the MediaVPs that the FSU provides.
Title: Re: Let's talk about the sound code... again.
Post by: jr2 on August 28, 2011, 02:30:18 pm
I thought that at this point, FSO required at minimum MV_Root.vp to operate?  And besides, .vps are just containers for the files.  If you wanted, you could make the table hard-coded into the FSO .exes and just have it able to be overridden by an actual .vp or .tbl in the FS2 file structure.  Right?
Title: Re: Let's talk about the sound code... again.
Post by: The E on August 28, 2011, 02:38:35 pm
What? No. I am quite sure that the exe still runs the retail data just fine. If it doesn't, that would be a serious regression.
Title: Re: Let's talk about the sound code... again.
Post by: Herra Tohtori on August 28, 2011, 03:30:37 pm
Several mods require a bare minimum of FSU compatibility provided by MV_Root.vp; many more mods require full MediaVP's. At least, as far as I know. I typically use mediavps anyway so I wouldn't know what mods can be run without...

The retail data still should work quite fine with FS2_Open engine.
Title: Re: Let's talk about the sound code... again.
Post by: taylor on August 28, 2011, 06:48:19 pm
Someone please give this patch a try and see if it does anything for the volume problems.

It seems quite apparent that the volume for all sound has increased at some point.  The actual volume for individual sounds appears to be the same, so I don't really have an explanation for the difference.  This patch just drops the gain for the master volume in OpenAL to more approximately match what the pre-new-sound code had (according to my ears in a quick test).

This does nothing for nebula lightning frequency though.  A better fix for that is simply editing the neblightning code to avoid playing sound too frequently, as opposed to re-imposing the hard playback count limits in the sound code directly (which was necessary at the time, but is a bug at this point).  There is really no reason to make nebula lightning 3D, as that isn't going to fix anything.  And it already avoids sound playback for any bolt over 400m away.  The code just needs to be modified to be smart about not playing too much sound in busy storms, which is something that it used to rely on the hardware limitations of the sound code to sort out.

[attachment deleted by ninja]
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 28, 2011, 09:40:50 pm
I'd test but I'd like a file I can actually do anything with.
Title: Re: Let's talk about the sound code... again.
Post by: The E on August 29, 2011, 05:43:25 pm
Here are builds with the change mentioned above: http://blueplanet.fsmods.net/E/stuff/soundtest.7z
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 29, 2011, 06:26:17 pm
That seems to be a step backwards. There's more noticable clipping on that latest build compared to the one Iss Mneur's posted (though the clipping itself is less ear shredding) and at times its not playing sounds from turrets close (and in the viewing cone) to you at all.
Title: Re: Let's talk about the sound code... again.
Post by: QuantumDelta on August 29, 2011, 06:35:26 pm
http://www.youtube.com/watch?v=zqtOhEgE2oA

.....Hopefully, if not I'll encode the two together tomorrow anyway
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on August 30, 2011, 12:23:14 am
Okay, another build to try.

This is a rollup of a few different changes so that that we can come up with some appropriate values and/or defaults.  The changes included are:

Thoughts?  Please post the settings of the above three flags and whether you are using the OpenALSoft.dll so that we can use the numbers to come up with good defaults for retail to use.


Code: (More sound code fun.patch) [Select]
Index: code/cmdline/cmdline.cpp
===================================================================
--- code/cmdline/cmdline.cpp (revision 7567)
+++ code/cmdline/cmdline.cpp (working copy)
@@ -437,8 +437,16 @@
 cmdline_parm output_sexp_arg("-output_sexps", NULL); //WMC - outputs all SEXPs to sexps.html
 cmdline_parm output_scripting_arg("-output_scripting", NULL); //WMC
 
+float Cmdline_percentflashtobang = 100.0f;
+float Cmdline_listenergain = -1;
+int Cmdline_enforce_concurrent_sound_count = 0;
 
+cmdline_parm percent_flashtobang_arg("-percent_flashtobang", NULL);
+cmdline_parm listenergain_arg("-listenergain", NULL);
+cmdline_parm always_enforce_concurrent_sound("-alwaysenforce", NULL);
 
+
+
 #ifndef NDEBUG
 // NOTE: this assumes that os_init() has already been called but isn't a fatal error if it hasn't
 void cmdline_debug_print_cmdline()
@@ -1450,6 +1458,21 @@
  Cmdline_bloom_intensity = bloom_intensity_arg.get_int();
  }
 
+ if ( listenergain_arg.found() )
+ {
+ Cmdline_listenergain = listenergain_arg.get_float();
+ }
+
+ if ( percent_flashtobang_arg.found() )
+ {
+ Cmdline_percentflashtobang = percent_flashtobang_arg.get_float();
+ }
+
+ if ( always_enforce_concurrent_sound.found() )
+ {
+ Cmdline_enforce_concurrent_sound_count = 1;
+ }
+
  return true;
 }
 
Index: code/cmdline/cmdline.h
===================================================================
--- code/cmdline/cmdline.h (revision 7567)
+++ code/cmdline/cmdline.h (working copy)
@@ -145,7 +145,10 @@
 extern int Cmdline_no_grab;
 #endif
 
+// Temp, only for evaluating new defaults
+extern float Cmdline_listenergain;
+extern float Cmdline_percentflashtobang;
+extern int Cmdline_enforce_concurrent_sound_count;
 
-
 //extern char FreeSpace_Directory[]; // allievating a cfilesystem problem caused by fred -- Kazan
 #endif
Index: code/nebula/neblightning.cpp
===================================================================
--- code/nebula/neblightning.cpp (revision 7567)
+++ code/nebula/neblightning.cpp (working copy)
@@ -21,10 +21,8 @@
 #include "weapon/emp.h"
 #include "network/multi.h"
 #include "network/multimsgs.h"
+#include "cmdline/cmdline.h"
 
-
-extern int Cmdline_nohtl;
-
 // ------------------------------------------------------------------------------------------------------
 // NEBULA LIGHTNING DEFINES/VARS
 //
@@ -439,24 +437,27 @@
 
  // do some special stuff on the very first strike of the bolt
  if(b->strikes_left == bi->num_strikes){
- // play a sound
- float bang;
- if(Nebl_bang < 40.0f){
- bang = 1.0f;
- } else if(Nebl_bang > 400.0f){
- bang = 0.0f;
- } else {
- bang = 1.0f - (Nebl_bang / 400.0f);
- }
- if(frand_range(0.0f, 1.0f) < 0.5f){
- snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- } else {
- snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- }
+ // play a sound
+ if (frand_range(0.0f, 100.0f) < Cmdline_percentflashtobang)
+ {
+ float bang;
+ if(Nebl_bang < 40.0f){
+ bang = 1.0f;
+ } else if(Nebl_bang > 400.0f){
+ bang = 0.0f;
+ } else {
+ bang = 1.0f - (Nebl_bang / 400.0f);
+ }
+ if(frand_range(0.0f, 1.0f) < 0.5f){
+ snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ } else {
+ snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ }
 
- // apply em pulse
- if(bi->emp_intensity > 0.0f){
- emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ // apply em pulse
+ if(bi->emp_intensity > 0.0f){
+ emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ }
  }
  }
  }
Index: code/sound/ds.cpp
===================================================================
--- code/sound/ds.cpp (revision 7567)
+++ code/sound/ds.cpp (working copy)
@@ -18,8 +18,8 @@
 #include "sound/acm.h"
 #include "osapi/osapi.h"
 #include "sound/dscap.h"
+#include "cmdline/cmdline.h"
 
-
 typedef struct sound_buffer
 {
  ALuint buf_id; // OpenAL buffer id
@@ -1129,6 +1129,10 @@
  // this is needed for 2D pan
  OpenAL_ErrorPrint( alListener3f(AL_POSITION, 0.0, 0.0, 0.0) );
  OpenAL_ErrorPrint( alListenerfv(AL_ORIENTATION, list_orien) );
+ if (Cmdline_listenergain > 0)
+ {
+ OpenAL_ErrorPrint( alListenerf(AL_GAIN, Cmdline_listenergain) );
+ }
 
  // disable doppler (FIXME)
  OpenAL_ErrorPrint( alDopplerFactor(0.0f) );
@@ -1407,24 +1411,33 @@
  }
  }
 
+ // Make sure that we are not going to play more copies of this sound than we should be
+ if ( Cmdline_enforce_concurrent_sound_count && (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
+ // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
+ if (lowest_instance_vol <= new_volume) {
+ ds_close_channel_fast(lowest_instance_vol_index);
+ first_free_channel = lowest_instance_vol_index;
+ }
+ }
+
  if (first_free_channel < 0) {
- // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
+ // Make sure that we are not going to play more copies of this sound than we should be
  if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
  // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
  if (lowest_instance_vol <= new_volume) {
  ds_close_channel_fast(lowest_instance_vol_index);
  first_free_channel = lowest_instance_vol_index;
  }
- } else {
- // there is no limit barrier to play the sound, so see if we've ran out of channels
- // stop the lowest volume instance to play our sound if priority demands it
- if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
- // Check if the lowest volume playing is less than the volume of the requested sound.
- // If so, then we are going to trash the lowest volume sound.
- if ( Channels[lowest_vol_index].vol <= new_volume ) {
- ds_close_channel_fast(lowest_vol_index);
- first_free_channel = lowest_vol_index;
- }
+ }
+ // still don't have a channel and
+ // there is no limit barrier to play the sound, so see if we've ran out of channels
+ // stop the lowest volume instance to play our sound if priority demands it
+ if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
+ // Check if the lowest volume playing is less than the volume of the requested sound.
+ // If so, then we are going to trash the lowest volume sound.
+ if ( Channels[lowest_vol_index].vol <= new_volume ) {
+ ds_close_channel_fast(lowest_vol_index);
+ first_free_channel = lowest_vol_index;
  }
  }
  }

Title: Re: Let's talk about the sound code... again.
Post by: Spoon on August 30, 2011, 01:54:11 pm
-alwaysenforce enabled while not perfect does give the best result, fixing sound from turrets&warpins 85% of the time. -listenergain between 0.8 - 0.9 slightly reduces the amount of clipping when it does happen, without making it sound like I need to turn up the volume of my speakers because the general sound volume sounds so soft. Imo if -alwaysenforce would work at every distance properly there would be no need for -listenergain at all.
-percent_flashtobang at 60 seems to give a pretty good nebula result.
not using openalsoft
Title: Re: Let's talk about the sound code... again.
Post by: torc on August 31, 2011, 05:02:48 pm
excuse me guys,but do you hear the capship warping effect?
and the capship explosion? the sound should be the Atomic.wav but what i only  hear is the clusterboom sound.
i noticed that working on Diaspora... i think is not only our issue,but i think is a bug in the code.
Plus, the Capship engine not work...if you pass near a ship like the Colossus,you hear nothing IIRC.
thanks in advance for your help
Title: Re: Let's talk about the sound code... again.
Post by: torc on September 01, 2011, 02:09:03 am
excuse me guys,but do you hear the capship warping effect?
and the capship explosion? the sound should be the Atomic.wav but what i only  hear is the clusterboom sound.
i noticed that working on Diaspora... i think is not only our issue,but i think is a bug in the code.
Plus, the Capship engine not work...if you pass near a ship like the Colossus,you hear nothing IIRC.
thanks in advance for your help
BUMP
ehm...i quoted myself...
thanks again :)
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on September 01, 2011, 07:29:56 am
Guys, Seriously.
Stop the irrelevant talk about speaker set ups and audiocards and do something with this:

Okay, another build to try.

This is a rollup of a few different changes so that that we can come up with some appropriate values and/or defaults.  The changes included are:
  • My fix from previously (http://www.hard-light.net/forums/index.php?topic=77889.msg1542937#msg1542937) disabled by default.  Enable with cmdline flag -alwaysenforce.
  • Allows dynamic adjustment of the change that Taylor posted (http://www.hard-light.net/forums/index.php?topic=77889.msg1543729#msg1543729).  By default it is also off.  Control this feature with -listenergain <value>-1 disables.  Useful range is 0.0 (effectively turns off sound) to 1.0 (presumably the same as -1).  Taylor's patch sets this to 0.65.
  • Allows control of the percentage of new lightning flashes that get turned into bangs (aka thunder sound plays).  Controlled with -percent_flashtobang <value>.  Default is 100.  I find 25 is too boring, 75 is still too much sound.

Thoughts?  Please post the settings of the above three flags and whether you are using the OpenALSoft.dll so that we can use the numbers to come up with good defaults for retail to use.

  • More sound code fun.7z (http://www.box.net/shared/tqpqk9s0qugczcyatpbv) (1.5MB; SHA-1: 7C2BD7D90BB8488A4B32EB093425E81E114C393A)

Code: (More sound code fun.patch) [Select]
Index: code/cmdline/cmdline.cpp
===================================================================
--- code/cmdline/cmdline.cpp (revision 7567)
+++ code/cmdline/cmdline.cpp (working copy)
@@ -437,8 +437,16 @@
 cmdline_parm output_sexp_arg("-output_sexps", NULL); //WMC - outputs all SEXPs to sexps.html
 cmdline_parm output_scripting_arg("-output_scripting", NULL); //WMC
 
+float Cmdline_percentflashtobang = 100.0f;
+float Cmdline_listenergain = -1;
+int Cmdline_enforce_concurrent_sound_count = 0;
 
+cmdline_parm percent_flashtobang_arg("-percent_flashtobang", NULL);
+cmdline_parm listenergain_arg("-listenergain", NULL);
+cmdline_parm always_enforce_concurrent_sound("-alwaysenforce", NULL);
 
+
+
 #ifndef NDEBUG
 // NOTE: this assumes that os_init() has already been called but isn't a fatal error if it hasn't
 void cmdline_debug_print_cmdline()
@@ -1450,6 +1458,21 @@
  Cmdline_bloom_intensity = bloom_intensity_arg.get_int();
  }
 
+ if ( listenergain_arg.found() )
+ {
+ Cmdline_listenergain = listenergain_arg.get_float();
+ }
+
+ if ( percent_flashtobang_arg.found() )
+ {
+ Cmdline_percentflashtobang = percent_flashtobang_arg.get_float();
+ }
+
+ if ( always_enforce_concurrent_sound.found() )
+ {
+ Cmdline_enforce_concurrent_sound_count = 1;
+ }
+
  return true;
 }
 
Index: code/cmdline/cmdline.h
===================================================================
--- code/cmdline/cmdline.h (revision 7567)
+++ code/cmdline/cmdline.h (working copy)
@@ -145,7 +145,10 @@
 extern int Cmdline_no_grab;
 #endif
 
+// Temp, only for evaluating new defaults
+extern float Cmdline_listenergain;
+extern float Cmdline_percentflashtobang;
+extern int Cmdline_enforce_concurrent_sound_count;
 
-
 //extern char FreeSpace_Directory[]; // allievating a cfilesystem problem caused by fred -- Kazan
 #endif
Index: code/nebula/neblightning.cpp
===================================================================
--- code/nebula/neblightning.cpp (revision 7567)
+++ code/nebula/neblightning.cpp (working copy)
@@ -21,10 +21,8 @@
 #include "weapon/emp.h"
 #include "network/multi.h"
 #include "network/multimsgs.h"
+#include "cmdline/cmdline.h"
 
-
-extern int Cmdline_nohtl;
-
 // ------------------------------------------------------------------------------------------------------
 // NEBULA LIGHTNING DEFINES/VARS
 //
@@ -439,24 +437,27 @@
 
  // do some special stuff on the very first strike of the bolt
  if(b->strikes_left == bi->num_strikes){
- // play a sound
- float bang;
- if(Nebl_bang < 40.0f){
- bang = 1.0f;
- } else if(Nebl_bang > 400.0f){
- bang = 0.0f;
- } else {
- bang = 1.0f - (Nebl_bang / 400.0f);
- }
- if(frand_range(0.0f, 1.0f) < 0.5f){
- snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- } else {
- snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- }
+ // play a sound
+ if (frand_range(0.0f, 100.0f) < Cmdline_percentflashtobang)
+ {
+ float bang;
+ if(Nebl_bang < 40.0f){
+ bang = 1.0f;
+ } else if(Nebl_bang > 400.0f){
+ bang = 0.0f;
+ } else {
+ bang = 1.0f - (Nebl_bang / 400.0f);
+ }
+ if(frand_range(0.0f, 1.0f) < 0.5f){
+ snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ } else {
+ snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ }
 
- // apply em pulse
- if(bi->emp_intensity > 0.0f){
- emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ // apply em pulse
+ if(bi->emp_intensity > 0.0f){
+ emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ }
  }
  }
  }
Index: code/sound/ds.cpp
===================================================================
--- code/sound/ds.cpp (revision 7567)
+++ code/sound/ds.cpp (working copy)
@@ -18,8 +18,8 @@
 #include "sound/acm.h"
 #include "osapi/osapi.h"
 #include "sound/dscap.h"
+#include "cmdline/cmdline.h"
 
-
 typedef struct sound_buffer
 {
  ALuint buf_id; // OpenAL buffer id
@@ -1129,6 +1129,10 @@
  // this is needed for 2D pan
  OpenAL_ErrorPrint( alListener3f(AL_POSITION, 0.0, 0.0, 0.0) );
  OpenAL_ErrorPrint( alListenerfv(AL_ORIENTATION, list_orien) );
+ if (Cmdline_listenergain > 0)
+ {
+ OpenAL_ErrorPrint( alListenerf(AL_GAIN, Cmdline_listenergain) );
+ }
 
  // disable doppler (FIXME)
  OpenAL_ErrorPrint( alDopplerFactor(0.0f) );
@@ -1407,24 +1411,33 @@
  }
  }
 
+ // Make sure that we are not going to play more copies of this sound than we should be
+ if ( Cmdline_enforce_concurrent_sound_count && (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
+ // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
+ if (lowest_instance_vol <= new_volume) {
+ ds_close_channel_fast(lowest_instance_vol_index);
+ first_free_channel = lowest_instance_vol_index;
+ }
+ }
+
  if (first_free_channel < 0) {
- // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
+ // Make sure that we are not going to play more copies of this sound than we should be
  if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
  // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
  if (lowest_instance_vol <= new_volume) {
  ds_close_channel_fast(lowest_instance_vol_index);
  first_free_channel = lowest_instance_vol_index;
  }
- } else {
- // there is no limit barrier to play the sound, so see if we've ran out of channels
- // stop the lowest volume instance to play our sound if priority demands it
- if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
- // Check if the lowest volume playing is less than the volume of the requested sound.
- // If so, then we are going to trash the lowest volume sound.
- if ( Channels[lowest_vol_index].vol <= new_volume ) {
- ds_close_channel_fast(lowest_vol_index);
- first_free_channel = lowest_vol_index;
- }
+ }
+ // still don't have a channel and
+ // there is no limit barrier to play the sound, so see if we've ran out of channels
+ // stop the lowest volume instance to play our sound if priority demands it
+ if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
+ // Check if the lowest volume playing is less than the volume of the requested sound.
+ // If so, then we are going to trash the lowest volume sound.
+ if ( Channels[lowest_vol_index].vol <= new_volume ) {
+ ds_close_channel_fast(lowest_vol_index);
+ first_free_channel = lowest_vol_index;
  }
  }
  }

Trying to fix the sound code here, useful feedback has been requested.
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on September 01, 2011, 01:39:39 pm
excuse me guys,but do you hear the capship warping effect?
and the capship explosion? the sound should be the Atomic.wav but what i only  hear is the clusterboom sound.
i noticed that working on Diaspora... i think is not only our issue,but i think is a bug in the code.
Plus, the Capship engine not work...if you pass near a ship like the Colossus,you hear nothing IIRC.
thanks in advance for your help
BUMP
ehm...i quoted myself...
thanks again :)
Your post that you quoted wasn't even up for 8 hours before you bumped it, 24-48 hours is a more realistic timeline.  If you want instant answers, use FS modding or #hard-light (assuming they have the answer for you), if you want researched answers, give the coders some time to research it.

Since you posted in this thread, I assume that is because the build that I posted breaks these sounds for you?  I have not changed anything that should affect the playback of these sounds, so if this build is breaking it, go to the the nightly build forum (http://www.hard-light.net/forums/index.php?board=173.0) and try the builds there to locate where we broke the sounds in question.

For the record,  I tested this last night, the correct warp, explosion, and engine sounds play just fine for me with retail assets in the trunk build and the build that I posted here.  More than likely the problem is a mod data issue and the ship that is not playing the explosion or warp sound is missing the "capital" ship flag.  I didn't get a chance to check on the specific requirements for engine sounds.

Trying to fix the sound code here, useful feedback has been requested.

Yes please.

With respect to the speakers and audio cards, find the settings (with retail assets) that you like the best with whatever you play the game with.  I am going to make whatever the consensus is the defaults for the engine.  The cmdline flags are not staying.
Title: Re: Let's talk about the sound code... again.
Post by: taylor on September 01, 2011, 09:50:47 pm
The listener gain thing is pointless as a fix.  I thought that it would help out, and if you don't look at it all too carefully then it does, but after going through the code (FSO and OpenAL) it is just a stupid thing.

I have found several bugs though, most specifically for warps and beams, where they are supposed be played as 3D sounds but get converted to being partially 2D and just kind of breaking how it's supposed to work/sound.  I've fixed that, but it still needs testing.

I also tested putting a timestamp on the nebula lightning so that it won't play a sound except in 750 ms intervals.  Doing this appears to best mimic the most of what retail tended to play.  But the main thing is that it got rid of the clipping 100% in my tests.  500ms clips a bit, 1000ms is too long of a time between sounds.  As a fix it appears to be the only thing that has worked perfectly for me, but it could probably use further tweaking to be even better.

Additionally I am working on some code to step down the gain of multiple of the same sound.  There are a few ways to go about this though and I haven't quite figured out how best to do it yet.  But the idea is that it should (hopefully) squash the clipping issue while still allowing for the full and rich sound environment provided by the new sound code.


Anyway, just an update on what I've found.
Title: Re: Let's talk about the sound code... again.
Post by: Flipside on September 01, 2011, 09:56:49 pm
Guys, Seriously.
Stop the irrelevant talk about speaker set ups and audiocards and do something with this:

Okay, another build to try.

This is a rollup of a few different changes so that that we can come up with some appropriate values and/or defaults.  The changes included are:
  • My fix from previously (http://www.hard-light.net/forums/index.php?topic=77889.msg1542937#msg1542937) disabled by default.  Enable with cmdline flag -alwaysenforce.
  • Allows dynamic adjustment of the change that Taylor posted (http://www.hard-light.net/forums/index.php?topic=77889.msg1543729#msg1543729).  By default it is also off.  Control this feature with -listenergain <value>-1 disables.  Useful range is 0.0 (effectively turns off sound) to 1.0 (presumably the same as -1).  Taylor's patch sets this to 0.65.
  • Allows control of the percentage of new lightning flashes that get turned into bangs (aka thunder sound plays).  Controlled with -percent_flashtobang <value>.  Default is 100.  I find 25 is too boring, 75 is still too much sound.

Thoughts?  Please post the settings of the above three flags and whether you are using the OpenALSoft.dll so that we can use the numbers to come up with good defaults for retail to use.

  • More sound code fun.7z (http://www.box.net/shared/tqpqk9s0qugczcyatpbv) (1.5MB; SHA-1: 7C2BD7D90BB8488A4B32EB093425E81E114C393A)

Code: (More sound code fun.patch) [Select]
Index: code/cmdline/cmdline.cpp
===================================================================
--- code/cmdline/cmdline.cpp (revision 7567)
+++ code/cmdline/cmdline.cpp (working copy)
@@ -437,8 +437,16 @@
 cmdline_parm output_sexp_arg("-output_sexps", NULL); //WMC - outputs all SEXPs to sexps.html
 cmdline_parm output_scripting_arg("-output_scripting", NULL); //WMC
 
+float Cmdline_percentflashtobang = 100.0f;
+float Cmdline_listenergain = -1;
+int Cmdline_enforce_concurrent_sound_count = 0;
 
+cmdline_parm percent_flashtobang_arg("-percent_flashtobang", NULL);
+cmdline_parm listenergain_arg("-listenergain", NULL);
+cmdline_parm always_enforce_concurrent_sound("-alwaysenforce", NULL);
 
+
+
 #ifndef NDEBUG
 // NOTE: this assumes that os_init() has already been called but isn't a fatal error if it hasn't
 void cmdline_debug_print_cmdline()
@@ -1450,6 +1458,21 @@
  Cmdline_bloom_intensity = bloom_intensity_arg.get_int();
  }
 
+ if ( listenergain_arg.found() )
+ {
+ Cmdline_listenergain = listenergain_arg.get_float();
+ }
+
+ if ( percent_flashtobang_arg.found() )
+ {
+ Cmdline_percentflashtobang = percent_flashtobang_arg.get_float();
+ }
+
+ if ( always_enforce_concurrent_sound.found() )
+ {
+ Cmdline_enforce_concurrent_sound_count = 1;
+ }
+
  return true;
 }
 
Index: code/cmdline/cmdline.h
===================================================================
--- code/cmdline/cmdline.h (revision 7567)
+++ code/cmdline/cmdline.h (working copy)
@@ -145,7 +145,10 @@
 extern int Cmdline_no_grab;
 #endif
 
+// Temp, only for evaluating new defaults
+extern float Cmdline_listenergain;
+extern float Cmdline_percentflashtobang;
+extern int Cmdline_enforce_concurrent_sound_count;
 
-
 //extern char FreeSpace_Directory[]; // allievating a cfilesystem problem caused by fred -- Kazan
 #endif
Index: code/nebula/neblightning.cpp
===================================================================
--- code/nebula/neblightning.cpp (revision 7567)
+++ code/nebula/neblightning.cpp (working copy)
@@ -21,10 +21,8 @@
 #include "weapon/emp.h"
 #include "network/multi.h"
 #include "network/multimsgs.h"
+#include "cmdline/cmdline.h"
 
-
-extern int Cmdline_nohtl;
-
 // ------------------------------------------------------------------------------------------------------
 // NEBULA LIGHTNING DEFINES/VARS
 //
@@ -439,24 +437,27 @@
 
  // do some special stuff on the very first strike of the bolt
  if(b->strikes_left == bi->num_strikes){
- // play a sound
- float bang;
- if(Nebl_bang < 40.0f){
- bang = 1.0f;
- } else if(Nebl_bang > 400.0f){
- bang = 0.0f;
- } else {
- bang = 1.0f - (Nebl_bang / 400.0f);
- }
- if(frand_range(0.0f, 1.0f) < 0.5f){
- snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- } else {
- snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- }
+ // play a sound
+ if (frand_range(0.0f, 100.0f) < Cmdline_percentflashtobang)
+ {
+ float bang;
+ if(Nebl_bang < 40.0f){
+ bang = 1.0f;
+ } else if(Nebl_bang > 400.0f){
+ bang = 0.0f;
+ } else {
+ bang = 1.0f - (Nebl_bang / 400.0f);
+ }
+ if(frand_range(0.0f, 1.0f) < 0.5f){
+ snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ } else {
+ snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ }
 
- // apply em pulse
- if(bi->emp_intensity > 0.0f){
- emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ // apply em pulse
+ if(bi->emp_intensity > 0.0f){
+ emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ }
  }
  }
  }
Index: code/sound/ds.cpp
===================================================================
--- code/sound/ds.cpp (revision 7567)
+++ code/sound/ds.cpp (working copy)
@@ -18,8 +18,8 @@
 #include "sound/acm.h"
 #include "osapi/osapi.h"
 #include "sound/dscap.h"
+#include "cmdline/cmdline.h"
 
-
 typedef struct sound_buffer
 {
  ALuint buf_id; // OpenAL buffer id
@@ -1129,6 +1129,10 @@
  // this is needed for 2D pan
  OpenAL_ErrorPrint( alListener3f(AL_POSITION, 0.0, 0.0, 0.0) );
  OpenAL_ErrorPrint( alListenerfv(AL_ORIENTATION, list_orien) );
+ if (Cmdline_listenergain > 0)
+ {
+ OpenAL_ErrorPrint( alListenerf(AL_GAIN, Cmdline_listenergain) );
+ }
 
  // disable doppler (FIXME)
  OpenAL_ErrorPrint( alDopplerFactor(0.0f) );
@@ -1407,24 +1411,33 @@
  }
  }
 
+ // Make sure that we are not going to play more copies of this sound than we should be
+ if ( Cmdline_enforce_concurrent_sound_count && (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
+ // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
+ if (lowest_instance_vol <= new_volume) {
+ ds_close_channel_fast(lowest_instance_vol_index);
+ first_free_channel = lowest_instance_vol_index;
+ }
+ }
+
  if (first_free_channel < 0) {
- // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
+ // Make sure that we are not going to play more copies of this sound than we should be
  if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
  // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
  if (lowest_instance_vol <= new_volume) {
  ds_close_channel_fast(lowest_instance_vol_index);
  first_free_channel = lowest_instance_vol_index;
  }
- } else {
- // there is no limit barrier to play the sound, so see if we've ran out of channels
- // stop the lowest volume instance to play our sound if priority demands it
- if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
- // Check if the lowest volume playing is less than the volume of the requested sound.
- // If so, then we are going to trash the lowest volume sound.
- if ( Channels[lowest_vol_index].vol <= new_volume ) {
- ds_close_channel_fast(lowest_vol_index);
- first_free_channel = lowest_vol_index;
- }
+ }
+ // still don't have a channel and
+ // there is no limit barrier to play the sound, so see if we've ran out of channels
+ // stop the lowest volume instance to play our sound if priority demands it
+ if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
+ // Check if the lowest volume playing is less than the volume of the requested sound.
+ // If so, then we are going to trash the lowest volume sound.
+ if ( Channels[lowest_vol_index].vol <= new_volume ) {
+ ds_close_channel_fast(lowest_vol_index);
+ first_free_channel = lowest_vol_index;
  }
  }
  }

Trying to fix the sound code here, useful feedback has been requested.

Considering that part of what is being discussed is what soundcards people use and how effective the OpenAL support is on them, I would consider that useful, even if it isn't useful to you personally, don't assume that such information is irrelevant. I've fixed sound issues on a friend computer because they'd turned on some internal effects on their own card or it had a built in EQ that had been enabled.

As such, the discussion of soundcards used by members is not irrelevant.

Secondly, as Taylor stated, he is looking for a way to reduce gain on multiple occurences of the same sound, this, once again, relates to the fact that the problem might not be the actual sound itself, but the way the computer mixes it, which is also what I was talking about earlier.
Title: Re: Let's talk about the sound code... again.
Post by: Zacam on September 01, 2011, 10:02:59 pm

Flipside: Reporting on ones sound configuration and setup while also providing feedback is more the point, not just some random divergence into talking about setups.
Title: Re: Let's talk about the sound code... again.
Post by: Flipside on September 01, 2011, 10:16:18 pm
Agreed, more detail and a more formalised system would probably be needed, but the fact is that if someone is having problems with the sound code, it wouldn't hurt to know what card they are using. That's why I can't really contribute to the thread beyond suggestions, because I know that OpenAL support on my card sucks at the best of times, so I could be having problems that are purely related to that low level of support.

It's not the level of detail I have a problem with, it's the casual shrugging off of information because 'we're trying to fix the sound code here', there are polite ways and rude ways of doing things and a simple smattering of good manners, particularly outside of GD, is not such a big thing to ask.

I've stated on a few sound code threads that I felt it was more to do with the mixing of the sounds when the audio is particularly 'busy', though apparently Taylor found some other problems as well, and I stand by that belief, but if people want to consider my input irrelevant then fine.
Title: Re: Let's talk about the sound code... again.
Post by: taylor on September 02, 2011, 12:25:52 am
Sound system setup can change everything about what works and what doesn't, so it never hurts to verify what someone has.  Simply playing the game with headphones instead of a 7.1 sound system can give very different results.  The 7.1 system can play sounds in a different place or moving in a weird direction, and headphones wouldn't show any of that.  Hardware makes a bit of difference, particularly if the sound drivers have an effects mixer which can give strange results if any of that is enabled.  OpenAL versions and how it's installed can make a difference as can what backend is in use.  Also the platform in use can be a big factor, as OpenAL works quite a bit differently on Windows than it does for Linux and OS X.  Far too much depends on the system and setup in question to assume that anything is just a problem with the code.

But I am definitely seeing a couple of code bugs.  Things that weren't really an issue with the DS/DS3D code because of how the two operate (as far as I know, not an expert), but are an issue with OpenAL since it's a unified system.  Cleaning up those issues will help deal with some 2D vs. 3D problems and make it easier to address the other issues.

I haven't quite figured out the true cause of the clipping issue, but it does seem to be related to a mixing problem with sounds that are in close proximity to each other.  Tweaking the gain a bit manually on those individual sounds did a lot to reduce the clipping problems so it's now a matter of implementing a system which can handle that in an automatic manner, and hoping that it really works to fix the problem.
Title: Re: Let's talk about the sound code... again.
Post by: chief1983 on September 02, 2011, 01:26:23 am
Taylor:   :yes: :yes: :yes:

That's right, I grew a third thumb for that maneuver.
Title: Re: Let's talk about the sound code... again.
Post by: QuantumDelta on September 02, 2011, 03:25:22 am
It is indeed quite relevant because, despite having tried for a while when I have been at my pc (hense, sorry, why I haven't popped up another video with the latest build when I have been on it), I haven't been able to repro the clipping described on Spoons machine on any of the builds, I assume, because of how much the Zonar can handle.
Title: Re: Let's talk about the sound code... again.
Post by: torc on September 02, 2011, 12:39:20 pm
excuse me guys,but do you hear the capship warping effect?
and the capship explosion? the sound should be the Atomic.wav but what i only  hear is the clusterboom sound.
i noticed that working on Diaspora... i think is not only our issue,but i think is a bug in the code.
Plus, the Capship engine not work...if you pass near a ship like the Colossus,you hear nothing IIRC.
thanks in advance for your help
BUMP
ehm...i quoted myself...
thanks again :)
Your post that you quoted wasn't even up for 8 hours before you bumped it, 24-48 hours is a more realistic timeline.  If you want instant answers, use FS modding or #hard-light (assuming they have the answer for you), if you want researched answers, give the coders some time to research it.

Since you posted in this thread, I assume that is because the build that I posted breaks these sounds for you?  I have not changed anything that should affect the playback of these sounds, so if this build is breaking it, go to the the nightly build forum (http://www.hard-light.net/forums/index.php?board=173.0) and try the builds there to locate where we broke the sounds in question.

For the record,  I tested this last night, the correct warp, explosion, and engine sounds play just fine for me with retail assets in the trunk build and the build that I posted here.  More than likely the problem is a mod data issue and the ship that is not playing the explosion or warp sound is missing the "capital" ship flag.  I didn't get a chance to check on the specific requirements for engine sounds.


i've just Bump my post not for ask you an immediate  answer for my issue,but because seems the discussion went out topic...that's all.

second: i'll try with the new build and see if there are some differences.
Anyway,i can't hear the atom.wav sound when a capship blows and the other issues in the retail build too,and is not due to the soundcard because all the Diaspora members noticed that.

Thanks for the help

Title: Re: Let's talk about the sound code... again.
Post by: QuantumDelta on September 02, 2011, 04:56:10 pm
Enough.

Can any non-to-the-subject posts be cleared out and no more be posted, please? Use your self-restraint guys thanks.


I think I nailed the flash-to-bang number needed, although obviously it's to personal taste so... video forthcoming.

Edit for video;

http://www.youtube.com/watch?v=4mry7YcdhaI

As it says in the description I'll fold it into the current long compilation video shortly and will end up;
http://www.youtube.com/watch?v=yBBONSZWTCA
Title: Re: Let's talk about the sound code... again.
Post by: Cyborg17 on September 03, 2011, 02:30:08 am
Flash-to-bang is pretty solid in the video, but will it work in a mission with less lightning?
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on September 06, 2011, 07:35:39 pm
Still eagerly awaiting for updates from Taylor on this.
Title: Re: Let's talk about the sound code... again.
Post by: QuantumDelta on September 07, 2011, 04:15:38 am
 23:01   QuantumDelta    • probably a good idea
 23:01   QuantumDelta    • how do you vary nebula lightning strikes normally btw?
 23:01   Axem            • what
 23:01   QuantumDelta    • in fred somehow?
 23:02   Axem            • RC?!
 23:02   Axem            • yeah QD
 23:02   Axem            • there's some storm settings in FRED
 23:02   Axem            • theyre rather coarse though i think
 23:04   Axem            • there's standard, active, medium and the ever favorite, emp
 23:05   QuantumDelta    • which one is the one used in the mission I've been videoing?
 23:05   Axem            • i dunno
 23:05   Axem            • which mission is it
 23:06   QuantumDelta    • uhmmm
 23:06   QuantumDelta    • with the warspite and lucidity and the two freighters....
 23:07   Axem            • Battle of the Wilderness?
 23:07   QuantumDelta    • might be?
 23:07   Axem            • +Storm: s_active
 23:09   QuantumDelta    • I wonder what the flash differences are..
 23:14   Axem            • http://pastebin.com/RtN7Nhx9
 23:14   Axem            • active is the heaviest
 23:14   Axem            • thats not the actual table
 23:14   Axem            • i just cut out the timing parts
 23:46   QuantumDelta    • I was gonna suggest some clever idea for how to change those timings so they'd work but uhh
 23:46   QuantumDelta    • 350-550, 500-900, 900-1850 sounds fine to me :<

obviously there are gameplay implications with changing the emp nebula flash though.. but sound wise those values sound right
Title: Re: Let's talk about the sound code... again.
Post by: jr2 on September 07, 2011, 08:53:20 am
change the EMP and sound so they are controlled in separate tables, e.g., you can have an 'active' storm, but the EMP effects are low.  This would also be helpful for if they develop "hardened" fighters in a mission that are more insulated against EMP.

Good idea, yes/no?
Title: Re: Let's talk about the sound code... again.
Post by: chief1983 on September 07, 2011, 11:52:15 am
How close are we to locking in reasonable numbers here?  We'd like to start the RC phase and we were thinking if this is still needing some input we could commit the configurable stuff to trunk, and lock it in for a final 3.6.14 release.
Title: Re: Let's talk about the sound code... again.
Post by: QuantumDelta on September 07, 2011, 12:19:43 pm
My offered numbers are based on a few tests, of which the comparison is visible (in terms of percentages of sound) in my last video with the input from cyborg making the note to factor in that the other nebulae have different levels.
It just needs a bit of legwork from some other people to see if it's not just 'to my tastes' or so.
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on September 07, 2011, 12:57:56 pm
How close are we to locking in reasonable numbers here?  We'd like to start the RC phase and we were thinking if this is still needing some input we could commit the configurable stuff to trunk, and lock it in for a final 3.6.14 release.

Well, only 2 people have actually offered any data to me, which results in 3 data points, which IMHO is not enough.

Also Taylor is working on some more proper fixes that may actually remove the need for any of my tweaks.
Title: Re: Let's talk about the sound code... again.
Post by: pecenipicek on September 07, 2011, 03:29:22 pm
i think this is one of the things that really REALLY shouldnt be hard-coded to the engine, as what might sound good with one set of effects, might sound crap with another set of effects.

Come one coders, you're not supposed to only keep everything retail-like and hard-coded, add another table for things like this and give us modders ways to work out things on our own as well.
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on September 07, 2011, 04:04:18 pm
i think this is one of the things that really REALLY shouldnt be hard-coded to the engine, as what might sound good with one set of effects, might sound crap with another set of effects.

Come one coders, you're not supposed to only keep everything retail-like and hard-coded, add another table for things like this and give us modders ways to work out things on our own as well.

With respect to the speakers and audio cards, find the settings (with retail assets) that you like the best with whatever you play the game with.  I am going to make whatever the consensus is the defaults for the engine.  The cmdline flags are not staying.

Title: Re: Let's talk about the sound code... again.
Post by: Axem on September 07, 2011, 07:41:56 pm
Okay, so to help get the RC cycle going, I decided to help.

http://lazymodders.fsmods.net/files/NewSoundCodeTestMission.rar

Here's some test missions for people to play to experiment around with the settings.

ClippingTest.fs2 tries very hard to clip audio. 12 Fighters all jump in right next to the player at the same time, then 6 mjolnirs fire at the same time.

My experience with that: -alwaysenforce + -listenergain around 0.5 - 0.65 sounded the best. (I preferred 0.5 personally)

NebTest.fs2 will cycle through the different storm types in FreeSpace to test -percent_flashtobang. Every 25s, a new storm type. I liked 30 in my opinion, though seeing close lightning without any sound was kind of odd. s_active is still too noisy for me though :p
Title: Re: Let's talk about the sound code... again.
Post by: mjn.mixael on September 08, 2011, 01:24:59 am
Using on-board RealTek on this rig (:(), 5.1 setup, soft_oal.dll as "Speakers (RealTek High Definition Audio) via DirectSound"

I used ' -alwaysenforce -listenergain 0.5 -percent_flashtobang 50'

Which seemed pretty good in all cases. The beams still clipped ever so slightly, but much better than it was.
Title: Re: Let's talk about the sound code... again.
Post by: pecenipicek on September 08, 2011, 03:29:57 am
With respect to the speakers and audio cards, find the settings (with retail assets) that you like the best with whatever you play the game with.  I am going to make whatever the consensus is the defaults for the engine.  The cmdline flags are not staying.
"The cmdline flags are not staying" part is what got my red flag waving around, as it implies that you will hardcode it and be done with it
Title: Re: Let's talk about the sound code... again.
Post by: Zacam on September 08, 2011, 03:38:50 am

Which is the best way to ensure a Retail like level of consistency in regards to particular environments.

If you want more expansion outside of that for a mod end, then you're looking at a modular sounds.tbl and using the sound_env.tbl for your mod, not dealing with the elements that these options are going to be setting up.
Title: Re: Let's talk about the sound code... again.
Post by: Davros on September 08, 2011, 04:06:08 am
Does the sound problem happen for all cards ?
Ive never heard it could that be because my soundcard is capable of 128 simultaneous sounds ?
also could it be an openal problem would sending the openal devs a bug report be worthwhile ?
Title: Re: Let's talk about the sound code... again.
Post by: pecenipicek on September 08, 2011, 04:40:12 am
Does the sound problem happen for all cards ?
in various amounts, yes.
Quote
Ive never heard it could that be because my soundcard is capable of 128 simultaneous sounds ?
You just might be one of the lucky ones who have cards which have proper hardware mixers, but even with my Audigy 2ZS i have these problems sometimes.
Quote
also could it be an openal problem would sending the openal devs a bug report be worthwhile ?
Doubtful.
Title: Re: Let's talk about the sound code... again.
Post by: Zacam on September 08, 2011, 05:16:24 am

So, as promised, I ran a lot of testing. I modified the .patch to compile to Antipodes, since that is what I do most of my testing with, but with that in mind, I will be repeating all of my tests again with Trunk.

I also need to test under "Generic Software" as well, which I will do and either update this post, or make an additional post (which ever is preferred)


As for the hardcoded stuff: What we are looking at and for HERE are being able to accurate represent and reproduce the "Retail" environment for effects playback that is consistent across the board.

OTHER things, like a flexible modular sounds.tbl and active use of the sound_env.tbl (which practically NOBODY is currently familiar with and I would LOVE for taylor, if he could one more time, post that and explain it for people so we can get it into the wiki) are what will allow for the non-hardcoded leverage of taking advantage of this new sound code. To be able to allow mod's to have the ability to control environment, sample playback amounts and/or gain and everything else is NOT what the purpose of THIS current testing is about. Those ARE issues and they DO need to be addressed, but not within the scope of THIS testing. Yes, it WILL be nice also being able to control these values outside of hard coded values. But we NEED the hard coded values FIRST to establish what the defacto baseline is so that pioneering sound engineers (no pun intended) know that what is heard on one system has a better chancre of still sounding just like that on another system.
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on September 22, 2011, 06:10:21 am
 :bump:
Would be a shame to let this issue slip into oblivion again when there was finally some progress getting made
Title: Re: Let's talk about the sound code... again.
Post by: chief1983 on September 22, 2011, 08:38:31 am
Don't worry, it won't.  I've been too busy this week to follow up due to a global summit at work, but as soon as that's over I'm going to be diving straight into getting something in to rectify the situation enough for the RC.
Title: Re: Let's talk about the sound code... again.
Post by: Spoon on September 22, 2011, 09:06:02 am
Don't worry, it won't.  I've been too busy this week to follow up due to a global summit at work, but as soon as that's over I'm going to be diving straight into getting something in to rectify the situation enough for the RC.
Excellent  :yes:
Title: Re: Let's talk about the sound code... again.
Post by: torc on September 22, 2011, 02:04:15 pm
if is possible, i wanna notice that the atom.wav sound is tied only at  Flags: "Capital"  in ships.tbl.

If the Flag is "supercap" or "freighter" the atom.wav not work.

Hope you can fix this bug :)
Title: Re: Let's talk about the sound code... again.
Post by: chief1983 on September 22, 2011, 02:09:45 pm
Is it Mantis'd?  Be a good idea to point out the number if so, and it probably won't get fixed if not.
Title: Re: Let's talk about the sound code... again.
Post by: torc on September 22, 2011, 02:15:20 pm
ehm...i don't know use mantis :(

Could you please do this for me?
Thanks in advance :)
Title: Re: Let's talk about the sound code... again.
Post by: pecenipicek on September 22, 2011, 02:21:14 pm
ehm...i don't know use mantis :(

Could you please do this for me?
Thanks in advance :)
http://scp.indiegames.us/mantis

register there and open a new issue. If you are unsure on how to actually format your new issue, take a look at the previously added issues and format accordingly.
Title: Re: Let's talk about the sound code... again.
Post by: torc on September 22, 2011, 02:50:41 pm
i am lazy :P

ok i'll do it...
Title: Re: Let's talk about the sound code... again.
Post by: The E on September 23, 2011, 06:13:13 pm
i am lazy :P

ok i'll do it...

Please do. Also note that issues on Mantis tend to get more priority than bug reports on the forum or bug mentions on IRC.
Title: Re: Let's talk about the sound code... again.
Post by: torc on September 24, 2011, 06:36:44 am
did it :)
Title: Re: Let's talk about the sound code... again.
Post by: Qent on September 24, 2011, 09:37:55 am
I did some checking, and this thread (http://www.hard-light.net/forums/index.php?topic=77314.msg1550263#msg1550263) might be relevant here too.

Also Mantis'd.
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on September 26, 2011, 10:13:18 pm
A more permanent version of the previous build has been committed as revision 7814 in preparation for 3.6.14 RC stage. See the commit message for details as it is a little different that what was here previously.  Of note is -listenergain is not a cmdline flag in the committed version and -alwaysenforce has been inverted as -donotenforce.

What was committed is consensus of this thread, which is locked in as the defaults for the RC.  The flags -donotenforce and -percent_flashtobang will be removed before .14 final.  percent_flashtobang will remain adjustable via lightning.tbl in the .14 final.
Title: Re: Let's talk about the sound code... again.
Post by: Alex Heartnet on September 26, 2011, 10:17:42 pm
I think I figured out a good compromise to the sound code problem.  Include both in the port, make a launcher flag that allows one to use the old sound code instead of the new one, and add a corresponding checkbox in the 'features' tab of the launcher.

Now users can use whichever version of the sound code they prefer.  Problem solved.
Title: Re: Let's talk about the sound code... again.
Post by: chief1983 on September 26, 2011, 10:56:22 pm
Except we can't.  The two can't exactly coexist.  It was a rewrite of much of the fundamental behavior of the code, not just some tweaks here and there.  Since you're new, I'll take that as an honest mistake, but generally programmers don't like being told how to do their jobs by non-programmers.

Also IssMneur, the idea was to commit it to just the 3.6.14 branch now that we have it :P
Title: Re: Let's talk about the sound code... again.
Post by: Iss Mneur on September 26, 2011, 11:13:07 pm
Except we can't.  The two can't exactly coexist.  It was a rewrite of much of the fundamental behavior of the code, not just some tweaks here and there.  Since you're new, I'll take that as an honest mistake, but generally programmers don't like being told how to do their jobs by non-programmers.

Also IssMneur, the idea was to commit it to just the 3.6.14 branch now that we have it :P
Bah, you need to copy the patch from somewhere :D  Besides, we don't know how long it will be till we have the proper fixes to the sound code.  But you or I can revert it if you like.