FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[Niels Mayer]

I've been long annoyed by alsa-tools' envy24control (*) lack of
peak-level indication in it's metering, and the non-implementation of
its "Reset Peaks" button:
https://bugzilla.redhat.com/show_bug.cgi?id=602903

I've fixed that annoyance. Now, a small white line appears above the
highest level on each meter, and can be reset via "Reset Peaks"
button.

Original source:
http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=envy24control/levelmeters.c;hb=HEAD
Patch:
http://nielsmayer.com/npm/602903.patch

To run this version of envy24control grab the most recent stable release (
ftp://ftp.alsa-project.org/pub/tools/alsa-tools-1.0.23.tar.bz2 ) or git pull
from trunk of the "alsa-tools" project (
http://alsa-project.org/main/index.php/GIT_Server ).

After unpacking and assuming you've got the patch in ~/602903.patch do:
>> cd alsa-tools-1.0.23
>> cat ~/602903.patch | patch -p1

it should give message "patching file envy24control/levelmeters.c" ...
follow the directions to compile alsa-tools....

Can whoever's in charge of these things commit this change "upstream"
and get it to propagate to the distros?
Alternately, give me commit access and I'll do it myself, if people
agree this patch is worth having.

Next steps:

(1) Think about building-in meter ballistics from Fons Adriaensen's
jkmeter ( http://www.kokkinizita.net/linuxaudio/downloads/jkmeter-0.4.0.tar.bz2
). Which helps implent Bob Katz' "K System" (
http://www.digido.com/level-practices-part-2-includes-the-k-system.html
). Although it probably most makes sense to implement such metering on
the main "digital mixer" meter of envy24control, if it's not too
inefficient, I'd want it available on all meters, despite the warning
from Fons ( http://old.nabble.com/First-release-of-jkmeter-td18798950.html
).
> This is the type of meter you want for live recording,
> mixing and mastering. It probably makes no sense to
> use it on all tracks of a DAW, where keeping digital
> level within limits is the main purpose of metering.

(2) Fix https://bugzilla.redhat.com/show_bug.cgi?id=602900 which
causes 'envy24control' to crash when given "-D" argument.
and behave incorrectly when given a correct non-numeric name for an
audio device: e.g.
>> envy24control  --card M66
>> invalid card type (driver is USB-Audio)
>> envy24control --card M66 --device M66
>> Segmentation fault (core dumped)

(3) Apply more reasonable defaults and automatically size to correct
dimensions. I use, for example:
>> envy24control --card 2 --outputs 4 --input 4 --pcm_output 8 --view_spdif_playback --midichannel 1 --midienhanced --window_width 1275 --tall_eq_mixer_heights 1 &

(4) Add midi output, in addition to midi input, which would monitor
the hardware peak metering from the ice1712
("amixer -c M66 cget iface=PCM,name='Multi Track Peak',numid=45")
and output a MIDI note-on on the corresponding MIDI channel whenever a
specified threshold value was exceeded. This could be used to
implement "automatic gain control" in association with the
midi-controllable ADC gain provided by envy24control.

Niels
http://nielsmayer.com

PS: (*)  http://alsa.opensrc.org/index.php/Envy24control
Cards supported by this fix:
                       *  M Audio Delta 1010
                       *  M Audio Delta 1010LT
                       *  M Audio Delta DiO 2496
                       *  M Audio Delta 66
                       *  M Audio Delta 44
                       *  M Audio Delta 410
                       *  M Audio Audiophile 2496
                       * TerraTec EWS 88MT
                       * TerraTec EWS 88D
                       * TerraTec EWX 24/96
                       * TerraTec DMX 6Fire
                       * TerraTec Phase 88
                       * Hoontech SoundTrack DSP 24
                       * Hoontech SoundTrack DSP 24 Value
                       * Hoontech SoundTrack DSP 24 Media 7.1
                       * Event Electronics, EZ8
                       * Digigram VX442
                       * Lionstracs, Mediastaton
                       * Terrasoniq TS 88

Re: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[Alan Horstmann]

[-- Attachment #1: Type: text/plain, Size: 3808 bytes --]

Hi Neils,

On Monday 12 July 2010 23:41, Niels Mayer wrote:
> I've been long annoyed by alsa-tools' envy24control (*) lack of
> peak-level indication in it's metering, and the non-implementation of
> its "Reset Peaks" button:
> https://bugzilla.redhat.com/show_bug.cgi?id=602903
>
> I've fixed that annoyance. Now, a small white line appears above the
> highest level on each meter, and can be reset via "Reset Peaks"
> button.
>
> Original source:
> http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=envy24control/
>levelmeters.c;hb=HEAD Patch:
> http://nielsmayer.com/npm/602903.patch

I wish I had been aware of your interest in this - in 2006-08 I coded rising 
peak and clip indicators for envy24 control, and have my versions patched.  
Unfortunately, I never got to a final re-work to submit; it has been on that 
'todo' list.  I was responsible for patches that introduced the present 
layout of envy24control, incl 'tall_eq_mixer_heights' etc.

Right now I am in the middle of other things, but I have quickly attached my 
existing patch, as you might like to try it.  I suspect many of the cc's on 
this mail will bounce (not-subscribed) so perhaps you could re-post it there.  
No guarantees though with current ALSA - I haven't updated since 1.0.18, and 
most boxes here use 1.0.12.  But I feel sure you will be able to get the 
patch to apply.  Come back with any issues.

<snip>

> Next steps:
>
> (1) Think about building-in meter ballistics from Fons Adriaensen's
> jkmeter (
> http://www.kokkinizita.net/linuxaudio/downloads/jkmeter-0.4.0.tar.bz2 ).
> Which helps implent Bob Katz' "K System" (
> http://www.digido.com/level-practices-part-2-includes-the-k-system.html
> ). Although it probably most makes sense to implement such metering on
> the main "digital mixer" meter of envy24control, if it's not too
> inefficient, I'd want it available on all meters, despite the warning
> from Fons ( http://old.nabble.com/First-release-of-jkmeter-td18798950.html
> ).
>
> > This is the type of meter you want for live recording,
> > mixing and mastering. It probably makes no sense to
> > use it on all tracks of a DAW, where keeping digital
> > level within limits is the main purpose of metering.

With the attached patch, all channels have rising peaks that reset at regular 
intervals, or hold (have a play with values in 'Extras').  The marker is 
half-width only.  No meter ballistics, though!

> (2) Fix https://bugzilla.redhat.com/show_bug.cgi?id=602900 which
> causes 'envy24control' to crash when given "-D" argument.
> and behave incorrectly when given a correct non-numeric name for an
> audio device: e.g.
>
> >> envy24control  --card M66
> >> invalid card type (driver is USB-Audio)
> >> envy24control --card M66 --device M66
> >> Segmentation fault (core dumped)
>
> (3) Apply more reasonable defaults and automatically size to correct
>
> dimensions. I use, for example:
> >> envy24control --card 2 --outputs 4 --input 4 --pcm_output 8
> >> --view_spdif_playback --midichannel 1 --midienhanced --window_width 1275
> >> --tall_eq_mixer_heights 1 &

Bear in mind that different hardware uses this, with different graphic 
environments; what seems the obvious ideal to you may not be so for others.  
Ultimately that is the job of command line arguments, as you do now.

I use this with DMX6fire and Hoontech DSP2000.

> (4) Add midi output, in addition to midi input, which would monitor
> the hardware peak metering from the ice1712
> ("amixer -c M66 cget iface=PCM,name='Multi Track Peak',numid=45")
> and output a MIDI note-on on the corresponding MIDI channel whenever a
> specified threshold value was exceeded. This could be used to
> implement "automatic gain control" in association with the
> midi-controllable ADC gain provided by envy24control.

Regards

Alan

[-- Attachment #2: e24c-AHrisingpeakclip-v1.patch --]
[-- Type: text/x-diff, Size: 14791 bytes --]

diff -ru envy24control/envy24control.c Aenvy24control/envy24control.c
--- envy24control/envy24control.c	2006-08-22 19:25:52.000000000 +0100
+++ Aenvy24control/envy24control.c	2008-07-28 23:07:28.000000000 +0100
@@ -1,5 +1,5 @@
 /*****************************************************************************
-   envy24control.c - Env24 chipset (ICE1712) control utility
+   envy24control.c - Env24 chipset (ICE1712) control utility **AH Peaks/clips mod v1 3.1.06
    Copyright (C) 2000 by Jaroslav Kysela <perex@suse.cz>
 
    (2003/03/22) Changed to hbox/vbox layout.
@@ -74,6 +74,12 @@
 GtkObject *hw_volume_change_adj;
 GtkWidget *hw_volume_change_spin;
 
+GtkWidget *clip_peaks_check;
+GtkWidget *auto_reset_clips_check;
+GtkWidget *riding_peaks_check;
+GtkWidget *auto_reset_riders_check;
+GtkObject *sw_peaks_reset_time_adj;
+
 GtkWidget *hw_spdif_profi_nonaudio_radio;
 GtkWidget *hw_spdif_profi_audio_radio;
 
@@ -210,7 +216,7 @@
 	gtk_signal_connect(GTK_OBJECT(drawing), "configure_event",
 			   GTK_SIGNAL_FUNC(level_meters_configure_event), NULL);
 	gtk_widget_set_events(drawing, GDK_EXPOSURE_MASK);
-	gtk_widget_set_usize(drawing, 36, (60 * tall_equal_mixer_ht + 204));
+	gtk_widget_set_usize(drawing, 36, (60 * tall_equal_mixer_ht + 202));
 	gtk_box_pack_start(GTK_BOX(vbox1), drawing, FALSE, FALSE, 1);
 
 	label = gtk_label_new("");
@@ -733,9 +739,106 @@
 	gtk_spin_button_set_numeric(GTK_SPIN_BUTTON(spinbutton), TRUE);
 	gtk_signal_connect(GTK_OBJECT(spinbutton_adj), "value_changed",
 			   GTK_SIGNAL_FUNC(volume_change_rate_adj), NULL);
-	
+
+}
+static void create_peak_bars(GtkWidget *box)
+{
+	GtkWidget *frame;
+	GtkWidget *vbox;
+	GtkWidget *vbox1;
+	GtkWidget *hbox;
+	GtkWidget *check;
+	GtkWidget *label;
+	GtkObject *spinbutton_adj;
+	GtkWidget *spinbutton;
+
+
+	frame = gtk_frame_new("Peak Bars");
+	gtk_widget_show(frame);
+	gtk_box_pack_start(GTK_BOX(box), frame, FALSE, FALSE, 0);
+
+	vbox = gtk_vbox_new(FALSE, 0);
+	gtk_widget_show(vbox);
+	gtk_container_add(GTK_CONTAINER(frame), vbox);
+	gtk_container_set_border_width(GTK_CONTAINER(vbox), 6);
+
+	frame = gtk_frame_new("Clip Bar 98%");
+        gtk_widget_show(frame);
+	gtk_box_pack_start(GTK_BOX(vbox), frame, FALSE, FALSE, 0);
+
+	vbox1 = gtk_vbox_new(FALSE, 0);
+	gtk_widget_show(vbox1);
+	gtk_container_add(GTK_CONTAINER(frame), vbox1);
+//	gtk_container_set_border_width(GTK_CONTAINER(vbox1), 0);
+
+	check = gtk_check_button_new_with_label("Active");
+	clip_peaks_check = check;
+	gtk_widget_show(check);
+	gtk_box_pack_start(GTK_BOX(vbox1), check, FALSE, FALSE, 0);
+	gtk_signal_connect(GTK_OBJECT(check), "toggled",
+			  (GtkSignalFunc)peak_bars_toggled,
+			  (gpointer)"clip_peaks");
+
+	check = gtk_check_button_new_with_label("Auto Reset");
+	auto_reset_clips_check = check;
+	gtk_widget_show(check);
+	gtk_box_pack_start(GTK_BOX(vbox1), check, FALSE, FALSE, 0);
+	gtk_signal_connect(GTK_OBJECT(check), "toggled",
+			  (GtkSignalFunc)peak_bars_toggled,
+			  (gpointer)"auto_reset_clip");
+
+	frame = gtk_frame_new("Riding Peaks");
+        gtk_widget_show(frame);
+	gtk_box_pack_start(GTK_BOX(vbox), frame, FALSE, FALSE, 6);
+
+	vbox1 = gtk_vbox_new(FALSE, 0);
+	gtk_widget_show(vbox1);
+	gtk_container_add(GTK_CONTAINER(frame), vbox1);
+
+	check = gtk_check_button_new_with_label("Active");
+	riding_peaks_check = check;
+	gtk_widget_show(check);
+	gtk_box_pack_start(GTK_BOX(vbox1), check, FALSE, FALSE, 0);
+	gtk_toggle_button_set_active(GTK_TOGGLE_BUTTON(check),TRUE);
+	gtk_signal_connect(GTK_OBJECT(check), "toggled",
+			  (GtkSignalFunc)peak_bars_toggled,
+			  (gpointer)"riding_peaks");
+
+	check = gtk_check_button_new_with_label("Auto Reset");
+	auto_reset_riders_check = check;
+	gtk_widget_show(check);
+	gtk_box_pack_start(GTK_BOX(vbox1), check, FALSE, FALSE, 0);
+	gtk_toggle_button_set_active(GTK_TOGGLE_BUTTON(check),TRUE);
+	gtk_signal_connect(GTK_OBJECT(check), "toggled",
+			  (GtkSignalFunc)peak_bars_toggled,
+			  (gpointer)"auto_reset_riders");
+
+	frame = gtk_frame_new("Reset Time");
+        gtk_widget_show(frame);
+	gtk_box_pack_start(GTK_BOX(vbox), frame, FALSE, FALSE, 0);
+
+	hbox = gtk_hbox_new(FALSE, 0);
+	gtk_widget_show(hbox);
+	gtk_container_add(GTK_CONTAINER(frame), hbox);
+	gtk_container_set_border_width(GTK_CONTAINER(hbox), 6);
+
+	label = gtk_label_new("Setting");
+	gtk_widget_show(label);
+	gtk_box_pack_start(GTK_BOX(hbox), label, TRUE, FALSE, 0);
+	gtk_label_set_justify(GTK_LABEL(label), GTK_JUSTIFY_LEFT);
+
+	spinbutton_adj = gtk_adjustment_new(5, 0, 9, 1, 1, 1);
+	sw_peaks_reset_time_adj = spinbutton_adj;
+	spinbutton = gtk_spin_button_new(GTK_ADJUSTMENT(spinbutton_adj), 1, 0);
+	gtk_widget_show(spinbutton);
+	gtk_box_pack_start(GTK_BOX(hbox), spinbutton, TRUE, FALSE, 0);
+	gtk_spin_button_set_numeric(GTK_SPIN_BUTTON(spinbutton), TRUE);
+	gtk_signal_connect(GTK_OBJECT(spinbutton_adj), "value_changed",
+			   GTK_SIGNAL_FUNC(peaks_reset_time_adj), NULL);
+
 }
 
+
 static void create_spdif_output_settings_profi_data(GtkWidget *box)
 {
 	GtkWidget *frame;
@@ -1379,6 +1482,45 @@
 	create_spdif_output_settings(hbox);
 }
 
+static void create_extras(GtkWidget *main, GtkWidget *notebook, int page)
+{
+	GtkWidget *label;
+	GtkWidget *vbox;
+	GtkWidget *hbox;
+	GtkWidget *scrolledwindow;
+	GtkWidget *viewport;
+
+	hbox = gtk_hbox_new(FALSE, 0);
+	gtk_widget_show(hbox);
+	gtk_container_add(GTK_CONTAINER(notebook), hbox);
+
+        label = gtk_label_new("Extras");
+        gtk_widget_show(label);
+	gtk_notebook_set_tab_label(GTK_NOTEBOOK(notebook),
+				   gtk_notebook_get_nth_page(GTK_NOTEBOOK(notebook), page),
+				   label);
+
+//	/* build scrolling area */                         /* Leave in for later */
+//	scrolledwindow = gtk_scrolled_window_new(NULL, NULL);
+//	gtk_widget_show(scrolledwindow);
+//	gtk_box_pack_start(GTK_BOX(hbox), scrolledwindow, TRUE, TRUE, 0);
+//	gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scrolledwindow),
+//					GTK_POLICY_AUTOMATIC, GTK_POLICY_NEVER);
+
+//	viewport = gtk_viewport_new(NULL, NULL);
+//	gtk_widget_show(viewport);
+//	gtk_container_add(GTK_CONTAINER(scrolledwindow), viewport);
+
+
+	vbox = gtk_vbox_new(FALSE, 0);
+	gtk_widget_show(vbox);
+	gtk_box_pack_start(GTK_BOX(hbox), vbox, FALSE, FALSE, 6);
+//	gtk_container_add(GTK_CONTAINER(hbox), vbox);
+//	gtk_container_set_border_width(GTK_CONTAINER(vbox), 6);
+
+	create_peak_bars(vbox);
+}
+
 static void create_about(GtkWidget *main, GtkWidget *notebook, int page)
 {
 	GtkWidget *label;
@@ -1421,7 +1563,7 @@
 	gtk_box_pack_start(GTK_BOX(vbox), label, TRUE, TRUE, 6);
 
 	/* create first line */
-	label = gtk_label_new("Envy24 Control Utility " VERSION);
+	label = gtk_label_new("Envy24 Control Utility v" VERSION "  **AH Peaks/clips mod v1-3.1.06");
         gtk_widget_show(label);
 	gtk_box_pack_start(GTK_BOX(vbox), label, FALSE, TRUE, 6);
 
@@ -1960,9 +2102,9 @@
 	gtk_widget_set_name(drawing, "DigitalMixer");
 	gtk_box_pack_start(GTK_BOX(hbox1), drawing, TRUE, FALSE, 6);
 	if (tall_equal_mixer_ht > 1 ) {
-		gtk_widget_set_usize(drawing, 60, 264 + 60 * (tall_equal_mixer_ht - 1));
+		gtk_widget_set_usize(drawing, 60, 262 + 60 * (tall_equal_mixer_ht - 1));
 	} else {
-		gtk_widget_set_usize(drawing, 60, 264);
+		gtk_widget_set_usize(drawing, 60, 262);
 	}
 	gtk_signal_connect(GTK_OBJECT(drawing), "expose_event",
 			   (GtkSignalFunc)level_meters_expose_event, NULL);
@@ -2285,6 +2427,7 @@
 	create_hardware(outerbox, notebook, page++);
 	if (envy_analog_volume_available())
 		create_analog_volume(outerbox, notebook, page++);
+	create_extras(outerbox, notebook, page++);
 	create_profiles(outerbox, notebook, page++);
 	create_about(outerbox, notebook, page++);
 	create_blank(outerbox, notebook, page++);
Only in Aenvy24control: envy24control.c.orig
diff -ru envy24control/envy24control.h Aenvy24control/envy24control.h
--- envy24control/envy24control.h	2006-08-22 19:25:52.000000000 +0100
+++ Aenvy24control/envy24control.h	2008-07-28 22:52:14.000000000 +0100
@@ -1,4 +1,4 @@
-#include <stdio.h>
+#include <stdio.h>       /*  AH Peaks/clips mod v1 3.1.06   */
 #include <stdlib.h>
 #include <string.h>
 #include <signal.h>
@@ -166,6 +166,8 @@
 gint level_meters_configure_event(GtkWidget *widget, GdkEventConfigure *event);
 gint level_meters_expose_event(GtkWidget *widget, GdkEventExpose *event);
 gint level_meters_timeout_callback(gpointer data);
+void peak_bars_toggled(GtkWidget *togglebutton, gpointer data);
+void peaks_reset_time_adj(GtkAdjustment *adj, gpointer data);
 void level_meters_reset_peaks(GtkButton *button, gpointer data);
 void level_meters_init(void);
 void level_meters_postinit(void);
Only in Aenvy24control: envy24control.h.orig
Only in Aenvy24control: envy24control.o
Only in Aenvy24control: envy24control-orig.c
Only in Aenvy24control: envy24control-orig.h
Only in Aenvy24control: hardware.o
diff -ru envy24control/levelmeters.c Aenvy24control/levelmeters.c
--- envy24control/levelmeters.c	2006-08-22 19:25:52.000000000 +0100
+++ Aenvy24control/levelmeters.c	2008-07-28 23:32:34.000000000 +0100
@@ -1,5 +1,5 @@
 /*****************************************************************************
-   levelmeters.c - Stereo level meters
+   levelmeters.c - Stereo level meters     **AH Peaks/clips mod v1 3.1.06
    Copyright (C) 2000 by Jaroslav Kysela <perex@suse.cz>
    
    This program is free software; you can redistribute it and/or
@@ -30,6 +30,11 @@
 
 extern int input_channels, output_channels, pcm_output_channels, spdif_channels, view_spdif_playback;
 
+	int peaks_store[2][22] = {0};  /* Holds info for clip & riding peaks indicators */
+	int count_time[2][22] = {0};   /* Holds reset time counts for peaks indicators  */
+	int peaks_setup[4] = {0,0,1,1}; /* Correspond to the 4 peak bar check buttons */
+	int time_count_val = 49;  /* Approx 2 secs reset -varied by spinbutton  */
+
 static void update_peak_switch(void)
 {
 	int err;
@@ -38,6 +43,11 @@
 		g_print("Unable to read peaks: %s\n", snd_strerror(err));
 }
 
+static int is_active(GtkWidget *widget)
+{
+	return GTK_TOGGLE_BUTTON(widget)->active ? 1 : 0;
+}
+
 static void get_levels(int idx, int *l1, int *l2)
 {
 	*l1 = *l2 = 0;
@@ -87,9 +97,10 @@
 	int green_segments = (segments / 4) * 3;
 	int red_segments = 2;
 	int orange_segments = segments - green_segments - red_segments;
-	int seg;
+	int seg, peak;
 	int segs_on1 = ((segments * level1) + 128) / 255;
 	int segs_on2 = ((segments * level2) + 128) / 255;
+	const short int clip_level = 250;
 
 	// g_print("segs_on1 = %i (%i), segs_on2 = %i (%i)\n", segs_on1, level1, segs_on2, level2);
 	for (seg = 0; seg < green_segments; seg++) {
@@ -146,6 +157,73 @@
 		segs_on1--;
 		segs_on2--;
 	}
+
+	if (peaks_setup[2]) { /* Draw rising peak segments */
+		peak = peaks_store[1][idx];
+		seg = ((segments * peak) + 128) / 255;
+		if (peak > level1) {
+			if (seg >= 1) {
+				gdk_draw_rectangle(pixmap[idx],
+						   penOrangeLight[idx],
+						   TRUE,
+						   6 , 3 + ((segments - seg ) * 4),
+						   (segment_width / 2),
+						   3);
+			}
+		} else {
+			peaks_store[1][idx] = level1;
+			count_time[1][idx] = 0;
+		}
+		if (stereo) { /* Draw right channel of Dig mixer, use [21] */
+			peak = peaks_store[1][21];
+			seg = ((segments * peak) + 128) / 255;
+			if (peak > level2) {
+				if (seg >= 1) {
+					gdk_draw_rectangle(pixmap[idx],
+							   penOrangeLight[idx],
+							   TRUE,
+							   2 + (width / 2),
+							   3 + ((segments - seg ) * 4),
+							   (segment_width / 2),
+							   3);
+				}
+			} else {
+				peaks_store[1][21] = level2;
+				count_time[1][21] = 0;
+			}
+		}
+	}
+
+	if (peaks_setup[0]) { /* Draw clip peak segments */
+		if (level1 >= clip_level) {
+			peaks_store[0][idx] = 1;
+			count_time[0][idx] = 0;
+		} else {
+			if (peaks_store[0][idx] > 0)  /* Previous peak */
+				gdk_draw_rectangle(pixmap[idx],
+						   penRedLight[idx],
+						   TRUE,
+						   6 + (segment_width / 2), 3,
+						   (segment_width / 2),
+						   3);
+		}
+
+		if (stereo) { /* Draw right channel of Dig mixer, use [21] */
+			if (level2 >= clip_level) {
+				peaks_store[0][21] = 1;
+				count_time[0][21] = 0;
+			} else {
+				if (peaks_store[0][21] > 0)  /* Previous peak */
+					gdk_draw_rectangle(pixmap[idx],
+							   penRedLight[idx],
+							   TRUE,
+							   2 + (width / 2) + (segment_width / 2), 3,
+							   (segment_width / 2),
+							   3);
+			}
+		}
+	}
+
 }
 
 gint level_meters_configure_event(GtkWidget *widget, GdkEventConfigure *event)
@@ -163,7 +241,7 @@
 	penOrangeShadow[idx] = get_pen(idx, 0xddff, 0x55ff, 0);
 	penOrangeLight[idx] = get_pen(idx, 0xffff, 0x99ff, 0);
 	penRedShadow[idx] = get_pen(idx, 0xaaff, 0, 0);
-	penRedLight[idx] = get_pen(idx, 0xffff, 0, 0);
+	penRedLight[idx] = get_pen(idx, 0xffff, 0x2fff, 0x2fff);
 	gdk_draw_rectangle(pixmap[idx],
 			   widget->style->black_gc,
 			   TRUE,
@@ -252,11 +330,83 @@
 					widget->allocation.width, widget->allocation.height);
 		}
 	}
+
+	for (idx = 0; idx<= 21; idx++) { /* Auto-reset the peak bars */
+		if (peaks_setup[1]) { /* Clip bars */
+			count_time[0][idx]++;
+//			g_print("A/R clips");
+			if (count_time[0][idx] > time_count_val*2) {
+				peaks_store[0][idx] = 0;
+				count_time[0][idx] = 0;
+			}
+		}
+		if (peaks_setup[3]) { /* Riding peaks */
+			count_time[1][idx]++;
+//			g_print("ST %i",slow_time);
+			if (count_time[1][idx] > time_count_val) {
+				peaks_store[1][idx] = 0;
+				count_time[1][idx] = 0;
+			}
+		}
+	}
 	return TRUE;
 }
 
