Spring RTS Engine

You know, as much i select the same unit as much a new select sound will be spawned in the game. My soundcard blows up with distortions. Again, is this a feature or not? I think sound should be blocked until the previous one is finished playing. I would like to point: this issue is concerning a single unit selection only.

You can limit number of simultaneous sounds in spring settings. You'll probably have to enable advanced settings tho.
You can also lower unit replay volume.

It's a feature and it doesn't bother anyone as long as they play the game. But it seems you like constantly click on one unit for some reason.

No, i don't want to reduce the total number of simultaneous sounds in game.

Also I could not reproduce this in OTA, so i decided to post.

slogic wrote:No, i don't want to reduce the total number of simultaneous sounds in game.

Also I could not reproduce this in OTA, so i decided to post.

Spring is not OTA. If you want that, play ota then.

Beherith wrote:Spring is not OTA. If you want that, play ota then.

This is another time i get the similar anwser. I think people should stop answering like this. If i'm posting here then i have my interest in Spring. Don't you get it? Can't i express my thoughts about Spring on the forum? This is ridiculous.

This is ridiculous.

Welcome to the forums

A game made over a decade ago can play sounds without massive clipping problems, so should Spring. It doesn't. You can mask it, by turning stuff down, but it's a bug, simply put.

Auswaschbar is currently working on hardware-accelerated sound, to bring Spring into the 21st century in that area. Right now, it's pretty rough, but I can see he's working hard to make it better for the next version.

For now... meh, if you build a lot of one kind of unit a lot, you should turn down the unit reply volumes. It's the only real "fix".

Argh wrote:Auswaschbar is currently working on hardware-accelerated sound, to bring Spring into the 21st century in that area. Right now, it's pretty rough, but I can see he's working hard to make it better for the next version..

What the heck are you talking about? All that's changed is that it uses the same sound system on windows as it has on linux.

Argh wrote:A game made over a decade ago can play sounds without massive clipping problems, so should Spring. It doesn't. You can mask it, by turning stuff down, but it's a bug, simply put.

I wouldn't really put it that way. My calculator can play sounds without clipping, because it only plays one thing at a time.

What the heck are you talking about? All that's changed is that it uses the same sound system on windows as it has on linux.

Meh, that's not quite what I got from the changelog, but I suppose that it depends on how much of that functionality is exposed to Lua in the end.

I just hope OpenAL sucks less than the last time it was put into Windows- I assume that they've finally made it be able to run WAVs without horrible popping and hissing on most audio hardware now

I wouldn't really put it that way. My calculator can play sounds without clipping, because it only plays one thing at a time.

For one thing... OTA played quite a few simultaneous sounds, at least polyphony levels of 16 or so.

Without clipping or distortion, either. And, if you've ever fired up Audacity and looked at the waveforms, it wasn't because their audio engineer was really clever- by today's standards, many of the sounds come dangerously close to clipping levels, and certainly would, if played simultaneously.

Spring, on the other hand, struggles with 16 sounds, when most modern game engines, and practically all soundcards, even the cheap ones, can do far more polyphony pretty well.



For another thing, practically all commercial games don't clip or have serious issues with distortion, either.

When's the last time you heard massive distortion in a MP shooter? Yeah, me neither- even when multiple guys are all gunning away, it reaches peak volume, but doesn't exceed it. Oh, I suppose you could blow your speakers out, at peak volume, but you'd have to try.

Or think about the sound in Dawn of War. There, you could still hear footsteps of the big, stompy robots and things, in the middle of a firefight. In Spring, it just gets totally lost when combat starts.

To address this in Spring seems like it shouldn't be that awful. I think it's mainly because sound is considered to be un-sexy that nobody's fixed it up very well, and I'm hoping that this time around, it gets fixed properly.

First off, don't just send sounds off to the card any time something asks. Track a queue, then you know what's scheduled this frame. Don't do sounds in unsync, do them on a frame basis- nobody will ever notice.

Since you'd have a queue, you'd know what's in it and where it is, and the relative volume vs. the position the POV was in. That's already being determined- now, just store it, instead of sending it out immediately.

From there, it should be pretty easy. If X sounds are scheduled, and 3 out of X are the same .WAV, then we can add their combined volumes, and know immediately if they're going to clip. Anything over 110% of max volume is guaranteed to clip, given the way that we have to master sound. So... just send ONE .WAV to the sound driver, at whatever that final volume is. Not three, at three different volumes... like we're doing now, except for that rather weak hack for unit replies.

It'd be better to end up with some stuff playing mono, than just throw sounds around, or just give that final sound a positional offset that makes it accurate to the relative POV- I don't think we're really supporting 3D sound yet, so there ya go, it'd at least be stereo-correct, if not 3D-correct.

Ideally, yeah, we want everything positionally accurate, but that's ideally- many people's soundcards can't handle that. And if we're not asking the soundcard what it can actually handle, then we're just assuming that it'll work, because OpenAL / DirectSound accepts it.

