4 Aug
2010
4 Aug
'10
11:01 p.m.
On Wed, Aug 4, 2010 at 12:00 PM, Tim E. Real <termtech(a)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