On Wed, Aug 4, 2010 at 12:00 PM, Tim E. Real termtech@rogers.com wrote:

Something odd. Are you sure about those digital mixer ranges?

Yep.

They now go down to only -48dB instead of -144dB. Seems like 2/3 of the range is missing?

Truncated. At least for my purposes, the original faders w/ 144dB dynamic range and linear mapping on the controls made the "business end" of the gain -- the top 20-30dB -- occur over far to few pixels to be controllable via mouse. At the same time the meters themselves go down to -48dB and there is the whole confusion about the scale-markings on the analog sliders versus the meters. Now there's none. And the "top end" of the slider is now more easily controllable by mouse. The MIDI control and other more fine-grained control (e.g. via , e.g. alsamixer-qt4, alsamixer, or other programs) is not affected.

In this new 'mudita24' interface, the input is set "off" when then digital mixer input attenuator is moved below -48dB, but not via MIDI or other external control. Therefore if someone actually needs to mix an input at -48dB or lower, they can still use the MIDI controllers or a different mixer like alsamixer-qt4 to set those kind of levels. This seemed like a better compromise than wasting more than half the slider real-estate to changes that can't even be heard (unless you've got the volume turned way up).

If this is particularly bothersome please let me know and I guess I'll add an option to give the full 0 to -144dB range back. However, if you're doing that kind of mixing, perhaps using a different mixer than the envy24's hardware mixer is more appropriate?

Also, the 'active' colour of the meters seems way too 'soft'? Seems like just a slightly darker grey shade than the meter  background (although I know it's supposed to be blue).

Yes, I see that this is very skin dependent and what is working for me isn't working for others. (Could you send a picture to show me what the coloration of your meters ends up like on your system?)

Any suggestions on using a different built-in color so as to not worry about contrast or visibility issues?

This makes it very hard to see the meters in action. A lighter shade of blue would make it look nice like a flourescent type of display.

Is there a known standard gnone name that can be applied to the foreground color? Alternately, how about options --meterfg and ---meterbg that allow you to specify the colors?

Also, sorry about this, I missed something in the ALSA dB reading  code I submitted: The index of the control:

In volume.c: dac_volume_adjust() and adc_volume_adjust(),  remove the clear() and set an index like this:

snd_ctl_elem_id_t *elem_id;          snd_ctl_elem_id_alloca(&elem_id);          //snd_ctl_elem_id_clear(elem_id); // TER: Removed          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_elem_id_set_index(elem_id, idx); // TER: Added          long db_gain = 0;

And in mixer.c: mixer_volume_to_db()  remove the clear() and set an index:

snd_ctl_elem_id_t *elem_id;    snd_ctl_elem_id_alloca(&elem_id);    //snd_ctl_elem_id_clear(elem_id); // TER: Removed    snd_ctl_elem_id_set_interface(elem_id, SND_CTL_ELEM_IFACE_MIXER);

/* IEC958_MULTI_CAPTURE_VOLUME, for stream=19 or 20 gives incorrect       results, use HW_MULTI_CAPTURE_VOLUME for all */    // Verified by TER. Those two controls have no dB values, but they should,    //   they're just part of the same mixer !    //  snd_ctl_elem_id_set_name(elem_id, (stream <= 10) ?    //   MULTI_PLAYBACK_VOLUME : (stream <= 18 ? HW_MULTI_CAPTURE_VOLUME :    //   IEC958_MULTI_CAPTURE_VOLUME));    snd_ctl_elem_id_set_name(elem_id, (stream <= 10) ? MULTI_PLAYBACK_VOLUME :       HW_MULTI_CAPTURE_VOLUME);

// TER: First line is 'proper' way, but second line is corrected    //   workaround for lack of dB values for IEC958 controls.    //snd_ctl_elem_id_set_index(elem_id, stream <= 18 ? (stream - 1) % 10 :    //   (stream - 1) % 18 );    snd_ctl_elem_id_set_index(elem_id, stream <= 18 ? (stream - 1) % 10 : 0 );

I'll have to look into this one... seems like a 1.0.2 is inevitable...

-----

With the ice1712 digital mixer, it is not so crucial that we pay attention to  what ALSA tells us about those controls. Setting an index with snd_ctl_elem_id_set_index() is not crucial. After all, this app is specifically for ice1712 and nothing else, so we know  that it's always going to be an ice1712 chip, so we can take advantage  of this, and 'hard-code' the digital mixer scale markings and other things. The ADC/DAC section however, is a different matter. Here is where we must pay attention to ALSA because we don't know  what kind of codec chips may be used. We can't even assume that all controls in a group have the same range so  to be safe we must use snd_ctl_elem_id_set_index(). Granted, envy24control does use some card-specific code for some tricks,  but to support new cards with yet-unknown codecs, we must trust ALSA. If we wanted utmost dB accuracy, we'd have to use card-specific code for  the AK4524 chip for example, due to the broken ALSA TLV functionality,  as Clements mentioned in another thread. These are the approaches I'm using in my re-work of the scales and page snaps.

We're all looking forward to these improvements.

And finally, a reminder (also to myself) to try to avoid using newer gtk  functions because this app is 'supposed' to be able to built with gtk-1. Those 'built-in' GtkScale marker functions are new since 2.16, and likely the  app could not be built with gtk-1. I guess bumping up to a minimum of gtk+-2.0 might be OK though,  as it is the year 2010... Anyone still using gtk+-1.x ?

I think it makes sense to update the minimum to gtk+-2.0 .. I'm not sure what the ALSA folk think.

Also my use of gtk_label_set_markup() is another one of these newer functions.

-- Niels. http://nielsmayer.com