Thread: RE: [GD-General] Sound
Brought to you by:
vexxed72
From: Ken N. <kn...@wh...> - 2005-05-15 20:47:58
|
Brian, Thank you for your feedback! I just bought the book, so hopefully it gets here in a few days. I can't use quieter sounds simply because I'm mixing up to 32 sound sources at once and if I reduce their volume to 1/32 the original then the user would have to have their speakers cranked up. I'll look into it some more and hopefully find a solution that will meet the requirements. Thanks again, -Ken Noland -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Brian Hook Sent: Sunday, May 15, 2005 12:55 PM To: gam...@li... Subject: Re: [GD-General] Sound On Sun, 15 May 2005 11:42:03 -0400, Ken Noland wrote: > Anybody know any good sound lists or really great articles on > software sound mixing? Try a good book on sound programming, several of them exist. Off the=20 top of my head is A Programmer's Guide to Sound by Kientzle. > an addition to the two sound samples produces errors when the sound > wraps around the limitations of a signed short. Yes. Welcome to sound programming =3D) > Clamping that > doesn't work either since sound is measured in a difference of > samples. Clamping doesn't work, period, since you end up clipping and=20 introducing distortion as a result. > Doing an average on the two sound samples causes sounds to > be more quiet then they should naturally be, so is there a better > way? Well, an average is just doing the addition and then rescaling the=20 results, which isn't always going to help you and just raises the=20 noise floor. There is no easy way around this. It's a large, complicated topic,=20 but the simplest answer (until you learn about the intricacies=20 involved) is "use quieter sounds". That way when you sum a bunch of=20 them, they hopefully won't clip, but even that's not a guarantee. Some fancier stuff mixes in floats and rescales on the fly, or applies=20 real-time compression/limiting, but that starts getting into the realm=20 of REAL complicated for someone without sound programming experience. Brian ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id=16281&op=3Dick _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU7 |
From: George W. <ge...@ap...> - 2005-05-16 17:34:16
|
On Sun, 15 May 2005 11:42:03 -0400, "Ken Noland" <kn...@wh...> wrote: > Anybody know any good sound lists or really great articles on software > sound mixing? I built a continuous streaming sound system and I'm having > difficulties mixing two sounds together. Just doing an addition to the > two sound samples produces errors when the sound wraps around the > limitations of a signed short. Clamping that doesn't work either since > sound is measured in a difference of samples. Doing an average on the > two sound samples causes sounds to be more quiet then they should > naturally be, so is there a better way? IIRC what you're looking for is called "cross normalization". You don't average (add all channels together and divide by the number of channels) because dead channels will attenuate the output too much; Instead you add the absolute values of all the channels together (pseudo envelope) and then normalize each channel against this absolute value. To improve dynamic range this should be done on a logarithmic scale. -- Enjoy, George Warner, Schizophrenic Optimization Scientist Apple Developer Technical Support (DTS) |
From: Brian H. <ho...@bo...> - 2005-05-16 17:46:25
|
> IIRC what you're looking for is called "cross normalization". You > don't average (add all channels together and divide by the number > of channels) because dead channels will attenuate the output too > much; The other issue is how large a window you perform these operations on. Clamping can be done per-sample-slice, but if you average per-sample then your volume is going to be all over the map. > Instead you add the absolute values of all the channels > together (pseudo envelope) and then normalize each channel against > this absolute value. To improve dynamic range this should be done > on a logarithmic scale. This is the similar to "riding the mixing slider", which works, but requires a lot more computational effort as you keep track of a sliding window and perform the normalization (via table lookup hopefully), along with a global volume atenuation. Unfortunately it's still very susceptible to heavy transients, but at least loud sections get compressed down. Something else to look at are compression/limitation DSP algorithms. Brian |
From: <bac...@ke...> - 2005-07-13 12:25:00
|
Hi I'm working on an improved math library. We are developing for linux and windows. I have a problem with inline assembly codes I can inline an assembly code, but I have to write all the codes 2 times to be able to compile with gcc and MSVC. I know about NASM, but with NASM I loose the inline functions. How do you guys do it? Writing every asm peace 2 or more times? Sacrifice the inline or add one more function call to the assembly function? How expensive is a function call today? Is there a way to convert Microsoft MASM code to GCC GAS? Best Regards Peter Balogh |
From: Ken N. <kn...@wh...> - 2005-05-16 19:26:56
|
Hey, I toyed with using a "sliding mixer", although at the time I didn't know what it was called. I noticed it would work on most cases, but as soon as you approached an area with tons of explosions and gunfire, and then you moved into an area that was quiet, the music was noticeably louder. I'm toying with the idea of using the slider based off of distance as well as sample amplitude. I'll let you know how that goes! I still haven't been able to find anything about this on the web, even though I have found a ton of pages about DSP and how to use FFT and all that fun stuff, none of them had any reduction mixing algorithms that I could find. Thanks -Ken Noland -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Brian Hook Sent: Monday, May 16, 2005 1:46 PM To: gam...@li... Subject: re: [GD-General] Sound > IIRC what you're looking for is called "cross normalization". You > don't average (add all channels together and divide by the number > of channels) because dead channels will attenuate the output too > much; The other issue is how large a window you perform these operations on.=20 Clamping can be done per-sample-slice, but if you average per-sample=20 then your volume is going to be all over the map. > Instead you add the absolute values of all the channels > together (pseudo envelope) and then normalize each channel against > this absolute value. To improve dynamic range this should be done > on a logarithmic scale. This is the similar to "riding the mixing slider", which works, but=20 requires a lot more computational effort as you keep track of a=20 sliding window and perform the normalization (via table lookup=20 hopefully), along with a global volume atenuation. Unfortunately it's still very susceptible to heavy transients, but at=20 least loud sections get compressed down. Something else to look at are compression/limitation DSP algorithms. Brian ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU7 |
From: Brian H. <ho...@bo...> - 2005-05-16 21:34:50
|
> was noticeably louder. I'm toying with the idea of using the slider > based off of distance as well as sample amplitude. I'll let you > know how that goes! What I've done in the past, which is cheap and easy but a gross hack, is to track the number of live sounds and use that as an amplitude modulation factor. The problem is that it's possible to have two sounds that sum to more power than 32 sounds, but on average 32 sounds will be louder than 2 sounds, but not 32 times louder*. So you don't want to just scale by (32-n)/32 (the number of active sounds), since that will drop off volume far too quickly. And it's still prone to failing in edge conditions. There really is no perfect way to get around it -- you have a fixed maximum range that can be exceeded, and you can't predict with 100% accuracy when this will happen without introducing latency and using some kind of real-time compression/limiting. Latency sucks for games, and real-time compression/limiting is expensive. FWIW, I don't believe any hardware mixers solve this problem either. Brian * Insert standard tangent about power, volume, and loudness -- by louder I mean "32 times greater amplitude". |
From: George W. <ge...@ap...> - 2005-05-17 16:12:39
|
On Mon, 16 May 2005 13:45:53 -0400, Brian Hook <ho...@bo...> wrote: >> IIRC what you're looking for is called "cross normalization". You >> don't average (add all channels together and divide by the number >> of channels) because dead channels will attenuate the output too >> much; > > The other issue is how large a window you perform these operations on. > Clamping can be done per-sample-slice, but if you average per-sample > then your volume is going to be all over the map. This is true. The min/max (or absolutes) should be used to compute an envelope. This envelope is used to up an AGC that then decay's over time. >> Instead you add the absolute values of all the channels >> together (pseudo envelope) and then normalize each channel against >> this absolute value. To improve dynamic range this should be done >> on a logarithmic scale. > > This is the similar to "riding the mixing slider", which works, but > requires a lot more computational effort as you keep track of a > sliding window and perform the normalization (via table lookup > hopefully), along with a global volume attenuation. I haven't found it to be particularly computationally heavy at all. Even the logarithmic mixing lends itself well to optimization if you have SIMD. > Unfortunately it's still very susceptible to heavy transients, but at > least loud sections get compressed down. This much is true. More importantly quiet channels aren't lost altogether when you have lots of silent channels. -- Enjoy, George Warner, Schizophrenic Optimization Scientist Apple Developer Technical Support (DTS) |
From: George W. <ge...@ap...> - 2005-05-17 16:40:10
|
On Mon, 16 May 2005 15:26:20 -0400, "Ken Noland" <kn...@wh...> wrote: > I toyed with using a "sliding mixer", although at the time I didn't know > what it was called. I noticed it would work on most cases, but as soon > as you approached an area with tons of explosions and gunfire, and then > you moved into an area that was quiet, the music was noticeably louder. > I'm toying with the idea of using the slider based off of distance as > well as sample amplitude. I'll let you know how that goes! Perhaps you could pre-mix everything but the music together and then average that with your music. The music then would maintain it's constant dynamic range and only your incidental sounds would be dynamically mixed together. > I still haven't been able to find anything about this on the web, even > though I have found a ton of pages about DSP and how to use FFT and all > that fun stuff, none of them had any reduction mixing algorithms that I > could find. "Game Audio Programming" is one of the more dog-ear'ed books in my programming bookcase. There are also many good sound articles in the Game Programming Gems series from Charles River Media. Also check out Csound, an open source sound library. An excellent book that explains it well is "The Csound Book: Perspectives in Software Synthesis, Sound Design, Signal Processing, and Programming" by Richard Boulanger (Editor). -- Enjoy, George Warner, Schizophrenic Optimization Scientist Apple Developer Technical Support (DTS) |
From: Brian H. <ho...@bo...> - 2005-07-29 02:23:55
|
This is kinda spam, but I'm only doing this on gd-general and this is one of the perks of being assistant list admin =3D) Anyway, my book on writing portable code has been released and is now available. More info at: http://www.writeportablecode.com Brian |