linuxaudio.org

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

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

Yep.

> They now go down to only -48dB instead of -144dB.

quoted text
> 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'?

quoted text
> 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.

quoted text
> 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

quoted text
>  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...
 -----

quoted text
> 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

quoted text
>  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

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev