Hi Niels.
Something odd. Are you sure about those digital mixer ranges?
They now go down to only -48dB instead of -144dB.
Seems like 2/3 of the range is missing?
Verified against the original mixer, and amixer.
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).
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.
--------------
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 );
-----
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.
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 ?
Tim.
On August 3, 2010 09:36:54 pm Niels Mayer wrote:
> FYI, I added the following since
> http://nielsmayer.com/envy24control/mudita24-1.0.1.tar.gz
> ... shall I release a 1.0.2 with the following additions (?):
>
> * fixed --card and --device to allow valid ALSA names and numbers
> ( https://bugzilla.redhat.com/show_bug.cgi?id=602900 ).
> * Add display of "Delta IEC958 Input Status" under "Hardware Settings."
> * Updated and corrected manual page and README
>
> Before I release, I'd like to know what happens on cards that don't
> have this feature, or if it's universally supported, but badly named.
> Can those with a Terratec or other card test the following command and
> let me know the results of command "amixer -c M66 cget
> iface=MIXER,name='Delta IEC958 Input Status'"
>
> e.g.:
> >> amixer -c M66 cget iface=MIXER,name='Delta IEC958 Input Status'
> >> numid=50,iface=MIXER,name='Delta IEC958 Input Status'
> >> ; type=BOOLEAN,access=r-------,values=1
> >>
> >> : values=on
>
> ...........................................................................
>......................
>
> Also, in case anybody ever wondered what this one, under "Analog
> Volume" is for: "Volume Control Rate Register" I added it to the
> README:
>
> .........................
>
> Notes on the Envy24's hardware Digital Mixer and hardware Metering,
> by Niels Mayer ( http://nielsmayer.com ):
> --------------------
>
> The "Monitor Inputs" and "Monitor PCMs" tabs contain multiple scale widgets
> grouped into L/R pairs and an associated peak-level meter. Each scale
> widget represents the 24 bit attenuation value of each input to the
> ice1712-based soundcard's digital mixer. This mixer is typically used for
> zero-latency monitoring of "live" inputs, alongside backing sounds and
> effects coming from the eight channels of PCM feeding the digital mixer.
> When many inputs are "hot" simultaneously these scale-widgets attenuate the
> inputs going into the digital mixer to prevent the output from clipping.
> For details see http://nielsmayer.com/npm/envy24mixer-architecture.png
>
> (from http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf )
>
> This is what the above manual says about the Envy24's digital mixer:
> > 4.5.5 Multi-Track Digital Monitoring
> >
> > The Envy24 integrates a 36-bit resolution digital hardware mixer. The
> > width of the data path is strictly to ensure that during processing of
> > all the channels, under any condition, no resolution is lost. The
> > dynamic range of the end user system will be limited by the range of the
> > physical output devices used. In order to maintain identical gain to the
> > input stream (i.e. 0dB), the resulting 24-bit is not msb-aligned to the
> > 36-bit. The overflow bits correspond to the analog distortion due to
> > saturation. The user would need to reduce the overall attenuation of the
> > inputs to avoid clipping. Insertion of the digital mixer adds only a
> > single sample cycle delay with respect to the original data. This
> > extremely low latency all digital mixer provides monitoring
> > functionality and can replace a traditional external analog input
> > mixer. There are 20 independent audio data streams to mix and control
> > the volume.
>
> Adjustment of responsivity vs. "zipper noise" from the 1.5dB steps at
> the top-range of
> the digital mixer attenuators is achieved by the following control
>
> under "Hardware Settings":
> > MT3B: Volume Control Rate Register
> > ...
> > Volume update rate control (sampling rate, PSYNC)
> > This register allows gradual change of the digital mixer volume
> > setting. The value in MT3B specifies the number of samples to elapse (in
> > hex) between each 1.5dB increment/decrement in volume mixer. This
> > gradual volume update continues until the setting programmed into MT38 is
> > reached. The appropriate value to program may vary, but 00 or 01h are
> > good choices for most cases.
>
> The peak metering data is displayed as 0 to -48dBFS in envy24control's
>
> meters. This data is derived from the envy24's hardware peak metering:
> > Peak data derived from the absolute value of 9 msb. 00h min - FFh max
> > volume. Reading the register resets the meter to 00h.
>
> This resolution of the hardware metering is descibed by Fons Adriaensen in
> a mailing list discussion:
>
> http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-August/029009.ht
>ml
>
> > [...] You have 128 steps between 0 and -6dB...
> > And even at -24dB the next step is 1.3dB lower. Below that
> > it gets worse radipdly. For a meter that is just supposed
> > to keep a check on peak levels it's OK.
>
> Note that hardware metering data is also available from the command-line:
> > amixer -c M66 cget iface=PCM,name='Multi Track Peak',numid=45
> > numid=45,iface=PCM,name='Multi Track Peak'
> > ; type=INTEGER,access=r-------,values=22,min=0,max=255,step=0
> >
> > : values=63,62,51,49,56,60,63,62,59,54,0,0,0,0,0,0,0,0,0,0,113,112
>
> ....................................................................
>
> Niels
> http://nielsmayer.com
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Aug 5 00:15:03 2010
This archive was generated by hypermail 2.1.8 : Thu Aug 05 2010 - 00:15:03 EEST
