13 Jul
2010
13 Jul
'10
12:41 a.m.
I've been long annoyed by alsa-tools' envy24control (*) lack of
peak-level indication in it's metering, and the non-implementation of
its "Reset Peaks" button:
https://bugzilla.redhat.com/show_bug.cgi?id=602903
I've fixed that annoyance. Now, a small white line appears above the
highest level on each meter, and can be reset via "Reset Peaks"
button.
Original source:
http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=envy24control/…
Patch:
http://nielsmayer.com/npm/602903.patch
To run this version of envy24control grab the most recent stable release (
ftp://ftp.alsa-project.org/pub/tools/alsa-tools-1.0.23.tar.bz2 ) or git pull
from trunk of the "alsa-tools" project (
http://alsa-project.org/main/index.php/GIT_Server ).
After unpacking and assuming you've got the patch in ~/602903.patch do:
> cd alsa-tools-1.0.23
> cat ~/602903.patch | patch -p1
it should give message "patching file envy24control/levelmeters.c" ...
follow the directions to compile alsa-tools....
Can whoever's in charge of these things commit this change "upstream"
and get it to propagate to the distros?
Alternately, give me commit access and I'll do it myself, if people
agree this patch is worth having.
Next steps:
(1) Think about building-in meter ballistics from Fons Adriaensen's
jkmeter ( http://www.kokkinizita.net/linuxaudio/downloads/jkmeter-0.4.0.tar.bz2
). Which helps implent Bob Katz' "K System" (
http://www.digido.com/level-practices-part-2-includes-the-k-system.html
). Although it probably most makes sense to implement such metering on
the main "digital mixer" meter of envy24control, if it's not too
inefficient, I'd want it available on all meters, despite the warning
from Fons ( http://old.nabble.com/First-release-of-jkmeter-td18798950.html
).
This is the type of meter you want for live
recording,
mixing and mastering. It probably makes no sense to
use it on all tracks of a DAW, where keeping digital
level within limits is the main purpose of metering.
(2) Fix https://bugzilla.redhat.com/show_bug.cgi?id=602900 which
causes 'envy24control' to crash when given "-D" argument.
and behave incorrectly when given a correct non-numeric name for an
audio device: e.g.
> envy24control --card M66
> invalid card type (driver is USB-Audio)
> envy24control --card M66 --device M66
> Segmentation fault (core dumped)
(3) Apply more reasonable defaults and automatically size to correct
dimensions. I use, for example:
> envy24control --card 2 --outputs 4 --input 4
--pcm_output 8 --view_spdif_playback --midichannel 1 --midienhanced --window_width 1275
--tall_eq_mixer_heights 1 &
(4) Add midi output, in addition to midi input, which would monitor
the hardware peak metering from the ice1712
("amixer -c M66 cget iface=PCM,name='Multi Track Peak',numid=45")
and output a MIDI note-on on the corresponding MIDI channel whenever a
specified threshold value was exceeded. This could be used to
implement "automatic gain control" in association with the
midi-controllable ADC gain provided by envy24control.
Niels
http://nielsmayer.com
PS: (*) http://alsa.opensrc.org/index.php/Envy24control
Cards supported by this fix:
* M Audio Delta 1010
* M Audio Delta 1010LT
* M Audio Delta DiO 2496
* M Audio Delta 66
* M Audio Delta 44
* M Audio Delta 410
* M Audio Audiophile 2496
* TerraTec EWS 88MT
* TerraTec EWS 88D
* TerraTec EWX 24/96
* TerraTec DMX 6Fire
* TerraTec Phase 88
* Hoontech SoundTrack DSP 24
* Hoontech SoundTrack DSP 24 Value
* Hoontech SoundTrack DSP 24 Media 7.1
* Event Electronics, EZ8
* Digigram VX442
* Lionstracs, Mediastaton
* Terrasoniq TS 88
13 Jul
13 Jul
1:40 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On Mon, Jul 12, 2010 at 03:41:15PM -0700, Niels Mayer wrote:
(1) Think about building-in meter ballistics from Fons
Adriaensen's
jkmeter ( http://www.kokkinizita.net/linuxaudio/downloads/jkmeter-0.4.0.tar.bz2
). Which helps implent Bob Katz' "K System" (
http://www.digido.com/level-practices-part-2-includes-the-k-system.html
). Although it probably most makes sense to implement such metering on
the main "digital mixer" meter of envy24control, if it's not too
inefficient, I'd want it available on all meters, despite the warning
from Fons ( http://old.nabble.com/First-release-of-jkmeter-td18798950.html
).
> This is the type of meter you want for live recording,
> mixing and mastering. It probably makes no sense to
> use it on all tracks of a DAW, where keeping digital
> level within limits is the main purpose of metering.
That comment is still true. A K-meter is for signals
that are in a sense the 'end result' you listen to.
For monitoring 'technical' levels in digital audio
the peak digital level is all you need.
A much more serious failure of Envy24ctl's meters is
that they don't provide any level indication at all.
Where is -10 dB ? or -20 dB ? Except for checking if
a signal is present they are just eye candy.
For me it doesn't matter at all. I/O gains are fixed
and levels are checked either by application software
or by the external equipment (a mixer in my case, the
sound card is connected as if it were an 8-track). So
in practice I never use Envy24control.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
3:18 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On Mon, Jul 12, 2010 at 4:40 PM, <fons(a)kokkinizita.net> wrote:
That comment is still true. A K-meter is for signals
that are in a sense the 'end result' you listen to.
For monitoring 'technical' levels in digital audio
the peak digital level is all you need.
As I mentioned, the main use would be for the "digital mixer" meter --
which is a single meter -- always visible on the left hand side no
matter which tab-panel selected -- representing the output of all the
inputs to the 36 bit wide digital mixer. The inputs feeding the
meter&mixer can include audio from 8 PCM outs + 2 SPDIF outs, as well
as 4 inputs, and 2 SPDIF inputs. Very much the "end result" you listen
to. It is normally used for "zero latency monitoring" of analog inputs
-- in which case the digital mix out is routed to the headphones. You
can also use it as an internal digital mix/route before going to hard
disk or DAW input -- very convenient as such.
However, also for the other individual inputs, one may find the option
of "K-system" metering useful for setting "average recording levels".
Our single instruments can be like "entire bands" and do not afford
proper metering into their own virtual digital mixer -- for example
the one hidden inside my db50xg clone. Or any other instrument capable
of simultaneous playback of 16 midi channels w/o individual mix-outs.
For that situation, or recording any "submix", you still might want to
have an indication of RMS or average values... if it's a meter that
claims to be able to present "perceptual loudness" and its useful,
great! i've found jkmeter useful for just such purposes...
Lets say you're recording a synth-line that is "expressive' -- you
might well want to use K-levels as a baseline reference level 0db for
recording, leaving either 14 or 20db headroom for the resonance on a
filter, or the loudness multiplication that arpeggiation, beat matched
reverberations,can give...
And of course the "K-level" could just be a slider or the ability to
move the meter background around via direct manipulation -- the
audio-equivalent of the little ring you twist around on a compass ....
A much more serious failure of Envy24ctl's meters
is
that they don't provide any level indication at all.
Where is -10 dB ? or -20 dB ? Except for checking if
a signal is present they are just eye candy.
I thought about fixing this along with the peak-level-hold issue, and
decided to not add any new bugs in fixing another :-) That "fix" would
be for another patch....
The hardware metering delivers levels from 0-255. According to
http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf the values
represent:
"Peak data derived from the absolute value of 9 msb. 00h min - FFh max
volume. Reading the
register resets the meter to 00h."
If anybody wants to contribute a mapping of 0-255 in db as the "9
msb's" of a 36bit deep mixer -- I'll add peak levels. And fons, if you
have any suggestions for displaying averaged, rms'd or "k-system'd"
versions of these 0-255 loudness values from the hardware metering,
that would be helpful too -- all I'm really looking for is "average
listening level/perceptual level". But the hardware metering may not
be able to provide that in a meaninful fashion.
Speaking of making my brain hurt -- I really would not have done the
meters as done in envy24control. I really hate the concept of
emulating the look of real gear down to the level that you have to
"quantize" to individual LED's... real helpful when you're checking to
see if you're an "led" away from clipping, or right there.... and all
the heinous computation to draw individual rectangles via a bunch of
offscreen gdk_draw_pixmap()-per-LED and then a big BLIT (w/o damage
area computation, it just blits the whole meter each update) -- each
and every time there's a meter value change, for each visible
meter.... All quite silly when it's quantized to 255 levels in the
first place.
And my patch adds to the mess and inefficiency by adding a single
gdk_draw_line() representing the peak level, which comes after the
original code redraws all the led-segments of each meter, for each
value refresh... Using the same damn for-loop, instead of computing
its pixel offset directly -- IMHO the entire meter needs a rewrite!...
which is why i was looking at jkmeter...
For this time, I was looking towards a clean patch to the existing
code, not a rewrite: http://nielsmayer.com/npm/602903.patch
be sure to checkout gint level_meters_timeout_callback(gpointer data) in
http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=envy24control/…
-- Niels
http://nielsmayer.com
10:19 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On Mon, Jul 12, 2010 at 06:18:29PM -0700, Niels Mayer wrote:
On Mon, Jul 12, 2010 at 4:40 PM,
<fons(a)kokkinizita.net> wrote:
Yes, if the mixer is used for monitoring you'd want a good ides
of the level you send to the musician's headphones.
But the output mixer is available on two PCM ins as well, so you can
measure it there using the real thing.
That comment is still true. A K-meter is for
signals
that are in a sense the 'end result' you listen to.
For monitoring 'technical' levels in digital audio
the peak digital level is all you need.
As I mentioned, the main use would be for the "digital mixer" meter --
which is a single meter -- always visible on the left hand side no
matter which tab-panel selected -- representing the output of all the
inputs to the 36 bit wide digital mixer. The inputs feeding the
meter&mixer can include audio from 8 PCM outs + 2 SPDIF outs, as well
as 4 inputs, and 2 SPDIF inputs. Very much the "end result" you listen
to. It is normally used for "zero latency monitoring" of analog inputs
-- in which case the digital mix out is routed to the headphones. You
can also use it as an internal digital mix/route before going to hard
disk or DAW input -- very convenient as such. If anybody wants to contribute a mapping of 0-255 in
db as the "9
msb's" of a 36bit deep mixer -- I'll add peak levels.
That is easy enough. L dB (L < 0) corresponds to 255 * (10 ^ L / 20).
And fons, if you
have any suggestions for displaying averaged, rms'd or "k-system'd"
versions of these 0-255 loudness values from the hardware metering,
that would be helpful too -- all I'm really looking for is "average
listening level/perceptual level". But the hardware metering may not
be able to provide that in a meaninful fashion.
Indeed it's not possible. You can't derive average or RMS levels
from peak levels. Basically you need all samples.
Speaking of making my brain hurt -- I really would not
have done the
meters as done in envy24control. I really hate the concept of
emulating the look of real gear down to the level that you have to
"quantize" to individual LED's...
That is indeed quite absurd.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
14 Jul
14 Jul
6:55 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On Tue, Jul 13, 2010 at 1:19 AM, <fons(a)kokkinizita.net> wrote:
On Mon, Jul 12, 2010 at 06:18:29PM -0700, Niels Mayer
wrote:
Yes, the meters in envy24control --
http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=envy24control/…
-- are absurd! What's even more absurd, is to have the benefits of the
ice1712's hardware metering squandered by drawing thousands of
rectangles per second (each individual "LED" on each meter is a
separate x draw-rectangle call). The existing envy24control meters are
an abomination of inefficiency! Especially when used with a remote X
display.
As a second patch (coming soon), I've rewritten the meters in a more
sensible fashion, drawing a single rectangle to represent the
instantaneous level (2-3 X-primitive draws per meter total and one
blit, versus hundreds of draws and a blit per value change per meter
in the original code). I'm also being a little more careful about not
needing to redraw the entire meter for each change -- using the
monotonicity of the audio signal being represented to optimize the way
you draw it; not redrawing if nothing has changed, etc.
And since the hardware metering already quantizes to 256 levels --
there's no point in re-quantizing those to individual "virtual LEDs"
as is done w/ the current envy24control.
The result so far are promising: Here's 'top' output (*) using the new
envy24control. Note the load is lower, and 'envy24control' and 'X'
both use much less CPU. In fact running this meter lowers the system
load. whereas running the old envy24control raises it (and makes the
fans run faster!).
top - 21:30:13 up 11:30, 9 users, load average: 0.02, 0.11, 0.06
2664 root 20 0 544m 134m 34m S 2.6 3.4 26:03.51 X
9404 npm 20 0 192m 9340 6908 S 0.7 0.2 0:01.72
envy24control
The new metering gives 2.6% CPU for X, and 0.7% CPU for the
new-metered envy24control; Versus 6.3% CPU for X and 2.7% for the old
metering in envy24control (the one from my first patch):
top - 21:25:57 up 11:25, 9 users, load average: 0.10, 0.09, 0.03
2664 root 20 0 544m 134m 34m S 6.3 3.4 25:50.67 X
9398 npm 20 0 192m 9368 6940 S 2.7 0.2 0:16.81 envy24control
Now granted this is not a scientific test, and "top" is not exactly
the best way to gauge performance. But it does suggest that the
computational complexity caused by the bad metering algorithm directly
translates to higher-power consumption, higher loads, and poorer
performance.
Compared to the existing envy24control metering -- It would probably
me more efficient to actually compute RMS levels off the audio stream
-- or even hook up jkmeter through jack -- instead of using the
hardware metering data through these computationally wasteful level
meters.
-- Niels
http://nielsmayer.com
Speaking of making my brain hurt -- I really
would not have done the
meters as done in envy24control. I really hate the concept of
emulating the look of real gear down to the level that you have to
"quantize" to individual LED's...
That is indeed quite absurd.
3:45 p.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On Tue, Jul 13, 2010 at 09:54:58PM -0700, Niels Mayer wrote:
What's even more absurd, is to have the benefits
of the
ice1712's hardware metering squandered by drawing thousands of
rectangles per second (each individual "LED" on each meter is a
separate x draw-rectangle call).
It should at least use the XDrawRectangles(), which draws a list
of them in a single call.
And since the hardware metering already quantizes to
256 levels --
there's no point in re-quantizing those to individual "virtual LEDs"
as is done w/ the current envy24control.
Depends. A linear mapping is not really the best you can do.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
16 Jul
16 Jul
3:14 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On Tue, Jul 13, 2010 at 9:54 PM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
As a second patch (coming soon), I've rewritten
the meters in a more
sensible fashion, drawing a single rectangle to represent the
instantaneous level (2-3 X-primitive draws per meter total and one
blit, versus hundreds of draws and a blit per value change per meter
in the original code).
Patch for https://bugzilla.redhat.com/show_bug.cgi?id=602903
(see also
http://old.nabble.com/FIxed-alsa-tools'-envy24control-missing-peak-leve…
)
(1) http://nielsmayer.com/npm/Screenshot-Efficient-Meters-Envy24Control.png
* To see what the new meters look like.
(2) http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.tgz
* Contains levelmeters.c and x86_64 binary 'envy24control' that should at
least work on Fedora 12 and OpenSuse and other 2.6.32-based distros.
(3) http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.patch
* To apply the patch, grab the most recent stable release (
ftp://ftp.alsa-project.org/pub/tools/alsa-tools-1.0.23.tar.bz2 ) or
git pull from trunk of the "alsa-tools" project.
* After unpacking and assuming you've got the patch in
~/Efficient-Meters-Envy24Control.patch.patch do:
> cd alsa-tools-1.0.23
> cat ~/Efficient-Meters-Envy24Control.patch | patch -p1
* It should give
message "patching file envy24control/levelmeters.c"
* Follow the directions to compile alsa-tools.
FYI here's what my "top" processes look like when running a test to
output individual streams to all 10 PCM output channels -- note X
consumes between "1.7%" to "2.0 %" and "envy24control"
"0.7%" to
"1.0%":
15210 npm 20 0 643m 14m 8964 S 6.6 0.4 0:05.85 gst123
15184 npm 20 0 643m 14m 8984 S 6.3 0.4 0:13.11 gst123
15190 npm 20 0 643m 14m 8980 S 6.0 0.4 0:12.48 gst123
15172 npm 20 0 643m 14m 8968 S 5.6 0.4 0:15.42 gst123
15178 npm 20 0 643m 14m 8984 S 5.6 0.4 0:14.17 gst123
13684 root 20 0 527m 112m 31m S 2.0 2.8 3:26.11 X
13923 npm 20 0 863m 60m 37m S 1.0 1.5 2:49.08 plasma-desktop
14163 npm 20 0 597m 27m 15m S 1.0 0.7 1:08.29 chrome
14155 npm 20 0 1038m 170m 14m S 0.7 4.3 1:00.87 chrome
15226 npm 20 0 192m 9316 6908 S 0.7 0.2 0:00.51 envy24control
Here's the envy24control from my first patch, using the original
meters that cause many separate XDrawRectangles for each LED-looking
segment. The performance difference is quite noticeable as the fans
start running louder and the system load climbs upwards as soon as the
original envy24control starts running: X consumes 5.7-10% CPU, and
envy24control between 2.0% and 2.7%.
15172 npm 20 0 643m 14m 8968 S 6.1 0.4 0:53.83 gst123
15178 npm 20 0 643m 14m 8984 S 6.1 0.4 0:51.48 gst123
15190 npm 20 0 643m 14m 8980 S 6.1 0.4 0:49.60 gst123
15210 npm 20 0 643m 14m 8964 S 6.1 0.4 0:44.01 gst123
13684 root 20 0 527m 112m 31m S 5.7 2.8 3:42.78 X
15184 npm 20 0 643m 14m 8984 S 5.7 0.4 0:51.07 gst123
15398 npm 20 0 192m 9332 6908 S 2.4 0.2 0:02.32
envy24control.f
14163 npm 20 0 597m 27m 15m S 1.0 0.7 1:15.54 chrome
13923 npm 20 0 863m 60m 37m S 0.6 1.5 2:55.04
plasma-desktop
Just to show that it's the same performance as the original
envy24control from alsa-tools-1.0.22-1.1.fc12.ccrma.x86_64:
15178 npm 20 0 643m 14m 8984 S 6.3 0.4 1:28.72 gst123
15190 npm 20 0 643m 14m 8980 S 6.3 0.4 1:26.65 gst123
15210 npm 20 0 643m 14m 8964 S 6.3 0.4 1:20.59 gst123
15184 npm 20 0 643m 14m 8984 S 6.0 0.4 1:28.21 gst123
13684 root 20 0 527m 112m 31m R 5.6 2.8 4:21.30 X
15172 npm 20 0 643m 14m 8968 S 5.6 0.4 1:31.51 gst123
15455 npm 20 0 192m 8700 6316 S 2.3 0.2 0:01.74
envy24control
14163 npm 20 0 597m 27m 15m S 1.3 0.7 1:23.02 chrome
13923 npm 20 0 863m 60m 37m S 0.7 1.5 3:00.72 plasma-desktop
-- Niels
http://nielsmayer.com
14 Jul
14 Jul
12:57 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
Hey Niels, thanks for the attention to this mixer.
I usually talk to Takashi Iwai at ALSA when I have patches.
It's been a while, but if he's still there he's very receptive.
The last time, I helped with getting him to fix the word clock
lock indicator.
The hardware has separate gain and attenuation stages.
Several years ago someone combined the 'gain' sliders
with the 'attenuation' sliders, on the 'Analog Volume' tab,
and there was some outcry from some users because they
wanted to have independent gain and attenuation sliders
and clearly know what each slider was set at.
I argued that this combining was a good thing because
having separate gain and attenuation sliders was clumsy.
I said that as long as the combined sliders were clearly marked,
users would know that anything above the 0dB mark
would clearly signify gain.
But nothing was ever done about the slider markings.
Having them go from 0 to 164 is not really helpful.
It's not clear where the 0dB mark is.
At the very least a 0dB mark should be added.
Uh, do you feel like taking a stab at this?
IIRC it would be a bit tricky because you have to look up
the corresponding values in the IC data sheets, I think.
Thanks. Tim.
On July 12, 2010 06:41:15 pm Niels Mayer wrote:
I've been long annoyed by alsa-tools'
envy24control (*) lack of
peak-level indication in it's metering, and the non-implementation of
its "Reset Peaks" button:
https://bugzilla.redhat.com/show_bug.cgi?id=602903
I've fixed that annoyance. Now, a small white line appears above the
highest level on each meter, and can be reset via "Reset Peaks"
button.
Original source:
http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=envy24control/
levelmeters.c;hb=HEAD Patch:
http://nielsmayer.com/npm/602903.patch
To run this version of envy24control grab the most recent stable release (
ftp://ftp.alsa-project.org/pub/tools/alsa-tools-1.0.23.tar.bz2 ) or git
pull from trunk of the "alsa-tools" project (
http://alsa-project.org/main/index.php/GIT_Server ).
After unpacking and assuming you've got the patch in ~/602903.patch do:
> cd alsa-tools-1.0.23
> cat ~/602903.patch | patch -p1
it should give message "patching file envy24control/levelmeters.c" ...
follow the directions to compile alsa-tools....
Can whoever's in charge of these things commit this change "upstream"
and get it to propagate to the distros?
Alternately, give me commit access and I'll do it myself, if people
agree this patch is worth having.
Next steps:
(1) Think about building-in meter ballistics from Fons Adriaensen's
jkmeter (
http://www.kokkinizita.net/linuxaudio/downloads/jkmeter-0.4.0.tar.bz2 ).
Which helps implent Bob Katz' "K System" (
http://www.digido.com/level-practices-part-2-includes-the-k-system.html
). Although it probably most makes sense to implement such metering on
the main "digital mixer" meter of envy24control, if it's not too
inefficient, I'd want it available on all meters, despite the warning
from Fons ( http://old.nabble.com/First-release-of-jkmeter-td18798950.html
).
This is the type of meter you want for live
recording,
mixing and mastering. It probably makes no sense to
use it on all tracks of a DAW, where keeping digital
level within limits is the main purpose of metering.
(2) Fix https://bugzilla.redhat.com/show_bug.cgi?id=602900 which
causes 'envy24control' to crash when given "-D" argument.
and behave incorrectly when given a correct non-numeric name for an
audio device: e.g.
> envy24control --card M66
> invalid card type (driver is USB-Audio)
> envy24control --card M66 --device M66
> Segmentation fault (core dumped)
(3) Apply more reasonable defaults and automatically size to correct
dimensions. I use, for example:
> envy24control --card 2 --outputs 4 --input 4
--pcm_output 8
> --view_spdif_playback --midichannel 1 --midienhanced --window_width 1275
> --tall_eq_mixer_heights 1 &
(4) Add midi output, in addition to midi input, which would monitor
the hardware peak metering from the ice1712
("amixer -c M66 cget iface=PCM,name='Multi Track Peak',numid=45")
and output a MIDI note-on on the corresponding MIDI channel whenever a
specified threshold value was exceeded. This could be used to
implement "automatic gain control" in association with the
midi-controllable ADC gain provided by envy24control.
Niels
http://nielsmayer.com
PS: (*) http://alsa.opensrc.org/index.php/Envy24control
Cards supported by this fix:
* M Audio Delta 1010
* M Audio Delta 1010LT
* M Audio Delta DiO 2496
* M Audio Delta 66
* M Audio Delta 44
* M Audio Delta 410
* M Audio Audiophile 2496
* TerraTec EWS 88MT
* TerraTec EWS 88D
* TerraTec EWX 24/96
* TerraTec DMX 6Fire
* TerraTec Phase 88
* Hoontech SoundTrack DSP 24
* Hoontech SoundTrack DSP 24 Value
* Hoontech SoundTrack DSP 24 Media 7.1
* Event Electronics, EZ8
* Digigram VX442
* Lionstracs, Mediastaton
* Terrasoniq TS 88
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
1:26 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On Tue, Jul 13, 2010 at 06:46:36PM -0400, Tim E. Real wrote:
It's not clear where the 0dB mark is.
AFAIK it's at 127.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
7:04 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On July 13, 2010 07:26:24 pm fons(a)kokkinizita.net wrote:
On Tue, Jul 13, 2010 at 06:46:36PM -0400, Tim E. Real
wrote:
Yes, I know that, but I was thinking of new users.
Other dB markings might help, too, just as a reference.
I don't remember why I didn't try to take care of it,
if there was some difficulty in the actual dB numbers or
something, or probably just never got around to it.
AFAIK above 127 the gain stage is operated upon rather than
the attenuation stage.
Tim.
It's not clear where the 0dB mark is.
AFAIK it's at 127.
Ciao,
16 Jul
16 Jul
12:11 p.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On Tue, Jul 13, 2010 at 3:46 PM, Tim E. Real <termtech(a)rogers.com> wrote:
But nothing was ever done about the slider markings.
Having them go from 0 to 164 is not really helpful.
It's not clear where the 0dB mark is.
At the very least a 0dB mark should be added.
Uh, do you feel like taking a stab at this?
IIRC it would be a bit tricky because you have to look up
the corresponding values in the IC data sheets, I think.
This makes sense... I was thinking of a simple ruler with a 0dB label
at 127 and a + dB label above and a - dB label below.
Some thoughts on further usability improvements to envy24control:
(1) In "alsamixer" the snd-ice1712-card's input levels are
represented by (versus envy24control's value):
100% (163) -> ADC [dB gain: 18.00]
78% (127) -> ADC [dB gain: 0.00]
1% (001) -> ADC [dB gain: -63.00]
0% (000) -> ADC [dB gain: mute]
Mixers like envy24control, kmix, alsamixergui, gst-mixer, etc, are a
lot less useful than they could be because they just present sliders.
At least envy24control gives numeric values, -- which is essential if
you want to know stereo channels are balenced, or what unity-gain
levels are for inputs.
In "alsamixer", the snd-ice1712-card's output levels are represented
by (versus envy24control value):
100% (127) -> DAC [dB gain: 0.00]
1% (001) -> DAC [dB gain: -63.00]
0% (000) -> DAC [dB gain: mute]
As this is a separate issue from the meters, it makes sense to do the
changes to the "Analog Volume" panel of envy24control as a separate
patch.
(2) The "0-96" sliders, feeding the digital mixer, need better
labeling and mappings too: The "96" actually being "-96dB" and only
valid for 16 bit depths. On the other hand, alsamixer is showing the
24 bit dB values, even when 16 bits are being used:
100% (0) -> H/W Multi [dB gain: 0.00, ...]
1% (95) -> H/W Multi [dB gain: -142.50,...]
0% (96) -> H/W Multi [dB gain: -144.00,...]
Worse than the labelling, but associated -- the scaling: Right now the
digital mixer's input sliders all have linear response -- which wastes
the lower half of the slider and makes setting levels difficult
because all the "action" is near the top. If you use an external MIDI
controller for the mixer, you can use this existing option:
-M, --midienhanced Use an enhanced mapping from midi controller to db slider
However this does not apply to the GUI controller, which stays linear.
Clearly the GUIs digital mixer controls also need a logarithmic scale
(perhaps as default settings); matching that, each mixer input's
meters also need to have their scale expressed "logarithmically" so as
to provide, for example 50% of the display resolution for 0 to -20dB,
and remaining 50% for -20dB to -96dB/-144dB.
Alongside the numbers indicating the 0 to -96db L or R gain on each
mixer input channel, I would also add the current peak value held in
the meters in dB, which would be based on hardware metering level
"0xFF" representing 0db, and hardware meter level "0x01" representing
all but the last of the 9 MSB's being 0 (per
http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf: "Peak data
derived from the absolute value of 9 msb. 00h * min - FFh max volume.
Reading the register resets the meter to 00h."
Other missing features:
(3) Due to the hardware metering employed by envy24control, the peak
meters don't actually detect "clipping" ; rather, they just detect
"full scale" as 255. Is there a hardware clipped indicator on the
ice1712? It doesn't make sense to turn on a big red "clipped" light
for 0dB output, so the current peak-meters are "subtle," and just
indicate that a peak occurred at the given level... And color-code the
peak towards red as it reaches 255.
(4) The "IEC958 Input Status" isn't presented, even though it's
available and working, e.g from the command-line,. with SPDIF input
going to the Delta66 soundcard:
.....
gnulem-176-~> amixer -c M66 cget numid=50,iface=MIXER,name='Delta
IEC958 Input Status'
numid=50,iface=MIXER,name='Delta IEC958 Input Status'
; type=BOOLEAN,access=r-------,values=1
: values=on
.....
And without any SPDIF input:
.....
gnulem-177-~> amixer -c M66 cget numid=50,iface=MIXER,name='Delta
IEC958 Input Status'
numid=50,iface=MIXER,name='Delta IEC958 Input Status'
; type=BOOLEAN,access=r-------,values=1
: values=off
Perhaps this isn't available in envy24control because it has differing
levels of support across envy24-based cards? I only have a Delta66's
and a Terratec Dmx6Fire 24/96 for testing, and both support the SPDIF
input status.
-- Niels
http://nielsmayer.com
PS: ALSA tip of the day. To read ice1712's hardware level-meter values
from the command line:
"amixer -c M66 cget iface=PCM,name='Multi Track Peak',numid=45"
type=INTEGER,access=r-------,values=22,min=0,max=255,step=0
: values=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,198,255,198
17 Jul
17 Jul
3:07 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
Been so long since I studied envy24 stuff that I was in danger of
messing up facts and wishing for something that might not be
possible. So I pulled my card out and looked at the ICs and their
datsheets, and looked at envy24control coding.
The ADC chip on my particular card is AK4524 from AKM.
Although the gain and attenuation stages are separate,
the control of them is not. Values from 0-127 control
the IATT stage, and values above 127 control the IPGA stage.
Looks like:
envy24control still has code to show both the IPGA and IATT controls.
I don't remember why they were separate in the first place.
Possibly some (AKM) chips allow *separate* control of gain and attenuation.
But it was ALSA where the two controls were combined into one ADC.
So I think envy24control just shows the one ADC control now.
This seems to open the door for other kinds of ADC chips, which
don't have separate gain and attenuation stages, and/or which
could have other value ranges. Say a range which doesn't go above 0dB.
So... I was going to say this means envy24control (or other mixer) has no
way of knowing what value corresponds to what dB, or where the 0dB point is.
But then I saw that amixer prints out the dB values.
Can't remember where amixer gets that from... Was it trickery or true values?
And do we have access to these values?
I think this was the difficulty I was remembering last post.
One moment... Checking...
Here we go! snd_mixer_selem_get_playback_dB( )
Problem solved? Accurate or not?
Cheers. Tim.
On July 16, 2010 03:13:17 am you wrote:
On Tue, Jul 13, 2010 at 3:46 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
But nothing was ever done about the slider
markings.
Having them go from 0 to 164 is not really helpful.
It's not clear where the 0dB mark is.
At the very least a 0dB mark should be added.
Uh, do you feel like taking a stab at this?
IIRC it would be a bit tricky because you have to look up
the corresponding values in the IC data sheets, I think.
This makes sense... I was thinking of a simple ruler with a 0dB label
at 127 and a + dB label above and a - dB label below.
Some thoughts on further usability improvements to envy24control:
(1) In "alsamixer" the snd-ice1712-card's input levels are
represented by (versus envy24control's value):
100% (163) -> ADC [dB gain: 18.00]
78% (127) -> ADC [dB gain: 0.00]
1% (001) -> ADC [dB gain: -63.00]
0% (000) -> ADC [dB gain: mute]
Mixers like envy24control, kmix, alsamixergui, gst-mixer, etc, are a
lot less useful than they could be because they just present sliders.
At least envy24control gives numeric values, -- which is essential if
you want to know stereo channels are balenced, or what unity-gain
levels are for inputs.
In "alsamixer", the snd-ice1712-card's output levels are represented
by (versus envy24control value):
100% (127) -> DAC [dB gain: 0.00]
1% (001) -> DAC [dB gain: -63.00]
0% (000) -> DAC [dB gain: mute]
As this is a separate issue from the meters, it makes sense to do the
changes to the "Analog Volume" panel of envy24control as a separate
patch.
(2) The "0-96" sliders, feeding the digital mixer, need better
labeling and mappings too: The "96" actually being "-96dB" and only
valid for 16 bit depths. On the other hand, alsamixer is showing the
24 bit dB values, even when 16 bits are being used:
100% (0) -> H/W Multi [dB gain: 0.00, ...]
1% (95) -> H/W Multi [dB gain: -142.50,...]
0% (96) -> H/W Multi [dB gain: -144.00,...]
Worse than the labelling, but associated -- the scaling: Right now the
digital mixer's input sliders all have linear response -- which wastes
the lower half of the slider and makes setting levels difficult
because all the "action" is near the top. If you use an external MIDI
controller for the mixer, you can use this existing option:
-M, --midienhanced Use an enhanced mapping from midi controller to db
slider However this does not apply to the GUI controller, which stays
linear.
Clearly the GUIs digital mixer controls also need a logarithmic scale
(perhaps as default settings); matching that, each mixer input's
meters also need to have their scale expressed "logarithmically" so as
to provide, for example 50% of the display resolution for 0 to -20dB,
and remaining 50% for -20dB to -96dB/-144dB.
Alongside the numbers indicating the 0 to -96db L or R gain on each
mixer input channel, I would also add the current peak value held in
the meters in dB, which would be based on hardware metering level
"0xFF" representing 0db, and hardware meter level "0x01"
representing
all but the last of the 9 MSB's being 0 (per
http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf: "Peak data
derived from the absolute value of 9 msb. 00h * min - FFh max volume.
Reading the register resets the meter to 00h."
Other missing features:
(3) Due to the hardware metering employed by envy24control, the peak
meters don't actually detect "clipping" ; rather, they just detect
"full scale" as 255. Is there a hardware clipped indicator on the
ice1712? It doesn't make sense to turn on a big red "clipped" light
for 0dB output, so the current peak-meters are "subtle," and just
indicate that a peak occurred at the given level... And color-code the
peak towards red as it reaches 255.
(4) The "IEC958 Input Status" isn't presented, even though it's
available and working, e.g from the command-line,. with SPDIF input
going to the Delta66 soundcard:
.....
gnulem-176-~> amixer -c M66 cget numid=50,iface=MIXER,name='Delta
IEC958 Input Status'
numid=50,iface=MIXER,name='Delta IEC958 Input Status'
; type=BOOLEAN,access=r-------,values=1
: values=on
.....
And without any SPDIF input:
.....
gnulem-177-~> amixer -c M66 cget numid=50,iface=MIXER,name='Delta
IEC958 Input Status'
numid=50,iface=MIXER,name='Delta IEC958 Input Status'
; type=BOOLEAN,access=r-------,values=1
: values=off
Perhaps this isn't available in envy24control because it has differing
levels of support across envy24-based cards? I only have a Delta66's
and a Terratec Dmx6Fire 24/96 for testing, and both support the SPDIF
input status.
-- Niels
http://nielsmayer.com
PS: ALSA tip of the day. To read ice1712's hardware level-meter values
from the command line:
"amixer -c M66 cget iface=PCM,name='Multi Track Peak',numid=45"
type=INTEGER,access=r-------,values=22,min=0,max=255,step=0
: values=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,198,255,198
3:22 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On July 16, 2010 08:56:30 pm Tim E. Real wrote:
Been so long since I studied envy24 stuff that I was
in danger of
messing up facts and wishing for something that might not be
possible. So I pulled my card out and looked at the ICs and their
datsheets, and looked at envy24control coding.
The ADC chip on my particular card is AK4524 from AKM.
Although the gain and attenuation stages are separate,
the control of them is not.
Oops, I think that might be wrong. They might be
independently
controlled. Just that bit # 8 determines where you are writing to.
That would explain the old separate IPGA and IATT sliders.
(Although envy24control will "set ADC volume to max if IPGA volume
greater 0" - volume.c line #172. I do remember observing that.)
Tim.
Values from 0-127 control
the IATT stage, and values above 127 control the IPGA stage.
Looks like:
envy24control still has code to show both the IPGA and IATT controls.
I don't remember why they were separate in the first place.
Possibly some (AKM) chips allow *separate* control of gain and attenuation.
But it was ALSA where the two controls were combined into one ADC.
So I think envy24control just shows the one ADC control now.
This seems to open the door for other kinds of ADC chips, which
don't have separate gain and attenuation stages, and/or which
could have other value ranges. Say a range which doesn't go above 0dB.
So... I was going to say this means envy24control (or other mixer) has no
way of knowing what value corresponds to what dB, or where the 0dB point
is. But then I saw that amixer prints out the dB values.
Can't remember where amixer gets that from... Was it trickery or true
values? And do we have access to these values?
I think this was the difficulty I was remembering last post.
One moment... Checking...
Here we go! snd_mixer_selem_get_playback_dB( )
Problem solved? Accurate or not?
Cheers. Tim.
On July 16, 2010 03:13:17 am you wrote:
On Tue, Jul 13, 2010 at 3:46 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev But nothing was ever done about the slider
markings.
Having them go from 0 to 164 is not really helpful.
It's not clear where the 0dB mark is.
At the very least a 0dB mark should be added.
Uh, do you feel like taking a stab at this?
IIRC it would be a bit tricky because you have to look up
the corresponding values in the IC data sheets, I think.
This makes sense... I was thinking of a simple ruler with a 0dB label
at 127 and a + dB label above and a - dB label below.
Some thoughts on further usability improvements to envy24control:
(1) In "alsamixer" the snd-ice1712-card's input levels are
represented by (versus envy24control's value):
100% (163) -> ADC [dB gain: 18.00]
78% (127) -> ADC [dB gain: 0.00]
1% (001) -> ADC [dB gain: -63.00]
0% (000) -> ADC [dB gain: mute]
Mixers like envy24control, kmix, alsamixergui, gst-mixer, etc, are a
lot less useful than they could be because they just present sliders.
At least envy24control gives numeric values, -- which is essential if
you want to know stereo channels are balenced, or what unity-gain
levels are for inputs.
In "alsamixer", the snd-ice1712-card's output levels are represented
by (versus envy24control value):
100% (127) -> DAC [dB gain: 0.00]
1% (001) -> DAC [dB gain: -63.00]
0% (000) -> DAC [dB gain: mute]
As this is a separate issue from the meters, it makes sense to do the
changes to the "Analog Volume" panel of envy24control as a separate
patch.
(2) The "0-96" sliders, feeding the digital mixer, need better
labeling and mappings too: The "96" actually being "-96dB" and only
valid for 16 bit depths. On the other hand, alsamixer is showing the
24 bit dB values, even when 16 bits are being used:
100% (0) -> H/W Multi [dB gain: 0.00, ...]
1% (95) -> H/W Multi [dB gain: -142.50,...]
0% (96) -> H/W Multi [dB gain: -144.00,...]
Worse than the labelling, but associated -- the scaling: Right now the
digital mixer's input sliders all have linear response -- which wastes
the lower half of the slider and makes setting levels difficult
because all the "action" is near the top. If you use an external MIDI
controller for the mixer, you can use this existing option:
-M, --midienhanced Use an enhanced mapping from midi controller to db
slider However this does not apply to the GUI controller, which stays
linear.
Clearly the GUIs digital mixer controls also need a logarithmic scale
(perhaps as default settings); matching that, each mixer input's
meters also need to have their scale expressed "logarithmically" so as
to provide, for example 50% of the display resolution for 0 to -20dB,
and remaining 50% for -20dB to -96dB/-144dB.
Alongside the numbers indicating the 0 to -96db L or R gain on each
mixer input channel, I would also add the current peak value held in
the meters in dB, which would be based on hardware metering level
"0xFF" representing 0db, and hardware meter level "0x01"
representing
all but the last of the 9 MSB's being 0 (per
http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf: "Peak data
derived from the absolute value of 9 msb. 00h * min - FFh max volume.
Reading the register resets the meter to 00h."
Other missing features:
(3) Due to the hardware metering employed by envy24control, the peak
meters don't actually detect "clipping" ; rather, they just detect
"full scale" as 255. Is there a hardware clipped indicator on the
ice1712? It doesn't make sense to turn on a big red "clipped" light
for 0dB output, so the current peak-meters are "subtle," and just
indicate that a peak occurred at the given level... And color-code the
peak towards red as it reaches 255.
(4) The "IEC958 Input Status" isn't presented, even though it's
available and working, e.g from the command-line,. with SPDIF input
going to the Delta66 soundcard:
.....
gnulem-176-~> amixer -c M66 cget numid=50,iface=MIXER,name='Delta
IEC958 Input Status'
numid=50,iface=MIXER,name='Delta IEC958 Input Status'
; type=BOOLEAN,access=r-------,values=1
: values=on
.....
And without any SPDIF input:
.....
gnulem-177-~> amixer -c M66 cget numid=50,iface=MIXER,name='Delta
IEC958 Input Status'
numid=50,iface=MIXER,name='Delta IEC958 Input Status'
; type=BOOLEAN,access=r-------,values=1
: values=off
Perhaps this isn't available in envy24control because it has differing
levels of support across envy24-based cards? I only have a Delta66's
and a Terratec Dmx6Fire 24/96 for testing, and both support the SPDIF
input status.
-- Niels
http://nielsmayer.com
PS: ALSA tip of the day. To read ice1712's hardware level-meter values
from the command line:
"amixer -c M66 cget iface=PCM,name='Multi Track Peak',numid=45"
type=INTEGER,access=r-------,values=22,min=0,max=255,step=0
: values=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,198,255,198
4:22 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
OK final message for now...
On July 16, 2010 08:56:30 pm Tim E. Real wrote:
Here we go! snd_mixer_selem_get_playback_dB( )
Problem solved? Accurate or not?
Slider markings still not possible with this - it
is only a 'current' value.
But that's OK, I'm now thinking markings on every slider would be clutter.
Instead, let's have a dB label below the integer value label, and use
snd_mixer_selem_get_playback_dB() to fill it.
I think that might be reasonable. dB markings may be impossible here...
Yap yap yap... Cheers. Tim.
27 Jul
27 Jul
2:28 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
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...
Slider markings still not possible with this - it is only a 'current'
value.
But that's OK, I'm now thinking markings on every slider would be clutter.
Instead, let's have a dB label below the integer value label, and use
snd_mixer_selem_get_playback_dB() to fill it.
I think that might be reasonable. dB markings may be impossible here...
{snip}
I don't remember why I didn't try to take care
of it,
if there was some difficulty in the actual dB numbers or
something, or probably just never got around to it.
{Much discussion elsewhere...}
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.
----------------
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.
7 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On Mon, Jul 26, 2010 at 5:15 PM, Tim E. Real <termtech(a)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
8:46 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On July 27, 2010 01:00:31 am you wrote:
On Mon, Jul 26, 2010 at 5:15 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
Apparently there is a more advanced TLV based dB conversion.
snd_tlv_convert_to_dB()
If it is true, then in that respect, could we say this code should
be updated to use the TLV dB functions, for better accuracy?
Because at constant 0.5dB steps, the dB labels in alsamixer and
envy24control sure don't seem to correspond closely to what's
in the AK4524 datasheet dB table.
I do hope I'm reading that datasheet right !
Now, a question is: If TLV proves more accurate, do we really want
these odd value yet more accurate markings. Like -18.32 not -18.
Ie maybe pseudo 0.5 dB steps are better, visually.
I'm starting to think so.
It's a compromise after all. Not terribly accurate but it works.
It would become a problem if large inaccuracies arise with some chip.
Ah, maybe a user switch - regular constant, or TLV based for accuracy.
But I need to study that TLV stuff more...
See my other post about successful experiments with other dB funcs.
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);
}
}
}
Yeah I know, I realised the
same thing.
I now have some hope for them.
Hope. Change. Yes we can... Sorry rambling on there.
And of course a switch to turn them on/off is a good idea.
----------------
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?
That was my original golden question. This
looks possible now.
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.
Chip-specific code. Nah, let's try to stick with
what ALSA gives us to
work with. We'd surely want to check that TLV thing first.
Careful, "finite" today, but tomorrow maybe a new ADC chip, eh?
We'll see. The saga continues.... Tim.
I'll look into your ALSA API findings as
well.
Comments?
-- Niels
http://nielsmayer.com
8:52 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
Tim E. Real wrote:
On July 27, 2010 01:00:31 am you wrote:
> > 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.
The driver uses a volume lookup table to pretend that the mixer values
have constant 0.5 dB steps. This should be changed.
> 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?
If there is a bug, it is in the TLV tables in the driver.
Apparently there is a more advanced TLV based dB
conversion.
snd_tlv_convert_to_dB()
The snd_mixer_selem_get_*_dB functions just get the TLV table and then
call snd_tlv_convert_to_dB internally.
Regards,
Clemens
11:11 a.m.
New subject: FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On Mon, 2010-07-26 at 20:15 -0400, Tim E. Real wrote:
On July 16, 2010 10:10:48 pm Tim E. Real wrote:
I've got two Terratec EWX 24/96, a while ago I checked the chips for the
older one of those cards and it has got a AK4524VF.
If more testers are needed, you may want to explain how to do a test.
> Here we go!
snd_mixer_selem_get_playback_dB( )
>
> Problem solved? Accurate or not?
Not accurate with AK4524 chip. Read on...
Slider markings still not possible with this - it is only a 'current'
value.
But that's OK, I'm now thinking markings on every slider would be clutter.
Instead, let's have a dB label below the integer value label, and use
snd_mixer_selem_get_playback_dB() to fill it.
I think that might be reasonable. dB markings may be impossible here...
{snip}
I don't remember why I didn't try to take
care of it,
if there was some difficulty in the actual dB numbers or
something, or probably just never got around to it.
{Much discussion elsewhere...}
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.
----------------
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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
5025
days inactive
5040
days old
linux-audio-dev@lists.linuxaudio.org
18 comments
5 participants
participants (5)
-
Clemens Ladisch -
fons＠kokkinizita.net -
Niels Mayer -
Ralf Mardorf -
Tim E. Real