Build a sound-state per Player, using that same queue, instead of sending every-bloody-thing over, so that player X and player Y don't have exactly the same thing going on, just with different positional information.

There's practically nothing that can be done, to avoid clipping entirely, but the last time I looked at the code, sound handling was really primitive in Spring.

Also we're not bothering to find out what polyphony or other features are available from the sound driver, so we don't know if we're exceeding the maximum number of sounds the card supports. We can ask OpenAL for that information, and know if we're going to saturate the card, and we can certainly know if we're in danger of saturating the bus- too many sounds of X length being delivered this frame is bad... delay a few of them a frame, it's better to hear them late than not hear them at all. And it's really a good idea not to saturate the bus.

Right now, we're not doing any of that. And that means, at least in the current build I'm testing, that sounds are frequently being cut off

Meh, if you have other code I should read, I'll read it, but that's basically what we were doing, so far as I can tell, and I hope it's improved.

Shoving too many wavs into the bus is a major problem, not just in terms of clipping but in terms of quality of the game state- you can very easily bring Spring to its knees by shoving enough sounds around, and it's really annoying that so many sounds are played per frame, and clipping so frequently... that stuff like unit movement noises get totally obliterated frequently, no matter how large a radius I give them

That had been the first 2 of about 10 sound-related commits.

I just hope OpenAL sucks less than the last time it was put into Windows- I assume that they've finally made it be able to run WAVs without horrible popping and hissing on most audio hardware now

Times change. Nowadays OpenAL is not only supported by major hardware companies, but also used in lots of modern (commercial and free) games.

Spring, on the other hand, struggles with 16 sounds, when most modern game engines, and practically all soundcards, even the cheap ones, can do far more polyphony pretty well.

Fortunaltely, you can configure spring to use as many sources at a time you want (in the settigns program).

First off, don't just send sounds off to the card any time something asks. Track a queue, then you know what's scheduled this frame. Don't do sounds in unsync, do them on a frame basis- nobody will ever notice.

Sounds are emited from synced ofc, but hardware (or OpenAL, don't know) plays them. And in fact, there is something coded in spring which prevents multiple unit replies from the same frame.

From there, it should be pretty easy. If X sounds are scheduled, and 3 out of X are the same .WAV, then we can add their combined volumes, and know immediately if they're going to clip. Anything over 110% of max volume is guaranteed to clip, given the way that we have to master sound. So... just send ONE .WAV to the sound driver, at whatever that final volume is. Not three, at three different volumes... like we're doing now, except for that rather weak hack for unit replies.

Sound are usually very short. They, however,
1. start with a small time-difference at least
2. are emmited from different positions
3. have different loudness (and pitch)
Al this makes it senseless to combine multiple sounds into 1. But additional, this is not where the clipping is comming from:
When a new sound is emmited, spring used a FIFO-queue for sounds. So it iterates over all (16 or more) sources, and when it emmits a sound, source x used to be stopped and gets a new sound attached, regardless if its still playing and if there are other sources free. Next time, source x+1 was getting stopped etc. Combine this with hundreds of soundsources on the battlefield, and you know where that noise is coming from.
I improved it a bit, so it looks for free sources first, but when noone is free, another is still getting stopped. What spring really needs is a prioritizing for sounds. Currently, the LLT from the othere edge of the map(even if you don't have LOS on it) can stop your unit reply or something.

Ideally, yeah, we want everything positionally accurate, but that's ideally- many people's soundcards can't handle that. And if we're not asking the soundcard what it can actually handle, then we're just assuming that it'll work, because OpenAL / DirectSound accepts it.

OpenAL has good software emulation. We don't need to care about how much your hardware can handle.

openal hardware mode can usually process at least 29 sources (my integrated sound chip can); software mode does a whopping 256 sources.

What spring really needs is a prioritizing for sounds. Currently, the LLT from the othere edge of the map(even if you don't have LOS on it) can stop your unit reply or something.

Well, yeah, I can hear that, in the tests with the current build. I'm not sure how much of this is priority, and how much of it's delaying stuff a frame. Sounds can get played via COB and other sources, too.

What we need, imo, is some more meaningful aggregation of sounds, and instead of FIFO, build a queue per frame. FIFO is causing a lot of the clipping.

For example- the infantry in P.U.R.E., because you deploy them in a line and they cannot move when prone... tend to clip when they volley-fire their weapons.

If sounds were held in a queue for a frame and some aggregation was done (i.e., instead of 10 rifle sounds, just one), they wouldn't clip- however... as it is, you get huge volume changes when they're all firing at once. To better-control that, the position in 3D space needs to be kept, and a comparison done.

Lots of other examples from P.U.R.E.- things like unit footsteps (where they are often frame-locked because you're giving a mass Move orders all at once), etc., cause major problems that don't occur in commercial engines. You don't see that stuff in the OTA mods, because they're using such primitive sound compared to a modern game.

If 30 calls for the same sound all originate in the same general area this frame... we know that we need to play this sound nice and loud, for it to be heard. So aggregate it, instead of FIFO.

Maybe use a system of sectors, instead of exact coordinates, to make the sort as fast as possible? Sectors could be fairly large (8 map squares, or more) and still seem correct most of the time.

What's clear is that we're routinely exceeding the number of sources available, and that we're frequently doing so with sounds that should have been combined into one source and sent with a non-clipping value.

Ok, that sounds expensive. But the CPU and bus hit for throwing around many copies of sounds (which aren't all short or small, especially with a game that's not using OTA-era sound quality) is not trivial. I see anywhere from 5% to 40% CPU load hits from sounds- and I've done a few tests, and I'm pretty sure sounds are one of the major things causing base explosions to cause everybody's sim state to reach a crawl.

Argh wrote:What we need, imo, is some more meaningful aggregation of sounds, and instead of FIFO, build a queue per frame. FIFO is causing a lot of the clipping.

Please, please, please don't talk beyond the bounds of your knowledge. It creates nothing but confusion or frustration.

Auswaschbar wrote:

Code: Select all

What the heck are you talking about? All that's changed is that it uses the same sound system on windows as it has on linux.

That had been the first 2 of about 10 sound-related commits.

You did things to improve it, but you didn't 'bring in hardware accelerated sound'. I meant all that had changed in sound systems.

1. I don't care if I'm mangling terms, guys. You know what I mean here- I want Spring to manage sounds, not just shove them to OpenAL and hope for the best. The hands-off approach is only fast on the Spring side, it's slow elsewhere and it doesn't work well.

Nor do I think I have the "magic bullet" or anything. Maybe there's a better solution- propose one

2. It seems a bit premature to talk about what it will or won't do, when it's only 2 patches in.

I've been wanting better sound control for ages- we've seen stuff like doppler shifting based on positional source movement in experiments, but that's stuff hardware can do these days, we should take advantage of that. Same with echoes and other quality-control stuff, that can greatly increase the perceived quality of the audio experience. Again... contrast Dawn of War, where you can clearly hear tanks rumbling even in the middle of combat... with Spring, where you have far too much complete silence, because playing multiple sound-streams is forbidden, and doing it with long WAVs is impractical because of the issues I'm talking about here- you'd max out the channels in a real hurry, and the CPU would get killed by hits of big soundfiles all the time. I tried it

Argh wrote:

What we need, imo, is some more meaningful aggregation of sounds, and instead of FIFO, build a queue per frame. FIFO is causing a lot of the clipping.

let me just lol here for a sec xD

Hey, lol all you want... making fun of me mangling technical terminology is always easy, and if it makes you feel better, great

Argh wrote:1. I don't care if I'm mangling terms, guys. You know what I mean here- I want Spring to manage sounds, not just shove them to OpenAL and hope for the best. The hands-off approach is only fast on the Spring side, it's slow elsewhere and it doesn't work well.

We all know it doesn't work well.

Argh wrote:I've been wanting better sound control for ages- we've seen stuff like doppler shifting based on positional source movement in experiments, but that's stuff hardware can do these days, we should take advantage of that. Same with echoes and other quality-control stuff, that can greatly increase the perceived quality of the audio experience. Again... contrast Dawn of War, where you can clearly hear tanks rumbling even in the middle of combat... with Spring, where you have far too much complete silence, because playing multiple sound-streams is forbidden, and doing it with long WAVs is impractical because of the issues I'm talking about here- you'd max out the channels in a real hurry, and the CPU would get killed by hits of big soundfiles all the time. I tried it

• we have doppler shift now, you can even enable pitching according to game speed (http://jobjol.nl/1740)
• echoes: no clue how to do that, and also no clue where an echo would be usefull in spring
• you don't do sounds in long WAVs, instead do one or more short clips and repeat them in some random order

no clue where an echo would be usefull in spring

Well, what if stuff like Big Giant Guns and Really Huge Explosions could use an echo, instead of having to build that into the WAV? Just a thought there.

you don't do sounds in long WAVs, instead do one or more short clips and repeat them in some random order

The clips in DoW aren't short clips, they're actually pretty long, and designed to play end-to-end.

Argh,

On a more serious note, mangling terms does matter. Programming/developing is a very precise business, communicating through these forums requires a lot of energy to read and understand the things people say. You can't be fuzzy about it. Think about what your saying and if you are unsure about something perform some research on the subject before you submit the post. If you (or anyone) just says things that don't make sense at all your reputation will decrease and eventually your posts will be ignored. By the looks of the lengths of your posts and the sheer sheer amounts of them, you don't want that :) And I don't wanna have to concentrate on things that are nonsense. You should really consider the quality of your replies.

Sorry for going off topic here, but this is very important imo.

My post got eaten by the Forum Monsters, apparently. This is a screen-capture of DoW's sound editing environment. It features maximum polyphony (didn't notice that before) envelope controls, etc.

You're mainly building a Lua textfile describing the audio parameters and compressing the sound for smaller filesize for transport, iirc. Lemme see if I can get an actual example of parameters...

Here ya go, a complete set of typical audio parameters from DoW (this is the movement noise of the Baneblade):