FPGA Central

Is there a quick, not much processing time needed, way to make the same
volume on a 16 signed int stream in real time?

I've heard of replaygain, rms, and fft now, but I don't think I have the
processing time able to devote to doing a perfect job of making multiple
streams the same volume in decibels. Is there a quick way / algorithm I can
look at the stream of 16 bit integers that will do a sufficient job? I
don't think I have the processing time available to consider all the
frequencies, how loud they are perceived, the energy, and averaging the DC
component.

Thanks,

SA Dev

SA Dev wrote:

> Is there a quick, not much processing time needed, way to make the same
> volume on a 16 signed int stream in real time?
>
> I've heard of replaygain, rms, and fft now, but I don't think I have the
> processing time able to devote to doing a perfect job of making multiple
> streams the same volume in decibels. Is there a quick way / algorithm I can
> look at the stream of 16 bit integers that will do a sufficient job? I
> don't think I have the processing time available to consider all the
> frequencies, how loud they are perceived, the energy, and averaging the DC
> component.
>
> Thanks,
>
> SA Dev

I don't know what you want. It's obvious that you can't control what you
aren't able to consider. You need to decide how good "good enough" is.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Hi Jerry,

> I don't know what you want. It's obvious that you can't control what you
> aren't able to consider. You need to decide how good "good enough" is.

I have a function that is getting 44.1khz samples (16bit) and I would like
to make it output at a consistent volume between streams... It would be
great to have the streams (different volumes) come out within a few decibels
of each other...

I realize that the volume may have to adjust since the stream is realtime
and I don't know if any louder volumes are coming down the line, but that is
ok.

Thanks for the help,

SA Dev

SA Dev wrote:

> Hi Jerry,
>
>
>>I don't know what you want. It's obvious that you can't control what you
>>aren't able to consider. You need to decide how good "good enough" is.
>
>
> I have a function that is getting 44.1khz samples (16bit) and I would like
> to make it output at a consistent volume between streams... It would be
> great to have the streams (different volumes) come out within a few decibels
> of each other...
>
> I realize that the volume may have to adjust since the stream is realtime
> and I don't know if any louder volumes are coming down the line, but that is
> ok.
>
> Thanks for the help,
>
> SA Dev

I still don't know what will make you happy and what will miss the mark;
what you would like at best and what you would be willing to settle for.

There are volume compressors used to maintain a constant output level
regardless of how the program material changes. The "ride gain" on the
signal, greatly diminishing the difference between crescendos and
diminuendos. They are good for speech (most tape recorders suitable for
meetings and dictation use them, but they make music sound rather
insipid. The best of them are quite good; it may do your job.

What hardware will you use to implement your device? How will the
software be written? There may be commercial units you can buy. If you
intend to look for those, look both for compressors and companders.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Jerry,

> >>I don't know what you want. It's obvious that you can't control what you
> >>aren't able to consider. You need to decide how good "good enough" is.

I'm sorry I'm not giving enough info. I am working with software that
emulates old arcade games, each arcade game may play its sound at a
different volume. Most of the games use old antiquated sound chips, or even
discrete components to generate the sound. What I would like to do is make
all the games have the same volume. I have access to a function that gets
each sample and can change it. Perfection would be a function that can
alter the sample values in such a way that they register exactly the same
decibel volume level on my sound level meter. Acceptible would be +-4 db I
would think...

Let me know if that helps or if you need more info, thanks for the help,

SA Dev

SA Dev wrote:

>
> I'm sorry I'm not giving enough info. I am working with software that
> emulates old arcade games, each arcade game may play its sound at a
> different volume. Most of the games use old antiquated sound chips, or even
> discrete components to generate the sound. What I would like to do is make
> all the games have the same volume. I have access to a function that gets
> each sample and can change it.

Must this be done in real time or is it possible to analyze
the sound produced by each game as it is installed, for
example? If the latter, you can do the root mean square
calculation to determine an average level for each such
game, save it somewhere, and apply a fixed gain (numerical
multiplication factor) to each sample at play time that is a
the ratio of the desired average level to the predetermined
level of the game.

To do this purely in real time will require "automatic level
control" wherein you compute a real time approximation to
the RMS value and adaptively adjust a gain accordingly which
you apply to the samples as you play them. I haven't done
that myself but I'm sure someone here can offer a snippet of
C code that does the ALC sensing and gain application.


Bob
--

"Things should be described as simply as possible, but no
simpler."

A. Einstein

Hi Bob,

> Must this be done in real time or is it possible to analyze
> the sound produced by each game as it is installed, for
> example? If the latter, you can do the root mean square
> calculation to determine an average level for each such
> game, save it somewhere, and apply a fixed gain (numerical
> multiplication factor) to each sample at play time that is a
> the ratio of the desired average level to the predetermined
> level of the game.

Yes, someone elses approach was similar to this (they didn't use RMS, but
rather just rather just peaks to determine if the volume was too loud).
They started out at 10 times normal volume and reduced the volume if
necessary to make it fit within the 16 bit integer. Then they stored the
multiplication factor so the game would start out next at the already
reduced factor. So, one time the game was run, sounds at first might be
louder than they should be until the loudest sounds of the game were
encountered, but then they would be leveled out. The problem is that their
idea of looking at the peaks only resulted in wide variations between games.
I think that is the part of their logic that is flawed.

I agree with the store multiplication factor, but the technique for using
the peaks to determine volume doesn't work well. That is what I'm trying to
improve.

Thanks!

SA Dev

"SA Dev" <nospam38925@forme.com> wrote in message
news:403c9ab5@news.tulsaconnect.com...
> Hi Bob,
>
> > Must this be done in real time or is it possible to analyze
> > the sound produced by each game as it is installed, for
> > example? If the latter, you can do the root mean square
> > calculation to determine an average level for each such
> > game, save it somewhere, and apply a fixed gain (numerical
> > multiplication factor) to each sample at play time that is a
> > the ratio of the desired average level to the predetermined
> > level of the game.
>
> Yes, someone elses approach was similar to this (they didn't use RMS, but
> rather just rather just peaks to determine if the volume was too loud).
> They started out at 10 times normal volume and reduced the volume if
> necessary to make it fit within the 16 bit integer. Then they stored the
> multiplication factor so the game would start out next at the already
> reduced factor. So, one time the game was run, sounds at first might be
> louder than they should be until the loudest sounds of the game were
> encountered, but then they would be leveled out. The problem is that
their
> idea of looking at the peaks only resulted in wide variations between
games.
> I think that is the part of their logic that is flawed.
>
> I agree with the store multiplication factor, but the technique for using
> the peaks to determine volume doesn't work well. That is what I'm trying
to
> improve.

"using the peaks doesn't work well" in what way?

You might consider averaging (lowpass filtering) the peaks so the highest
one or two don't drive the result - IF that's your concern.

Fred

Hi Fred,

> "using the peaks doesn't work well" in what way?

I've sent two files up to my FTP site at:

http://home.earthlink.net/~alank2/newasteroid.wav
and
http://home.earthlink.net/~alank2/newpengo.wav

The newasteroid.wav has much louder peaks, but is only 58db when I play it
on my system. The newpengo.wav has lesser peaks, but is 75db when I play it
on my system.

I'm using a cheap SPL meter, radio shack digital set to MAX (report max),
Fast, and Weighting "A".

Thanks,

SA Dev

Fred Marshall wrote:

> "SA Dev" <nospam38925@forme.com> wrote in message
> news:403c9ab5@news.tulsaconnect.com...
>
>>Hi Bob,
>>
>>
>>>Must this be done in real time or is it possible to analyze
>>>the sound produced by each game as it is installed, for
>>>example? If the latter, you can do the root mean square
>>>calculation to determine an average level for each such
>>>game, save it somewhere, and apply a fixed gain (numerical
>>>multiplication factor) to each sample at play time that is a
>>>the ratio of the desired average level to the predetermined
>>>level of the game.
>>
>>Yes, someone elses approach was similar to this (they didn't use RMS, but
>>rather just rather just peaks to determine if the volume was too loud).
>>They started out at 10 times normal volume and reduced the volume if
>>necessary to make it fit within the 16 bit integer. Then they stored the
>>multiplication factor so the game would start out next at the already
>>reduced factor. So, one time the game was run, sounds at first might be
>>louder than they should be until the loudest sounds of the game were
>>encountered, but then they would be leveled out. The problem is that
>
> their
>
>>idea of looking at the peaks only resulted in wide variations between
>
> games.
>
>>I think that is the part of their logic that is flawed.
>>
>>I agree with the store multiplication factor, but the technique for using
>>the peaks to determine volume doesn't work well. That is what I'm trying
>
> to
>
>>improve.
>
>
> "using the peaks doesn't work well" in what way?
>
> You might consider averaging (lowpass filtering) the peaks so the highest
> one or two don't drive the result - IF that's your concern.
>
> Fred

Whatever the criterion, if there's a chance that the gain product might
exceed the integer range, then you have to saturate rather than wrap
around, and to do it right, you ought to low-pass filter to smooth the
hard corners due to clipping. (But you'll get by if you don't.)

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

"Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message
news:zp6dnckGvuyjW6HdRVn-tw@centurytel.net...
>
> > Yes, someone elses approach was similar to this (they didn't use RMS,
but
> > rather just rather just peaks to determine if the volume was too loud).
> > They started out at 10 times normal volume and reduced the volume if
> > necessary to make it fit within the 16 bit integer. Then they stored
the
> > multiplication factor so the game would start out next at the already
> > reduced factor. So, one time the game was run, sounds at first might be
> > louder than they should be until the loudest sounds of the game were
> > encountered, but then they would be leveled out. The problem is that
> their
> > idea of looking at the peaks only resulted in wide variations between
> games.
> > I think that is the part of their logic that is flawed.
> >
> > I agree with the store multiplication factor, but the technique for
using
> > the peaks to determine volume doesn't work well. That is what I'm
trying
> to
> > improve.
>
> "using the peaks doesn't work well" in what way?

Perception of loudness is more based on average (or RMS) signal power than
on maximum peak level. A few large short peaks can dramatically alter the
peak level but may not affect the RMS level much at all.

According to CoolEdit's statistics:

New Asteroid
Peak amplitude: 0dB
Average RMS power: -4.85dB

New Pengo
Peak amplitude: -0.37dB
Average RMS power: -5.55dB

So you can see the peak amplitude is basically identical and the RMS power
is within 1dB. The reason your SPL meter shows such a dramatic difference
is probably due to the A-weighting performed by the meter. The New Asteroid
has most of its energy below 200 Hz while with New Pengo the energy is
concentrated between 1-2 kHz. The A-weighting curve is much more sensitive
to 1-2k than it is to low frequencies (see
http://sound.westhost.com/project17.htm for a graph).

If possible, turn off weighting on your SPL meter and you will probably see
less discrepancy. It is also possible that your playback system is
providing some attenuation of low frequencies, further skewing the results.

"SA Dev" <nospam38925@forme.com> wrote in message
news:403cdb9a$1@news.tulsaconnect.com...
> Hi Fred,
>
> > "using the peaks doesn't work well" in what way?
>
> I've sent two files up to my FTP site at:
>
> http://home.earthlink.net/~alank2/newasteroid.wav
> and
> http://home.earthlink.net/~alank2/newpengo.wav
>
> The newasteroid.wav has much louder peaks, but is only 58db when I play it
> on my system. The newpengo.wav has lesser peaks, but is 75db when I play
it
> on my system.
>
> I'm using a cheap SPL meter, radio shack digital set to MAX (report max),
> Fast, and Weighting "A".
>
> Thanks,
>
> SA Dev
>
>

Hi Jon,

> So you can see the peak amplitude is basically identical and the RMS power
> is within 1dB. The reason your SPL meter shows such a dramatic difference
> is probably due to the A-weighting performed by the meter. The New
Asteroid
> has most of its energy below 200 Hz while with New Pengo the energy is
> concentrated between 1-2 kHz. The A-weighting curve is much more
sensitive
> to 1-2k than it is to low frequencies (see
> http://sound.westhost.com/project17.htm for a graph).

I used the A-weighting because it says it "more reflects" what the volume
level is to the human ear. I realize there is probably a debate about
A-weighting. To me, pengo sounds much louder than the asteroids does. What
can I do in software to make both of them sound about the same volume level?

BTW, I'm having a real hard time getting why the RMS power can be equated to
the volume you hear. If you had a wav file that had only one sample in it,
say 10000, you wouldn't hear anything because there is no difference to make
the sound, yet the power it used was significant...

Thanks,

SA Dev

SA Dev wrote:
> BTW, I'm having a real hard time getting why the RMS power can be equated to
> the volume you hear. If you had a wav file that had only one sample in it,
> say 10000, you wouldn't hear anything because there is no difference to make
> the sound, yet the power it used was significant...

I assume you mean "that had all the samples equal to 10000" rather than
"that had only one sample in it, say 10000."

Because you can't hear DC no matter how much power it contains. Here's
what I would do if I were you.

1) calculate the average value (i.e., the DC component).
2) Subtract it out of the samples.
3) compute the RMS.
4) calculate scale (inversely proportionate to RMS)
5) multiply each sample by scale.

