Re: Calculating peak level in db
Re: Calculating peak level in db
- Subject: Re: Calculating peak level in db
- From: "James Chandler Jr." <email@hidden>
- Date: Sun, 13 Oct 2002 14:33:41 -0400
>
James Chandler Jr wrote:
>
> PeakDB = 20.0 * Log10(abs(MaxSampleValue));
>
>
This is what I was seeking for. Now I get the same
>
values the Delta Control Panel displays.
>
(=(20/ln(10))*ln(maxAbsSampleValue);
Hi Gerd
Glad it is working properly now.
>
By the way, I don't calculate abs of the max sample value
>
but max of (abs of each sample value)
Yeah thats how I do it too. Was just trying to be clear about what is
getting calculated.
>
I do it the other way round:
>
The recording thread updates max(abs(value)) per channel.
>
>
I have a second thread that asks for (and resets) these values 10 to 30
>
times a second and triggers a redraw.
Yep, how you handle the redraw issue depends on the environment. In an
application, its easy enough to use a low-priority timer or some kind of
idle process to update the screen at whatever rate you desire.
In plugins, it might not be desirable to add overhead of an extra timer just
to schedule meter updates. And the plugin DSP code might be getting called
in jerky spurts, without much regularity. Without using a timer, its easy
enough to count the number of samples processed within whatever DSP handler
is convenient for that purpose.
In DirectX plugins, the DSP code is rather far removed from the property
display window code, and the window is often not displayed at all, depending
on what the Host is doing. Also complicated by good odds that the DSP
process is running in a different thread from the window code, so it can be
unsafe or inefficient to draw to a window from the DSP thread.
In DirectX plugins, when my DSP thread decides a meter should be updated, if
the window containing the meter is visible, the DSP code sends an invalidate
message to the on-screen meter object, so that the meter object redraws
itself sometime later on, whenever the on-screen meter object receives the
invalidate message within its own thread context.
I'm very ignorant of OSX and CoreAudio so far, but from following the
discussions it sounds like OSX plugin DSP code and plugin window drawing
code are pretty separated from each other, similar situation to DirectX
plugins.
It will be awhile before I get time to write OSX AudioUnit plugins, but am
interested in the current discussion about how a DSP thread should control
window drawing. This is such a common task in many plugins, would be nice to
do it easy and clean.
James Chandler Jr.
BTW, here is a variation on meter display that can be useful for real low
CPU overhead, if efficiency is an issue or you have a zillion meters to
draw--
Old analog needle meters respond linearly, but display the proper dB level
by adjusting the markings on the linear meter. This isn't very useful for
values lower than -24 dB, but often a musician is most interested in stuff
happening above -24 dB.
By displaying a bar graph linearly, you can avoid the 20 * Log10
calculation, and avoid possibly complicated logic how to map dB level to the
meter real-estate.
Just map MaxSampleValue linearly across your meter. Mark the meter something
like this (crude ascii art best viewed with a fixed width font)--
-24 -15 -9 -6 -3 0
*|*|*|*|***|****|*******|*********|**************|
-48 -18 -12
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.