On July 26, 2010 09:07:35 pm you wrote:
On Mon, Jul 26, 2010 at 12:29 AM, Tim E. Real
<termtech(a)rogers.com> wrote:
trust me it will look great at the expense of
only 28 extra pixels for
the minimum height over the original - it's all you can really do, man:
Remove the -72 and -108 dB marks on all the monitor sliders
in volume.c: draw_24bit_attenuator_scale_markings().
Remove the -42 and -54 dB marks from the DAC sliders in
volume.c: draw_dac_scale_markings().
Remove the -18, -30, -42, -54, -60 dB markings from the ADC
sliders in volume.c:draw_adc_scale_markings().
Change the level meter heights by changing
gtk_widget_set_usize(drawing, 24, (60 * tall_equal_mixer_ht + 204));
to
gtk_widget_set_usize(drawing, 24, (60 * tall_equal_mixer_ht + 168));
in envy24control.c: create_mixer_frame().
Trust me they'll love it !
Thanks! Yes, it does look better. I've applied these suggestions to my
current sources and they'll be part of an upcoming release that
addresses the issues...
If you have any suggestions on getting rid of the annoying
detent/hysteresis as you move the sliders past the markings, that
would be great.
-- Niels.
http://nielsmayer.com
Sure, NP I'll take a look.
Good news!
As I mentioned in a follow-up to another thread, I found a bunch
more dB related functions.
I tested replacing the code in volume.c:dac_volume_to_db() and
adc_volume_to_db() with a call to ALSA's snd_ctl_convert_to_dB().
The results are identical! And better for ADC compatibility, right?
Now comes the fun part. Coming up with an Al-Gore-rithm to
handle the scale markings using these ALSA functions -
how many 6dB steps we have, which ones to display, the range, etc.
It occurred to me 'dynamic markings': If the user expands
more, or less, vertically, then more, or less, markings should appear.
But it's still tricky - we want it to look the way I suggested above,
with more markings concentrated around the 0dB point, whenever
we are forced to compromise by removing marks.
Ultimately, at minimum height it must look like that - it's a compromise,
until a (better) solution comes up.
Also I see there is something called TLV based dB conversion where
I think it's a table or can be an arbitrary function. Must study more.
------------
For now here's the code, throw it inside
dac_volume_to_db() and
adc_volume_to_db() but *replace* DAC_VOLUME_NAME with ADC_VOLUME_NAME,
and I believe mixer_volume_to_db() and wherever else required.
Do you need a patch?
Hope this is OK, not sure how many members to set in struct snd_ctl_elem_id.
List members, does it look OK?
char* dac_volume_to_db(int ival) {
if (ival != 0) {
// Use ALSA functions to get dB values.
long db_gain = 0;
float fval;
snd_ctl_elem_id_t *elem_id;
snd_ctl_elem_id_alloca(&elem_id);
snd_ctl_elem_id_clear(elem_id);
snd_ctl_elem_id_set_interface(elem_id, SND_CTL_ELEM_IFACE_MIXER);
snd_ctl_elem_id_set_name(elem_id, DAC_VOLUME_NAME);
snd_ctl_convert_to_dB(ctl, elem_id, ival, &db_gain);
fval = ((float)db_gain / 100.0);
sprintf(temp_label, "%+2.1f", fval);
return (temp_label) ;
}
else
{
// Rest of function ('off' part). ]
...
Tim.