You can do all of these steps offline and store the resulting wav file.
But if you do that, you can manually adjust the volume (use cooledit or
something like that) until your ear likes it, and store the adjusted
wav. There is really no reason to adjust the wav file on the fly.

--
Jim Thomas Principal Applications Engineer Bittware, Inc
jthomas@bittware.com http://www.bittware.com (703) 779-7770
To understand recursion, one must first understand recursion.

As I mentioned in a previous post, you have to consider the ear's
sensitivity to different frequencies to get the true answer. The RMS power
is an approximation that works decently in most real world cases, but
obviously breaks down in "made up" waveforms such as yours. Another
assumption of RMS matching perceived volume is that the signal lasts for a
reasonably long duration. One sample ain't enough!

(BTW, you will hear something when you play a 1 sample waveform like yours,
namely a click or tick. Even if your file only has 1 sample in it, your
sound card is putting out the equivalent of a file full of zeros before and
after you play the sample. So the output goes from zero to 10000 back to
zero, creating a tick sound.)

I don't have enough time to tell you how to exactly accomplish what you
want--it's actually non-trivial. But the basic process, as has been
mentioned before, is to create an automatic gain control or compressor that
takes into account the frequency sensitivity of the human ear. The gain
control logic needs to see the signal filtered by something that is
approximately the ear's response, like say an a-weighting filter.

