From: Jack Peel <jhp_at_cypress.com>
Date: Wed, 23 Oct 2002 10:44:10 -0700

Phil,

It would be nice to have this as an option for those of us who would like
the meter to be more accurate, maybe even create it as a compile option,
or a simple patch. The best of course would be a menu setting that
switched between the two modes, but that might be a little much work
as it sounds like it involves code in several different places.

Also did you ever get the peak meter to display in dB ? Or has this simply
lost interest ?

Jack

langhaarrocker wrote:

>On Wed, 23 Oct 2002 15:00:23 +0200, "Henri DAVID" <hdavid_at_mail.com>
>wrote:
>
>
>
>>My idea is to read peaks values from the MAS frequently let say 50 times per
>>second (is this value to high ?? will it drain to much juice?), and update
>>the peakmeter display only 10 times per second. the peakmeter would the not
>>display the last read QPeak value but an average of the last 5 five value or
>>maybe as it is a _PEAK_meter the max of the five last values would be then
>>more appropriated here.
>>
>>
>
>I experimented a lot with the peak meter code and yes, we can get it
>much more accurate. But only on the expense of more cpu activity which
>would give us less time to put the cpu in sleep mode -> energy
>consumption. So I decided against busy reading for playback as is
>merely a "nice to have" toy here. The only time a meter might become
>relevant is when copying from the analog output to another device. But
>in that case the recording device should provide the meter.
>When the jukebox is recording the whole thing looks completely
>different as the meter becomes a necessary tool. Then we want it to be
>as accurate as necessary.
>
>The code is already prepared for busy reading and asynchronous
>display. The intension is to call peak_meter_peek like hell. Frequent
>calls to peak_meter_peek searches for the maximum. Whenever a screen
>refresh is needed a call to peak_meter_read_l provides it with this
>maximum.
>
>Your idea to read out the mas twice in peak_meter_peek would be good
>for detecting clips. But that as well is already in the code - even if
>a little bit hidden:
>
>Note that in peak_meter_draw a call to peak_meter_read_l is followed
>by a call to peak_meter_peek:
>
>void peak_meter_draw(int x, int y, int width, int height) {
> int left = 0, right = 0;
> static int last_left = 0, last_right = 0;
> int meterwidth = width - 3;
> int i;
>
> /* if disabled only draw the peak meter */
> if (peak_meter_enabled) {
> /* read the volume info from MAS */
> left = peak_meter_read_l();
> right = peak_meter_read_r();
>
> peak_meter_peek();
> ....
>
>Both functions read out the volume info and thus we compare two peak
>values that are very close in time. This is about as good as we can go
>for clip detection.
>
>The real trick for high performance meter would be in wps.c in the
>function wps_show. Here is a code snippet that would dramatically
>increase the precision of the peak meter - at the cost of cpu time.
>
>#ifdef HAVE_LCD_BITMAP
> /* when the peak meter is enabled we want to have a
> few extra updates to make it look smooth. On the
> other hand we don't want to waste energy if it
> isn't displayed */
> if (peak_meter_enabled) {
> int i;
>
> for (i = 0; i < 4; i++) {
> long end_time = current_tick + HZ / 20;
> do {
> button = button_get(false);
> }
> while ( TIME_BEFORE(current_tick, end_time) &&
> button == BUTTON_NONE);
>
> wps_refresh(id3, 0, false);
> }
> } else {
> button = button_get_w_tmo(HZ/5);
> }
>#else
> button = button_get_w_tmo(HZ/5);
>#endif
>
>
>Phil
>
>
>
>
>
Received on 2002-10-23