+void peak_bars_toggled(GtkWidget *togglebutton, gpointer data)
+{
+	char *what = (char *) data;
+
+	if (!strcmp(what, "clip_peaks")) {
+		if (is_active(togglebutton))
+			peaks_setup[0] = 1;
+		else
+			peaks_setup[0] = 0;
+	} else if (!strcmp(what, "auto_reset_clip")) {
+		if (is_active(togglebutton))
+			peaks_setup[1] = 1;
+		else
+			peaks_setup[1] = 0;
+	} else if (!strcmp(what, "riding_peaks")) {
+		if (is_active(togglebutton))
+			peaks_setup[2] = 1;
+		else
+			peaks_setup[2] = 0;
+	} else if (!strcmp(what, "auto_reset_riders")) {
+		if (is_active(togglebutton))
+			peaks_setup[3] = 1;
+		else
+			peaks_setup[3] = 0;
+	} else {
+		g_print("peak_bars_toggled: %s ???\n", what);
+	}
+
+}
+
+void peaks_reset_time_adj(GtkAdjustment *adj, gpointer data)
+{
+	int val, idx;
+
+	val = adj->value;
+	time_count_val = 9;
+	for (idx = 0; idx < val; idx++)
+		time_count_val = time_count_val * 1.442; /* Create a time count in a non-linear series, approx 2^n */
+//	g_print(" Val %i", val);
+//	g_print(" Time count val %i.", time_count_val);
+}
+
+
+
 void level_meters_reset_peaks(GtkButton *button, gpointer data)
 {
+	int idx;
+
+	for (idx = 0; idx <= 21; idx++) {
+		peaks_store[0][idx] = 0;
+		peaks_store[1][idx] = 0;
+		count_time[0][idx] = 0;
+		count_time[1][idx] = 0;
+	}
+//	g_print("Reset");
 }
 
 void level_meters_init(void)

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[Raymond Yau]