If you have a PC, how about just using a compressor software plug-in? I'm
sure there's some Direct X stuff or something that works in real-time. Or
do you really want to do this yourself as an educational/hobby project?

"SA Dev" <nospam38925@forme.com> wrote in message
news:403d0bd2$1@news.tulsaconnect.com...
> Hi Jon,
>
> > So you can see the peak amplitude is basically identical and the RMS
power
> > is within 1dB. The reason your SPL meter shows such a dramatic
difference
> > is probably due to the A-weighting performed by the meter. The New
> Asteroid
> > has most of its energy below 200 Hz while with New Pengo the energy is
> > concentrated between 1-2 kHz. The A-weighting curve is much more
> sensitive
> > to 1-2k than it is to low frequencies (see
> > http://sound.westhost.com/project17.htm for a graph).
>
> I used the A-weighting because it says it "more reflects" what the volume
> level is to the human ear. I realize there is probably a debate about
> A-weighting. To me, pengo sounds much louder than the asteroids does.
What
> can I do in software to make both of them sound about the same volume
level?
>
> BTW, I'm having a real hard time getting why the RMS power can be equated
to
> the volume you hear. If you had a wav file that had only one sample in
it,
> say 10000, you wouldn't hear anything because there is no difference to
make
> the sound, yet the power it used was significant...
>
> Thanks,
>
> SA Dev
>
>

Hi Jon,

> I don't have enough time to tell you how to exactly accomplish what you
> want--it's actually non-trivial. But the basic process, as has been
> mentioned before, is to create an automatic gain control or compressor
that
> takes into account the frequency sensitivity of the human ear. The gain
> control logic needs to see the signal filtered by something that is
> approximately the ear's response, like say an a-weighting filter.
> If you have a PC, how about just using a compressor software plug-in? I'm
> sure there's some Direct X stuff or something that works in real-time. Or
> do you really want to do this yourself as an educational/hobby project?

What is a compressor? How would it help? I just want some code that makes
both of the wav's I posted sound roughly the same volume in realtime... It
seems like it may be too complicated to be easily done however.

Thanks for the help,

SA Dev

In article <c1iur0$1hvldk$1@ID-210375.news.uni-berlin.de>,
Jon Harris <goldentully@hotmail.com> wrote:
>The reason your SPL meter shows such a dramatic difference
>is probably due to the A-weighting performed by the meter.

Is there a simple pole-zero approximation to A-weighting (or
other profile that is a good match to typical human perception
of "loudness")? Would a simple IIR followed by an RMS averaging
method provide a useful volume scaling factor (assuming this
had to be done in real-time)?


--
Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/
#include <canonical.disclaimer> // only my own opinions, etc.

"SA Dev" <nospam38925@forme.com> wrote in message
news:403d59ca@news.tulsaconnect.com...
> Hi Jon,
>
> > I don't have enough time to tell you how to exactly accomplish what you
> > want--it's actually non-trivial. But the basic process, as has been
> > mentioned before, is to create an automatic gain control or compressor
> that
> > takes into account the frequency sensitivity of the human ear. The gain
> > control logic needs to see the signal filtered by something that is
> > approximately the ear's response, like say an a-weighting filter.
> > If you have a PC, how about just using a compressor software plug-in?
I'm
> > sure there's some Direct X stuff or something that works in real-time.
Or
> > do you really want to do this yourself as an educational/hobby project?
>
> What is a compressor? How would it help? I just want some code that
makes
> both of the wav's I posted sound roughly the same volume in realtime...

That's what a compressor does!
http://www.google.com/search?hl=en&l...in&sa=N&tab=gw

> It seems like it may be too complicated to be easily done however.

Given your current level of expertise, that seems to be the case. I'd
recommend trying to find already written software.