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

From: Niels Mayer <nielsmayer@email-addr-hidden>
Date: Tue Jul 27 2010 - 08:00:31 EEST

On Mon, Jul 26, 2010 at 5:15 PM, Tim E. Real <termtech@rogers.com> wrote:
> On July 16, 2010 10:10:48 pm Tim E. Real wrote:
>> > Here we go!   snd_mixer_selem_get_playback_dB(  )
>> >
>> > Problem solved? Accurate or not?
> Not accurate with AK4524 chip. Read on...
[...]
> Yikes! It's all coming back to me now, this can of worms.
> In my case the Delta101LT card has the AK4524 ADCs.
> The dB step of the IPGA stage is constant at 0.5dB, but the
>  dB step of the DATT stage is not - anywhere from 6dB to 0.28dB !
> And remember the IPGA and DATT controls were combined, complicating things.
> Meanwhile, other AK chips' DATT stages are constant step.

So does this mean 'alsamixer' has a bug for those card models with
combined IPGA? Which would that be?

Note the code in 'alsamixer' which prints out dB-values -- is this
correct or not?

alsa-utils-1.0.23/alsamixer/mixer_display.c :
        ... if (control->flags & (TYPE_PVOLUME | TYPE_CVOLUME)) {
                int (*get_vol_func)(snd_mixer_elem_t *, snd_mixer_selem_channel_id_t, long *);

                if (control->flags & TYPE_PVOLUME)
                        get_vol_func = snd_mixer_selem_get_playback_dB;
                else
                        get_vol_func = snd_mixer_selem_get_capture_dB;
                if (!(control->flags & HAS_VOLUME_1)) {
                        err = get_vol_func(control->elem, control->volume_channels[0], &db);
                        if (err >= 0) {
                                dbs = format_gain(db);
                                value_info = casprintf(" [%s %s]", _("dB gain:"), dbs);
                                free(dbs);
                        }
                } else {
                        err = get_vol_func(control->elem, control->volume_channels[0], &db);
                        if (err >= 0)
                                err = get_vol_func(control->elem, control->volume_channels[1], &db2);
                        if (err >= 0) {
                                dbs = format_gain(db);
                                dbs2 = format_gain(db2);
                                value_info = casprintf(_(" [%s %s, %s]"), _("dB gain:"), dbs, dbs2);
                                free(dbs);
                                free(dbs2);
                        }
                }
        }

> ----------------
> Hey look what I found: A bunch of other dB related funcs like:
>
> snd_mixer_selem_get_playback_dB_range (snd_mixer_elem_t *elem,
>  long *min, long *max)
> "Get range in dB for playback volume of a mixer simple element. "
>
> Now, this would certainly help with markings - if the dB step were constant.
> We would know by the number of integer steps where the 0dB point was etc.
>
> But even better, look at this one! :
>
> snd_mixer_selem_ask_playback_vol_dB (snd_mixer_elem_t *elem, long value,
>  long *dBvalue)
> "Return corresponding dB value to an integer playback volume for a
>  mixer simple element. "
>
> The thing is, for the AK4524, ALSA reports only a single constant
>  step of 0.5, and says the minimum is -63.5dB, with 163 integer steps
>  and a max of +18.5dB.
> It does kinda sorta all work out, but in a average step sort of way...
> ALSA would need to use a dB table (exists?) to be accurate here.
>
> So, we're basing our scales on somewhat dubious info.
> But no doubt these dB functions should be very helpful in drawing
>  scales for all ADC chips on ice1712 cards, no?
>
> The "impossible" is possible?
>
> Hope this helps. Tim.

Either that or make the scales optional and document them as being
potentially inaccurate in the manual page :-). Or just get rid of them
as more trouble than they're worth -- which might be the reason it
didn't have scales prior to my modification :-).

The fundamental "scale" that we most need to be concerned about is
"127" representing unity gain on the ADC. Is that at least constant
across devices in the ice1712 family? I initially thought I'd do that,
but then got carried away once I realized how much space it was
wasting just to mark 0dB and (off).

Any examples of this inaccuracy in action? As in the new 'envycontrol'
returned value, versus 'alsamixer', versus what it is supposed to be?
I thought that we could at least identify any that might be wildly out
of range by comparing against 'alsamixer' or 'amixer' values. But now
I'm wondering if those
are reliable given what you mentioned.

Given the fininte # of ADC/DACs and finite# of device models affected
by this, one could also decide to not get overly theoretical about
this and code-in any special values for specific card models that
aren't behaving properly. I'll look into your ALSA API findings as
well.

Comments?

-- Niels
http://nielsmayer.com
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jul 27 08:15:04 2010

This archive was generated by hypermail 2.1.8 : Tue Jul 27 2010 - 08:15:04 EEST