2010/7/13 Alan Horstmann <gineera@aspect135.co.uk>

> Hi Neils,
>
> On Monday 12 July 2010 23:41, Niels Mayer wrote:
> > I've been long annoyed by alsa-tools' envy24control (*) lack of
> > peak-level indication in it's metering, and the non-implementation of
> > its "Reset Peaks" button:
> > https://bugzilla.redhat.com/show_bug.cgi?id=602903
> >
> > I've fixed that annoyance. Now, a small white line appears above the
> > highest level on each meter, and can be reset via "Reset Peaks"
> > button.
> >
> > Original source:
> >
> http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=envy24control/
> >levelmeters.c;hb=HEAD Patch:
> > http://nielsmayer.com/npm/602903.patch
>
>
Seem "Peak Hold" button (e.g  japa or jaaa ) may be better than "Reset
Peaks" button

Re: [LAD] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[Niels Mayer]

On Tue, Jul 13, 2010 at 1:19 AM,  <fons@kokkinizita.net> wrote:
>On Mon, Jul 12, 2010 at 06:18:29PM -0700, Niels Mayer wrote:
>> Speaking of making my brain hurt -- I really would not have done the
>> meters as done in envy24control. I really hate the concept of
>> emulating the look of real gear down to the level that you have to
>> "quantize" to individual LED's...
>
> That is indeed quite absurd.

