Its not a bug and it has nothing to do with spring.
Well, I'm afraid I'd have to disagree with that.
Here's why:
A. The "maximum simultaneous sounds fix" just lowers the number of sound files that are allowed to be playing at once. It's like solving the problem of hearing dinner conversation in a restaurant by declaring that if there are 100 people talking, at all kinds of volumes, that we want to hear only X number of them, pulled out of a hat.
Obviously... you don't get logical results from that. It'd make more sense to limit the number of sounds played through based on their distance, however... the last time I checked, it's not filtered in any way. So, you may be hearing a factory off-screen, gunshots from a soldier on-screen, and be wasting the other 14 out of 16 "slots" on very faint foot-step sounds from distant sources. In OTA mods, it's harder to see how badly this works- in P.U.R.E., it's completely obvious, because I have a lot of ambient noise sources.
Modern soundcards, even supposedly-crappy chipset stuff on motherboards... can easily handle 32 or more simultaneous sounds playing through at once, often more. The problem is how multiples of the same sound occurring during a given frame is handled.
Currently, there's some logic in Spring that's supposed to prevent more than X from playing, period. However, it'd be smarter to add the number of simultaneous occurrences together, then multiply the volume- if greater than 100%, then halt at 100%, so that Spring won't cause horrible clipping. Set the "standard" level of a sound to 50%, and voila- one instance of a sound is fairly quiet, multiples are quite loud, and no clipping, and it'd save the soundcards from being overworked, and allow more sounds to play simultaneously in most situations with lower overhead.
B. The second problem is that the Unit Reply volume wasn't working correctly, due to using the incorrect Registry entry in SpringSettings. I believe this has already been addressed. Unit Replies have the same problem as multiple sounds playing on the same frame, and should be cured the same way- the only difference is that they won't ever fade with distance, and should have an artificial ceiling set by the user control, imo.
C. The third problem is that sound's fadeout due to distance is handled in a very user-unfriendly fashion.
Instead of specifying a fadeout distance, where past N you hear 0% of the resulting sound, the current system calls for a "volume", which then drops off after passing through a range-based formula- the "volume" defines the range, but the resulting relationship isn't very straightforward. I.E., I can go fetch that math for you, but most of you won't understand what it means, and it's not user-friendly, nor is it labeled in a way that has anything to do with what it does- "volume" is the term for the actual loudness of a sound, but what this actually does is to affect
attenuation from the point-source.