Yes, the meters in envy24control --
http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=envy24control/levelmeters.c;hb=HEAD
-- are absurd! What's even more absurd, is to have the benefits of the
ice1712's hardware metering squandered by drawing thousands of
rectangles per second (each individual "LED" on each meter is a
separate x draw-rectangle call). The existing envy24control meters are
an abomination of inefficiency! Especially when used with a remote X
display.

As a second patch (coming soon), I've rewritten  the meters in a more
sensible fashion, drawing a single rectangle to represent the
instantaneous level (2-3 X-primitive draws per meter total and one
blit, versus hundreds of draws and a blit per value change per meter
in the original code). I'm also being a little more careful about not
needing to redraw the entire meter for each change -- using the
monotonicity of the audio signal being represented to optimize the way
you draw it; not redrawing if nothing has changed, etc.

And since the hardware metering already quantizes to 256 levels --
there's no point in re-quantizing those to individual "virtual LEDs"
as is done w/ the current envy24control.

The result so far are promising: Here's 'top' output (*) using the new
envy24control. Note the load is lower, and 'envy24control' and 'X'
both use much less CPU. In fact running this meter lowers the system
load. whereas running the old envy24control raises it (and makes the
fans run faster!).

 top - 21:30:13 up 11:30,  9 users,  load average: 0.02, 0.11, 0.06
 2664 root      20   0  544m 134m  34m S  2.6  3.4  26:03.51 X
 9404 npm       20   0  192m 9340 6908 S  0.7  0.2   0:01.72
envy24control

The new metering gives 2.6% CPU for X, and 0.7% CPU for the
new-metered envy24control; Versus 6.3% CPU for X and 2.7% for the old
metering in envy24control (the one from my first patch):

 top - 21:25:57 up 11:25,  9 users,  load average: 0.10, 0.09, 0.03
 2664 root      20   0  544m 134m  34m S  6.3  3.4  25:50.67 X
 9398 npm       20   0  192m 9368 6940 S  2.7  0.2   0:16.81 envy24control

Now granted this is not a scientific test, and "top" is not exactly
the best way to gauge performance. But it does suggest that the
computational complexity caused by the bad metering algorithm directly
translates to higher-power consumption, higher loads, and poorer
performance.

Compared to the existing envy24control metering -- It would probably
me more efficient to actually compute RMS levels off the audio stream
-- or even hook up jkmeter through jack -- instead of using the
hardware metering data through these computationally wasteful level
meters.

-- Niels
http://nielsmayer.com

Re: [LAD] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[fons-5YXofNvN5bf4jJi9/k9gcg]

On Tue, Jul 13, 2010 at 09:54:58PM -0700, Niels Mayer wrote:

>  What's even more absurd, is to have the benefits of the
> ice1712's hardware metering squandered by drawing thousands of
> rectangles per second (each individual "LED" on each meter is a
> separate x draw-rectangle call).

It should at least use the XDrawRectangles(), which draws a list
of them in a single call.

> And since the hardware metering already quantizes to 256 levels --
> there's no point in re-quantizing those to individual "virtual LEDs"
> as is done w/ the current envy24control.

Depends. A linear mapping is not really the best you can do.

Ciao,

-- 
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[Niels Mayer]

On Tue, Jul 13, 2010 at 9:54 PM, Niels Mayer <nielsmayer@gmail.com> wrote:
> As a second patch (coming soon), I've rewritten  the meters in a more
> sensible fashion, drawing a single rectangle to represent the
> instantaneous level (2-3 X-primitive draws per meter total and one
> blit, versus hundreds of draws and a blit per value change per meter
> in the original code).

Patch for https://bugzilla.redhat.com/show_bug.cgi?id=602903
(see also http://old.nabble.com/FIxed-alsa-tools'-envy24control-missing-peak-level-meters-and-"Reset-Peaks"-ts29144830.html
)

(1) http://nielsmayer.com/npm/Screenshot-Efficient-Meters-Envy24Control.png
 * To see what the new meters look like.
(2) http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.tgz
 * Contains levelmeters.c and x86_64 binary 'envy24control' that should at
   least work on Fedora 12 and OpenSuse and other 2.6.32-based distros.
(3) http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.patch
 * To apply the patch, grab the most recent stable release (
   ftp://ftp.alsa-project.org/pub/tools/alsa-tools-1.0.23.tar.bz2 ) or
   git pull from trunk of the "alsa-tools" project.
 * After unpacking and assuming you've got the patch in
   ~/Efficient-Meters-Envy24Control.patch.patch do:
   >> cd alsa-tools-1.0.23
   >> cat ~/Efficient-Meters-Envy24Control.patch | patch -p1
  * It should give message "patching file envy24control/levelmeters.c"
  * Follow the directions to compile alsa-tools.

FYI here's what my "top" processes look like when running a test to
output individual streams to all 10 PCM output channels -- note X
consumes between "1.7%" to "2.0 %" and "envy24control" "0.7%" to
"1.0%":

15210 npm       20   0  643m  14m 8964 S  6.6  0.4   0:05.85 gst123
15184 npm       20   0  643m  14m 8984 S  6.3  0.4   0:13.11 gst123
15190 npm       20   0  643m  14m 8980 S  6.0  0.4   0:12.48 gst123
15172 npm       20   0  643m  14m 8968 S  5.6  0.4   0:15.42 gst123
15178 npm       20   0  643m  14m 8984 S  5.6  0.4   0:14.17 gst123
13684 root      20   0  527m 112m  31m S  2.0  2.8   3:26.11 X
13923 npm       20   0  863m  60m  37m S  1.0  1.5   2:49.08 plasma-desktop
14163 npm       20   0  597m  27m  15m S  1.0  0.7   1:08.29 chrome
14155 npm       20   0 1038m 170m  14m S  0.7  4.3   1:00.87 chrome
15226 npm       20   0  192m 9316 6908 S  0.7  0.2   0:00.51 envy24control

Here's the envy24control from my first patch, using the original
meters that cause many separate XDrawRectangles for each LED-looking
segment. The performance difference is quite noticeable as the fans
start running louder and the system load climbs upwards as soon as the
original envy24control starts running: X consumes 5.7-10% CPU, and
envy24control between 2.0% and 2.7%.

15172 npm       20   0  643m  14m 8968 S  6.1  0.4   0:53.83 gst123
15178 npm       20   0  643m  14m 8984 S  6.1  0.4   0:51.48 gst123
15190 npm       20   0  643m  14m 8980 S  6.1  0.4   0:49.60 gst123
15210 npm       20   0  643m  14m 8964 S  6.1  0.4   0:44.01 gst123
13684 root      20   0  527m 112m  31m S  5.7  2.8   3:42.78 X
15184 npm       20   0  643m  14m 8984 S  5.7  0.4   0:51.07 gst123
15398 npm       20   0  192m 9332 6908 S  2.4  0.2   0:02.32
envy24control.f
14163 npm       20   0  597m  27m  15m S  1.0  0.7   1:15.54 chrome
13923 npm       20   0  863m  60m  37m S  0.6  1.5   2:55.04
plasma-desktop

Just to show that it's the same performance as the original
envy24control from alsa-tools-1.0.22-1.1.fc12.ccrma.x86_64:

15178 npm       20   0  643m  14m 8984 S  6.3  0.4   1:28.72 gst123
15190 npm       20   0  643m  14m 8980 S  6.3  0.4   1:26.65 gst123
15210 npm       20   0  643m  14m 8964 S  6.3  0.4   1:20.59 gst123
15184 npm       20   0  643m  14m 8984 S  6.0  0.4   1:28.21 gst123
13684 root      20   0  527m 112m  31m R  5.6  2.8   4:21.30 X
15172 npm       20   0  643m  14m 8968 S  5.6  0.4   1:31.51 gst123
15455 npm       20   0  192m 8700 6316 S  2.3  0.2   0:01.74
envy24control
14163 npm       20   0  597m  27m  15m S  1.3  0.7   1:23.02 chrome
13923 npm       20   0  863m  60m  37m S  0.7  1.5   3:00.72 plasma-desktop

-- Niels
http://nielsmayer.com
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [LAD] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[Niels Mayer]

On Tue, Jul 13, 2010 at 3:46 PM, Tim E. Real <termtech@rogers.com> wrote:
> But nothing was ever done about the slider markings.
> Having them go from 0 to 164 is not really helpful.
> It's not clear where the 0dB mark is.
> At the very least a 0dB mark should be added.
> Uh, do you feel like taking a stab at this?
> IIRC it would be a bit tricky because you have to look up
>  the corresponding values in the IC data sheets, I think.

This makes sense... I was thinking of a simple ruler with a 0dB label
at 127 and a + dB label  above and a - dB label below.

Some thoughts on further usability improvements to envy24control:

(1)  In "alsamixer" the snd-ice1712-card's input levels are
represented by (versus envy24control's value):
100% (163) -> ADC [dB gain: 18.00]
78%   (127) -> ADC [dB gain: 0.00]
1%     (001) -> ADC [dB gain: -63.00]
0%    (000) -> ADC [dB gain: mute]
Mixers like envy24control, kmix, alsamixergui, gst-mixer, etc, are a
lot less useful than they could be because they just present sliders.
At least envy24control gives numeric values,  -- which is essential if
you want to know stereo channels are balenced, or what unity-gain
levels are for inputs.

In "alsamixer", the snd-ice1712-card's output levels are represented
by (versus envy24control value):
100%  (127)  -> DAC [dB gain: 0.00]
1%      (001)  -> DAC [dB gain: -63.00]
0%      (000) -> DAC [dB gain: mute]

As this is a separate issue from the meters, it makes sense to do the
changes to the "Analog Volume" panel of envy24control as a separate
patch.

(2) The "0-96" sliders, feeding the digital mixer, need better
labeling and mappings too: The "96" actually being "-96dB" and only
valid for 16 bit depths. On the other hand, alsamixer is showing the
24 bit dB values, even when 16 bits are being used:

100% (0)  -> H/W Multi [dB gain: 0.00, ...]
1%    (95) -> H/W Multi [dB gain: -142.50,...]
0%    (96) -> H/W Multi [dB gain: -144.00,...]

Worse than the labelling, but associated -- the scaling: Right now the
digital mixer's input sliders all have linear response -- which wastes
the lower half of the slider and makes setting levels difficult
because all the "action" is near the top. If you use an external MIDI
controller for the mixer, you can use this existing option:
	-M, --midienhanced	Use an enhanced mapping from midi controller to db slider
However this does not apply to the GUI controller, which stays linear.

Clearly the GUIs digital mixer controls also need a logarithmic scale
(perhaps as default settings); matching that, each mixer input's
meters also need to have their scale expressed "logarithmically" so as
to provide, for example 50% of the display resolution for 0 to -20dB,
and remaining 50% for -20dB to -96dB/-144dB.

Alongside the numbers indicating the 0 to -96db L or R gain on each
mixer input channel, I would also add the current  peak value held in
the meters in dB, which would be based on hardware metering level
"0xFF" representing 0db, and hardware meter level "0x01" representing
all but the last of the 9 MSB's being 0 (per
http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf: "Peak data
derived from the absolute value of 9 msb. 00h * min - FFh max volume.
Reading the register resets the meter to 00h."

Other missing features:

(3) Due to the hardware metering employed by envy24control, the peak
meters don't actually detect "clipping" ; rather, they just detect
"full scale" as 255. Is there a hardware clipped indicator on the
ice1712? It doesn't make sense to turn on a big red "clipped" light
for 0dB output, so the current peak-meters are "subtle," and just
indicate that a peak occurred at the given level... And color-code the
peak towards red as it reaches 255.

(4) The "IEC958 Input Status" isn't presented, even though it's
available and working, e.g from the command-line,. with SPDIF input
going to the Delta66 soundcard:
.....
gnulem-176-~> amixer -c M66 cget numid=50,iface=MIXER,name='Delta
IEC958 Input Status'
numid=50,iface=MIXER,name='Delta IEC958 Input Status'
  ; type=BOOLEAN,access=r-------,values=1
  : values=on
.....
And without any SPDIF input:
.....
gnulem-177-~> amixer -c M66 cget numid=50,iface=MIXER,name='Delta
IEC958 Input Status'
numid=50,iface=MIXER,name='Delta IEC958 Input Status'
  ; type=BOOLEAN,access=r-------,values=1
  : values=off

Perhaps this isn't available in envy24control because it has differing
levels of support across envy24-based cards? I only have a Delta66's
and a Terratec  Dmx6Fire 24/96 for testing, and both support the SPDIF
input status.

-- Niels
http://nielsmayer.com

PS: ALSA tip of the day. To read ice1712's hardware level-meter values
from the command line:
"amixer -c M66 cget iface=PCM,name='Multi Track Peak',numid=45"
  type=INTEGER,access=r-------,values=22,min=0,max=255,step=0
: values=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,198,255,198
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [LAD] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[Geoff King]

On Thu, Jul 15, 2010 at 9:14 PM, Niels Mayer <nielsmayer@gmail.com> wrote:
> On Tue, Jul 13, 2010 at 9:54 PM, Niels Mayer <nielsmayer@gmail.com> wrote:
>> As a second patch (coming soon), I've rewritten  the meters in a more
>> sensible fashion, drawing a single rectangle to represent the
>> instantaneous level (2-3 X-primitive draws per meter total and one
>> blit, versus hundreds of draws and a blit per value change per meter
>> in the original code).
>

Niels, Thank you for taking the time to work on improving Envy24Ctl.
I tried your patch for the peaks and it seemed to work fine for me.  I
can't comment on the code (as I'm much more musician than programmer),
but had no problem patching and installing.  Looking forward to trying
this new patch and whatever else you come up with. Geoff

_______________________________________________
PlanetCCRMA mailing list
PlanetCCRMA@ccrma.stanford.edu
http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma

Re: [LAD] [PlanetCCRMA] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[Niels Mayer]

On Fri, Jul 16, 2010 at 5:27 AM, Geoff King <gsking1@gmail.com> wrote:
> Niels, Thank you for taking the time to work on improving Envy24Ctl.
> I tried your patch for the peaks and it seemed to work fine for me.  I
> can't comment on the code (as I'm much more musician than programmer),
> but had no problem patching and installing.  Looking forward to trying
> this new patch and whatever else you come up with. Geoff

Geoff -- thank you for trying out the patch! (And, OT,  thanks for
working w/ Rui to help fix
http://sourceforge.net/tracker/?func=detail&atid=733076&aid=3021645&group_id=135501
:: "help fix qtractor crash on bus changing/configuration (3021645)" --
Envy24 and multichannel qtractor users, yes, it's time for a "svn up" ).

FYI, to try out the new levelmeters "easy", if you're running Fedora
x86_64, use the "envy24control" binary directly, or drop the
levelmeters.c file into your build:
http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.tgz
( for details http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.README )

........

On a completely different "note"  the envy 24 manual (
http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf )
has interesting info on the envy24 digital mixer that I've snapshotted:

Diagram: http://nielsmayer.com/npm/envy24mixer-architecture.png

Note the way it truncates in the mixer: the more inputs you "mix" at
once, the fewer bits each input source gets, and it's not clear what
kind of dither, or it's a straight truncate of 24... ultimately the
envy24 seems oriented towards producing a 16 bit, and not 24 bit
master (which makes sense given that the chip is well over a decade
old and HD audio production for "prosumer" was rare):
..........
4.5.5 Multi-Track Digital Monitoring
The Envy24 integrates a 36-bit resolution digital hardware mixer. The
width of the data path is strictly to
ensure that during processing of all the channels, under any
condition, no resolution is lost. The dynamic range
of the end user system will be limited by the range of the physical
output devices used. In order to maintain
identical gain to the input stream (i.e. 0dB), the resulting 24-bit is
not msb-aligned to the 36-bit. The overflow
bits correspond to the analog distortion due to saturation. The user
would need to reduce the overall attenuation
of the inputs to avoid clipping. Insertion of the digital mixer adds
only a single sample cycle delay with respect
to the original data. This extremely low latency all digital mixer
provides monitoring functionality and can
replace a traditional external analog input mixer. There are 20
independent audio data streams to mix and
control the volume. ...
..............

--Niels
http://nielsmayer.com
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev