[LAD] announcing envy24control, mudita (*) edition.

[LAD] announcing envy24control, mudita (*) edition.

[Niels Mayer]

Summary of updates from envy24control 0.6.0 (GIT HEAD) to "1.0.0":

(0) After a decade, incremented version to 1.0.0 (**)
(1) Implemented missing "Peak Hold" functionality in meters and
reimplemented meters for increased efficiency and lower X resource
usage. (see http://www.linuxaudio.org/mailarchive/lad/2010/7/12/171535
& https://bugzilla.redhat.com/show_bug.cgi?id=602903 )
(2) All volumes are represented as decibels, including the 0 to -48dB
range of the hardware peak-meters, the 0 -to- -144dB attenuation for
all inputs to the digital mixer, the 0 -to- -63dB attenuation of the
analog DAC, and the +18 -to- -63dB attenuation/amplification of the
analog ADC.
(3) All gtk "scale" widgets have dB legends; the "PageUp" "PageDown"
keys allow rapid movement between the marked levels.
(4) Got rid of myriad compile warnings and other minor fixes across codebase.

Some screenshots:
http://nielsmayer.com/envy24control/Screenshot-Envy24Control-AnalogVolume.png
http://nielsmayer.com/envy24control/Screenshot-Envy24Control-MonitorInputs.png
http://nielsmayer.com/envy24control/Screenshot-Envy24Control-MonitorPCM.png

------------

To the ALSA project: please consider this patch to alsa-tools'
envy24control (**):
http://nielsmayer.com/envy24control/envy24control-0.6-to-1.0.patch
(patch to 'envy24control' from GIT trunk/head of alsa-tools)
http://nielsmayer.com/envy24control/envy24control-1.0.README
(summary of changes from 0.6.0 to 1.0.0)

------------

Those wanting to compile directly, or run a 64 bit linux binary I've built:

http://nielsmayer.com/envy24control/envy24control-1.0.tar.gz
(full directory, just follow README directions to build/install)
http://nielsmayer.com/envy24control/envy24control-1.0-fc12-x86_64.tar.gz
(x86_64 binary that should work on fedora12 and equivalent OpenSuse release)

I'd appreciate any testing results or comments on this "1.0.0"
release. In particular, I'd like some assurance that the dB markings
on sliders in "Analog Volume" panel are correct (compared to values
reported by 'alsamixer'). I'm looking for testing with following
devices (as I think my testing covers code for M-Audio Delta 44 &
Delta 66, Terratec Dmx6fire & EWX2496) specifically:
  M-Audio Delta 1010, M-Audio Audiophile 2496, M-Audio Delta 1010LT
  TerraTec EWS 88MT, TerraTec EWS 88D, TerraTec Phase 88,
  Hoontech SoundTrack DSP 24 (all variants).

Thanks,

Niels
http://nielsmayer.com

PS:
(*) http://en.wikipedia.org/wiki/Envy#In_philosophy :: "mudita, taking
joy in the good fortune of another. This virtue is considered the
antidote to envy and the opposite of schadenfreude."

(**) http://git.alsa-project.org/?p=alsa-tools.git;a=tree;f=envy24control;h=d5a56728048135649314456191fe8559c4f68118;hb=HEAD

Re: [LAD] announcing envy24control, mudita (*) edition.

[Paul Davis]

On Sun, Jul 25, 2010 at 3:10 PM, Niels Mayer <nielsmayer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> (2) All volumes are represented as decibels, including the 0 to -48dB

i don't own one, so its not of much concern to me, but dB<WHAT> ?

Re: [LAD] announcing envy24control, mudita (*) edition.

[David Nielson]

>> (2) All volumes are represented as decibels, including the 0 to -48dB
>>      
> i don't own one, so its not of much concern to me, but dB<WHAT>  ?
>    
dBFS, except for the analog one, which would be dB relative to the 
previous signal strength.

David

Re: [LAD] announcing envy24control, mudita (*) edition.

[Niels Mayer]

On Sun, Jul 25, 2010 at 12:21 PM, Paul Davis <paul-dDzkXPnfpdxaomM2pvQuqZqQE7yCjDx5@public.gmane.org> wrote:
>> (2) All volumes are represented as decibels, including the 0 to -48dB
> i don't own one, so its not of much concern to me, but dB<WHAT> ?

The http://en.wikipedia.org/wiki/Decibel is a unitless measurement. :-)

However, in this case there are a few different semi-implicit
http://en.wikipedia.org/wiki/DBFS and other markings that I left off
in the name of saving on screen-real-estate and reduced redundancy.
Tooltips across-the board would be a very helpful addition to the
envy24control 1.0.0 interface. On the other hand, these are exactly
the same dB values as reported by ALSA's "amixer" and "alsamixer" so
such complaints should go upstream. :-)

Specifically:

(1) The db markings in "Analog Volumes" correspond to analog levels
that can be set for the DAC or ADC's. e.g.
0 -to- -63dB attenuation of the output of the analog DAC, and the +18
-to- -63dB attenuation/amplification of the
analog ADC. These are the exact same dB readings reported by ALSA,
e.g. "amixer -c M66":

> Simple mixer control 'ADC',0
> Limits: 0 - 163
> Mono: 163 [100%] [18.00dB]
> Simple mixer control 'ADC',1
> Limits: 0 - 163
> Mono: 163 [100%] [18.00dB]
> Simple mixer control 'ADC',2
> Limits: 0 - 163
> Mono: 152 [93%] [12.50dB]
> Simple mixer control 'ADC',3
> Limits: 0 - 163
> Mono: 152 [93%] [12.50dB]

(2) The "0 to -48dB" peak metering  levels are based on values from
hardware peak metering
(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.

When "0dBFS" reads on the peak meters in the new envy24control, it
means 0dBFS relative to these 9MSB's.  (see the red "0dBFS" labels in
http://nielsmayer.com/envy24control/Screenshot-Envy24Control-MonitorInputs.png
or http://nielsmayer.com/envy24control/Screenshot-Envy24Control-MonitorPCM.png
). Note that the signal would be able to go 7 or 15 LSB's higher
before reaching actual full-scale peak. It would be more useful if
there was a way for the hardware meters to detect actual clipping,
e.g. value=256, whereas normally the meters report values from 0-255.
For example "amixer -c M66 cget iface=PCM,name='Multi Track
Peak',numid=45" returns:
> 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

For proper metering, I suggest using Fons' excellent jkmeter with it's
nice (and free) implementation of the K-System
http://en.wikipedia.org/wiki/File:K-14_spectrafoo.jpg (caption:
"digital audio meters in the Metric Halo application, called
SpectraFoo").

(3) For the envy24's built in digital mixer, the 8PCMs + 2*SPDIF out,
and up to 8 inputs + 2SPDIF inputs, all send to the digital mixer via
24dB attenuators. Seer
http://nielsmayer.com/envy24control/envy24mixer-architecture.png for
details. Thus all mixer input sliders have "0 -to- -144dB
attenuation."

(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.

-- Niels
http://nielsmayer.com

Re: [LAD] announcing envy24control, mudita (*) edition.

[Takashi Iwai]

At Sun, 25 Jul 2010 12:10:44 -0700,
Niels Mayer wrote:
> 
> Summary of updates from envy24control 0.6.0 (GIT HEAD) to "1.0.0":
> 
> (0) After a decade, incremented version to 1.0.0 (**)
> (1) Implemented missing "Peak Hold" functionality in meters and
> reimplemented meters for increased efficiency and lower X resource
> usage. (see http://www.linuxaudio.org/mailarchive/lad/2010/7/12/171535
> & https://bugzilla.redhat.com/show_bug.cgi?id=602903 )
> (2) All volumes are represented as decibels, including the 0 to -48dB
> range of the hardware peak-meters, the 0 -to- -144dB attenuation for
> all inputs to the digital mixer, the 0 -to- -63dB attenuation of the
> analog DAC, and the +18 -to- -63dB attenuation/amplification of the
> analog ADC.
> (3) All gtk "scale" widgets have dB legends; the "PageUp" "PageDown"
> keys allow rapid movement between the marked levels.
> (4) Got rid of myriad compile warnings and other minor fixes across codebase.
> 
> Some screenshots:
> http://nielsmayer.com/envy24control/Screenshot-Envy24Control-AnalogVolume.png
> http://nielsmayer.com/envy24control/Screenshot-Envy24Control-MonitorInputs.png
> http://nielsmayer.com/envy24control/Screenshot-Envy24Control-MonitorPCM.png
> 
> ------------
> 
> To the ALSA project: please consider this patch to alsa-tools'
> envy24control (**):
> http://nielsmayer.com/envy24control/envy24control-0.6-to-1.0.patch
> (patch to 'envy24control' from GIT trunk/head of alsa-tools)
> http://nielsmayer.com/envy24control/envy24control-1.0.README
> (summary of changes from 0.6.0 to 1.0.0)

Great.  I'd love to merge it to the upstream tree after code review.

Could you simply post your patch(es) to alsa-devel ML (and Cc to
maintainers)?  Then we can check your changes.

At best, please give incremental patches containing the proper
changelog and your sign-off in the patch comments to be applicable via
git-am.

Also, avoid to change version numbers.  If you take over the whole
project, then yes, it's fine to change the major version number as you 
like.  But, as long as the upstream is alive, this may bring much more
confusion than needed.


thanks,

Takashi

Re: announcing envy24control, mudita (*) edition.

[Niels Mayer]

On Mon, Jul 26, 2010 at 1:47 AM, Takashi Iwai <tiwai@suse.de> wrote:
> Great.  I'd love to merge it to the upstream tree after code review.
>
> Could you simply post your patch(es) to alsa-devel ML (and Cc to
> maintainers)?  Then we can check your changes.

Takashi -- I am glad to hear of your interest and thankful for your
consideration. It appears that some of the code-review and testing is
already happening in linux-audio-dev (
http://linuxaudio.org/mailarchive/lad/2010/7/25/172231 ) so I will
submit a more final patch to alsa-devel, once some issues found in
testing&usability get resolved.

> At best, please give incremental patches containing the proper
> changelog and your sign-off in the patch comments to be applicable via
> git-am.

Now that I understand the correct way to submit ALSA patches, I will
follow instructions from
http://www.alsa-project.org/main/index.php/GIT_Server#Occasional_Developers
for my final ALSA submission.

> Also, avoid to change version numbers.  If you take over the whole
> project, then yes, it's fine to change the major version number as you
> like.  But, as long as the upstream is alive, this may bring much more
> confusion than needed.

In my defense of being presumptuous to change the version number,
please note that the submitted patch didn't include the autoconf
change that sets the new version number (
http://nielsmayer.com/envy24control/envy24control-0.6-to-1.0.patch ).
The "1.0.0" is in 'configure' for the source distribution (
http://nielsmayer.com/envy24control/envy24control-1.0.tar.gz ) to help
distinguish it from the standard version....

To avoid confusion for the next 1.0.1 release, I'll do something
similar, but I'll change 'configure' in the source distribution to
build "mudita24 1.0.1" rather than "envy24control 1.0.1", using the
same sources. And release as "mudita24-1.0.1" ... Then I'll submit the
final sourcecode to alsa-devel as [PATCH] results, minus the
config/naming changes. I hope this is an acceptable solution.

Thanks,

Niels
http://nielsmayer.com
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [LAD] announcing envy24control, mudita (*) edition.

[Ralf Mardorf]

Suse 11.2 amd64
TERRATEC EWX 24/96

No issues to build it.

The faders with the +4dBu -10dBV switch here are shorter too.

CPU usage when playing and showing the meters around 5%, max around 22%,
for 0.6.0 and 1.0.0. 

CPU usage when playing and moving the DAC faders for 0.6.0 it's around
30%, but for 1.0.0 it's > 60%.

I switched several times between /usr/bin/envy24control
and /usr/local/bin/envy24control and watched both CPUs by htop.

After the 'normal' output for both versions I get:

'(envy24control:9266): Gtk-WARNING **: GtkSpinButton: setting an
adjustment with non-zero page size is deprecated

(envy24control:9266): Gtk-WARNING **: GtkSpinButton: setting an
adjustment with non-zero page size is deprecated'

Hth,

Ralf

Re: [LAD] announcing envy24control, mudita (*) edition.

[Ralf Mardorf]

On Mon, 2010-07-26 at 12:13 +0200, I wrote:
> Suse 11.2 amd64
> TERRATEC EWX 24/96

> CPU usage when playing and moving the DAC faders for 0.6.0 it's around
> 30%, but for 1.0.0 it's > 60%.

Pardon.

CPU usage when playing and moving the DAC faders for 0.6.0 it's > 20% <
25%, but for 1.0.0 it's > 30% < 50%.

I did watch the complete CPU usage first, but the application's CPU
usage. I did the same mistake when I watched the meters, but regarding
to the faders the information seems to be important.

Re: [LAA] announcing envy24control, mudita (*) edition.

[john ffitch]

Any chance of an option to envy24control to allow colour blind people
to see three zones?  I had been using it for years before I was told
that there is a red section at the top and green below
==John ffitch

Re: [LAD] announcing envy24control, mudita (*) edition.

[Niels Mayer]

On Sat, Jul 31, 2010 at 12:06 PM, Tim E. Real <termtech@rogers.com> wrote:
> Niels do you have a new release or repo I can work with rather than
>  the original release, which may be too outdated to patch against by now?

http://nielsmayer.com/envy24control/mudita24-1.0.1.tar.gz
  (source directory, follow README).

Please give it a try and report on how this "release candidate" works for you.

This 1.0.1 release should fix most of the problems/gripes/bugs/errors
reported on linux-audio-devel.
New command-line options "-g 1" allow multi-channel folk to get rid of
the stereo grouping; those annoyed by the "detent" on the sliders or
the extra space taken up by the markings, use "-n" to turn off this
feature..

The main thing I haven't been able to resolve is Fons' complaint
regarding the DAC Volumes in "Analog Volume" panel not all being the
same height, due to a -10/+4 radiobox that only appears in first DAC
column for the Terratec EWS88MT; this radiobox causes the associated
slider to be shorter than the other channels. Shouldn't this radiobox
appear in all DAC columns?. Is this a regression in "mudita24" or a
feature request for standard "envy24control"? I didn't change this
aspect of the code, as far as I can tell.

-- Niels.
http://nielsmayer.com
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[fons-5YXofNvN5bf4jJi9/k9gcg]

On Sat, Jul 31, 2010 at 11:24:31PM -0700, Niels Mayer wrote:

> The main thing I haven't been able to resolve is Fons' complaint
> regarding the DAC Volumes in "Analog Volume" panel not all being the
> same height, due to a -10/+4 radiobox that only appears in first DAC
> column for the Terratec EWS88MT; this radiobox causes the associated
> slider to be shorter than the other channels. Shouldn't this radiobox
> appear in all DAC columns?.

No, it's one switch for all channels.

> Is this a regression in "mudita24" or a feature request for standard
> "envy24control"? I didn't change this  aspect of the code, as far as
> I can tell.

The original has the same problem. Don't waste your time with it
unless someone else thinks it matters. As said I have fixed levels
on all channels, I don't ever use the mixer (as the card is connected
to a real mixer anyway), and everything is initialised by an alsactl
restore on booting. So in practice I never use envy24control. 

Apart from that, I just don't understand why I toolkit like GTK
apparently makes it difficult to  get such a simple thing right.
Same for the faders. 

Ciao,

-- 
FA

There are three of them, and Alleline.

Re: [LAD] announcing envy24control, mudita (*) edition.

[Niels Mayer]

On Sun, Aug 1, 2010 at 3:54 PM,  <fons@kokkinizita.net> wrote:
>> Is this a regression in "mudita24" or a feature request for standard
>> "envy24control"? I didn't change this  aspect of the code, as far as
>> I can tell.
>
> The original has the same problem.

Well that's "good" to hear, in the sense that I didn't cause a
regression for which there was no way to predict how i could have
caused, it, from the changes made. (Another bug I know of
https://bugzilla.redhat.com/show_bug.cgi?id=602900 )

However your complaint  forced me to look at the code enough that it
would be a pretty easy fix. I'd special case for "dac_senses==1"
(apparently an unfortunate shorthand for dac sensitivity adjust), and
"adc_senses==1". For that condition, I'd lay out the radiobutton first
as the leftmost column, and afterwards all the sliders for the DACs,
and then if same for ADC's, again same way.

If there's multiple adc_senses and dac_senses (i don't know if there
are ice1712 card models that do this, but i'd hope that is the case,
as one normally has a mixture of consumer and pro devices to hookup)
then the original code putting a dac/adc sensitivity radiobutton under
each associated slider would kick-in.

Since I don't have the card to test this aspect, hopefully someone
from ALSA will comment on why things are the way they are. Because it
might also be just as well to leave the code as-is and not cause
regressions on cards we might not be able to test on (or even find:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=230506172001 ).

-- Niels
http://nielsmayer.com
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [LAD] announcing envy24control, mudita (*) edition.

[Niels Mayer]

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.html
> [...] 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

Re: [LAD] announcing envy24control, mudita (*) edition.

[Raymond Yau]

2010/8/4 Niels Mayer <nielsmayer@gmail.com>

> 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 ).
>

./envy24control -Ddefault

card_number = atoi(strchr(name, ':') + sizeof(char));

This bug seem still occur when name does not contain ":" since ctl device is
"hw:n" where n is card number

http://git.alsa-project.org/?p=alsa-tools.git;a=blobdiff;f=envy24control/envy24control.c;h=c7ee4daf54ddb69d0a90636ed157bb81ba019671;hp=3cbf154c959d1882dff8753bc31dd51bd56a52f9;hb=8d4747de3c96c25688a3a5cdcfd56ed3035f5a55;hpb=2115618facbbc88a7323f3f0d6a7780e311408d2

Re: [LAD] [alsa-devel] announcing envy24control, mudita (*) edition.

[Niels Mayer]

On Tue, Aug 3, 2010 at 10:38 PM, Raymond Yau
<superquad.vortex2@gmail.com> wrote:
> 2010/8/4 Niels Mayer <nielsmayer@gmail.com>
>>   * fixed --card and --device to allow valid ALSA names and numbers
>>        ( https://bugzilla.redhat.com/show_bug.cgi?id=602900 ).
>
> ./envy24control -Ddefault
>
> card_number = atoi(strchr(name, ':') + sizeof(char));
>
> This bug seem still occur when name does not contain ":" since ctl device is
> "hw:n" where n is card number

I used similar code to what's in alsamixer to perform the same
functions as the old broken code. Now the code behaves as follows:

gnulem-238-~> envy24control -Dhw:default
envy24control: invalid ALSA audio device, invalid index or name for
card: hw:default
gnulem-239-~> envy24control -Dhw:M66
using	 --- input_channels: 4
	 --- output_channels: 4
	 --- pcm_output_channels: 8
	 --- spdif in/out channels: 2
gnulem-240-~> envy24control -Dhw:M66.0
envy24control: invalid ALSA audio device, invalid index or name for
card: hw:M66.0
gnulem-241-~> envy24control -Dhw:M66,0
envy24control: invalid ALSA audio device, invalid index or name for
card: hw:M66,0
gnulem-242-~> envy24control -DM66
envy24control: ALSA audio device syntax expects ':' character: M66


Current code:

	while ((c = getopt_long(argc, argv, "D:c:f:i:m:Mo:p:s:w:vt:ng:",
long_options, NULL)) != -1) {
		switch (c) {
		case 'D':
			name = optarg;
			if (!index(name, ':')) {
			  fprintf(stderr, "envy24control: ALSA audio device syntax expects
':' character: %s\n", optarg);
			  exit(1);
			}
			card_number = snd_card_get_index(strchr(name, ':') + sizeof(char));
/* NPM: use correct ALSA-specific call to fix
https://bugzilla.redhat.com/show_bug.cgi?id=602900  */
			if (card_number < 0) {		/* NPM: code orig from alsa-utils/alsamixer/cli.c */
			  fprintf(stderr, "envy24control: invalid ALSA audio device,
invalid index or name for card: %s\n", optarg);
			  exit(1);
			}
			break;
		case 'c':
			card_number = snd_card_get_index(optarg); /* NPM: use correct
ALSA-specific call to fix
https://bugzilla.redhat.com/show_bug.cgi?id=602900  */
			if (card_number < 0) {		/* NPM: code orig from alsa-utils/alsamixer/cli.c */
				fprintf(stderr, "envy24control: invalid ALSA index or name for
audio card: %s\n", optarg);
				exit(1);
			}
			sprintf(tmpname, "hw:%d", card_number);
			name = tmpname;
			break;

-- Niels
http://nielsmayer.com
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Raymond Yau]

2010/8/4 Niels Mayer <nielsmayer@gmail.com>

> On Tue, Aug 3, 2010 at 10:38 PM, Raymond Yau
> <superquad.vortex2@gmail.com> wrote:
> > 2010/8/4 Niels Mayer <nielsmayer@gmail.com>
> >>   * fixed --card and --device to allow valid ALSA names and numbers
> >>        ( https://bugzilla.redhat.com/show_bug.cgi?id=602900 ).
> >
> > ./envy24control -Ddefault
> >
> > card_number = atoi(strchr(name, ':') + sizeof(char));
> >
> > This bug seem still occur when name does not contain ":" since ctl device
> is
> > "hw:n" where n is card number
>
> I used similar code to what's in alsamixer to perform the same
> functions as the old broken code. Now the code behaves as follows:
>
> gnulem-238-~> envy24control -Dhw:default
> envy24control: invalid ALSA audio device, invalid index or name for
> card: hw:default
> gnulem-239-~> envy24control -Dhw:M66
> using    --- input_channels: 4
>         --- output_channels: 4
>         --- pcm_output_channels: 8
>         --- spdif in/out channels: 2
> gnulem-240-~> envy24control -Dhw:M66.0
> envy24control: invalid ALSA audio device, invalid index or name for
> card: hw:M66.0
> gnulem-241-~> envy24control -Dhw:M66,0
> envy24control: invalid ALSA audio device, invalid index or name for
> card: hw:M66,0
> gnulem-242-~> envy24control -DM66
> envy24control: ALSA audio device syntax expects ':' character: M66
>
>
The "-D" option seem to be used similar to  "amixer -Dabc"

ctl.abc {

   type hw
   card 2
}

Re: [LAD] [alsa-devel] announcing envy24control, mudita (*) edition.

[Niels Mayer]

[-- Attachment #1: Type: text/plain, Size: 5631 bytes --]

On Wed, Aug 4, 2010 at 1:20 AM, Raymond Yau <superquad.vortex2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> The "-D" option seem to be used similar to  "amixer -Dabc"
> ctl.abc {  type hw ,  card 2 }

Raymond --

Thanks for the clarification regarding the use of the -D argument for
alsa control devices. I've updated my code to handle things in the
same way that amixer does. The diffs for this change are at the end of
this message, and attached. ALSA names for examples/tests below from
http://nielsmayer.com/npm/dot-asoundrc.txt ....

.........................................
gnulem-277-~> /usr/bin/envy24control -D66    ##behavior on current
head and latest stable release
Segmentation fault (core dumped)
gnulem-278-~> envy24control -D66                ##behavior using this patch ...
using	 --- input_channels: 4
gnulem-279-~> envy24control -D666
ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL 666
envy24control: cannot open mixer: No such file or directory - '666'
gnulem-280-~> envy24control -Dhw:66
envy24control: invalid ALSA audio device, invalid index or name for card: hw:66
gnulem-281-~> envy24control -Dhw:M66
using	 --- input_channels: 4
gnulem-282-~> envy24control -Dmulti
invalid card type (driver is HDA-Intel)
gnulem-283-~> envy24control -Ddefault
invalid card type (driver is USB-Audio)
gnulem-284-~> envy24control -c default
envy24control: invalid ALSA index or name for audio card: default
gnulem-285-~> envy24control -c SB
invalid card type (driver is HDA-Intel)
gnulem-286-~> envy24control -c multi
envy24control: invalid ALSA index or name for audio card: multi
gnulem-287-~> envy24control -c M66
using	 --- input_channels: 4
gnulem-299-~> amixer -Dhw:/dev/snd/controlC2 >! /tmp/foo
gnulem-301-~> amixer -D/dev/snd/controlC2 > ! /tmp/foo
ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL /dev/snd/controlC2
amixer: Mixer attach /dev/snd/controlC2 error: No such file or directory
gnulem-290-~> envy24control -D/dev/snd/controlC2
ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL /dev/snd/controlC2
envy24control: cannot open mixer: No such file or directory -
'/dev/snd/controlC2'

.........................................

diff --git a/envy24control/envy24control.c b/envy24control/envy24control.c
index 0b2749e..e5d89d0 100644
--- a/envy24control/envy24control.c
+++ b/envy24control/envy24control.c
@@ -2084,3 +2166,3 @@ int main(int argc, char **argv)
 	view_spdif_playback = 0;
 	profiles_file_name = DEFAULT_PROFILERC;
 	default_profile = NULL;
	while ((c = getopt_long(argc, argv, "D:c:f:i:m:Mo:p:s:w:vt:",
long_options, NULL)) != -1) {
 		switch (c) {
 		case 'D':
-			name = optarg;
-			card_number = atoi(strchr(name, ':') + sizeof(char));
-			if (card_number < 0 || card_number >= MAX_CARD_NUMBERS) {
-				fprintf(stderr, "envy24control: invalid card number %d\n", card_number);
-				exit(1);
+			/* NPM: old code assumed ':' present, e.g. "-Dhw:66",
+			 * (w/ .asoundrc "ctl.66 {type hw, card M66}") and would
+			 * coredump if given "-D66". Prevent the coredump and even
+			 * handle latter case even if keying off ':' is not a
+			 * good way to do this. Note that for snd_card_get_index()
+			 * "The accepted format is an integer value in ASCII
representation or the card
+			 * identifier (the id parameter for sound-card drivers). The control device
+			 * name like /dev/snd/controlC0 is accepted, too." */
+			if (!index(optarg, ':')) {
+			  /* NPM: unlike old envy24control code, but behaving like amixer et al,
+			     "-D66" is valid. Handle it. */
+			  snd_mixer_t *mixer;
+			  struct snd_mixer_selem_regopt selem_regopt = {
+			    .ver = 1,
+			    .abstract = SND_MIXER_SABSTRACT_NONE,
+			    .device = optarg,
+			  };
+			  if ((err = snd_mixer_open(&mixer, 0)) < 0) {
+			    fprintf(stderr, "envy24control: cannot open mixer: %s -
'%s'\n", snd_strerror(err), optarg);
+			    exit(1);
+			  }
+			  if ((err = snd_mixer_selem_register(mixer, &selem_regopt, NULL)) < 0) {
+			    fprintf(stderr, "envy24control: cannot open mixer: %s -
'%s'\n", snd_strerror(err), optarg);
+			    exit(1);
+			  }
+			  name = optarg; /* NPM: now that device name validated,  e.g.
pass "-D66" unaltered to snd_ctl_open()... */
+			}
+			else {
+			  /* NPM: handle e.g. optarg == "hw:M66" */
+			  card_number = snd_card_get_index(strchr(optarg, ':') +
sizeof(char)); /* NPM: use correct ALSA-specific call to fix
https://bugzilla.redhat.com/show_bug.cgi?id=602900  */
+			  if (card_number < 0) {
+			    fprintf(stderr, "envy24control: invalid ALSA audio device,
invalid index or name for card: %s\n", optarg);
+			    exit(1);
+			  }
+			  name = optarg; /* e.g. optarg == "hw:M66" passed to
snd_ctl_open() below */
 			}
 			break;
 		case 'c':
-			i = atoi(optarg);
-			if (i < 0 || i >= MAX_CARD_NUMBERS) {
-				fprintf(stderr, "envy24control: invalid card number %d\n", i);
+			card_number = snd_card_get_index(optarg); /* NPM: use correct
ALSA-specific call to fix
https://bugzilla.redhat.com/show_bug.cgi?id=602900  */
+			if (card_number < 0) {		/* NPM: code orig from alsa-utils/alsamixer/cli.c */
+				fprintf(stderr, "envy24control: invalid ALSA index or name for
audio card: %s\n", optarg);
 				exit(1);
 			}
-			card_number = i;
-			sprintf(tmpname, "hw:%d", i);
+			sprintf(tmpname, "hw:%d", card_number); /* e.g. "hw:M66" for arg
"-cM66" passed to snd_ctl_open() below */
 			name = tmpname;
 			break;
 		case 'f':

.........................................

--Niels
http://nielsmayer.com

[-- Attachment #2: fix-alsa-ctl-device-params.patch --]
[-- Type: text/x-patch, Size: 3235 bytes --]

diff --git a/envy24control/envy24control.c b/envy24control/envy24control.c
index 0b2749e..e5d89d0 100644
--- a/envy24control/envy24control.c
+++ b/envy24control/envy24control.c
@@ -2084,3 +2166,3 @@ int main(int argc, char **argv)
 	view_spdif_playback = 0;
 	profiles_file_name = DEFAULT_PROFILERC;
 	default_profile = NULL;
	while ((c = getopt_long(argc, argv, "D:c:f:i:m:Mo:p:s:w:vt:", long_options, NULL)) != -1) {
 		switch (c) {
 		case 'D':
-			name = optarg;
-			card_number = atoi(strchr(name, ':') + sizeof(char));
-			if (card_number < 0 || card_number >= MAX_CARD_NUMBERS) {
-				fprintf(stderr, "envy24control: invalid card number %d\n", card_number);
-				exit(1);
+			/* NPM: old code assumed ':' present, e.g. "-Dhw:66",
+			 * (w/ .asoundrc "ctl.66 {type hw, card M66}") and would
+			 * coredump if given "-D66". Prevent the coredump and even
+			 * handle latter case even if keying off ':' is not a 
+			 * good way to do this. Note that for snd_card_get_index()
+			 * "The accepted format is an integer value in ASCII representation or the card
+			 * identifier (the id parameter for sound-card drivers). The control device
+			 * name like /dev/snd/controlC0 is accepted, too." */
+			if (!index(optarg, ':')) { 
+			  /* NPM: unlike old envy24control code, but behaving like amixer et al,
+			     "-D66" is valid. Handle it. */
+			  snd_mixer_t *mixer;
+			  struct snd_mixer_selem_regopt selem_regopt = {
+			    .ver = 1,
+			    .abstract = SND_MIXER_SABSTRACT_NONE,
+			    .device = optarg,
+			  };
+			  if ((err = snd_mixer_open(&mixer, 0)) < 0) {
+			    fprintf(stderr, "envy24control: cannot open mixer: %s - '%s'\n", snd_strerror(err), optarg);
+			    exit(1);
+			  }
+			  if ((err = snd_mixer_selem_register(mixer, &selem_regopt, NULL)) < 0) {
+			    fprintf(stderr, "envy24control: cannot open mixer: %s - '%s'\n", snd_strerror(err), optarg);
+			    exit(1);
+			  }
+			  name = optarg; /* NPM: now that device name validated,  e.g. pass "-D66" unaltered to snd_ctl_open()... */
+			}
+			else {
+			  /* NPM: handle e.g. optarg == "hw:M66" */
+			  card_number = snd_card_get_index(strchr(optarg, ':') + sizeof(char)); /* NPM: use correct ALSA-specific call to fix https://bugzilla.redhat.com/show_bug.cgi?id=602900  */
+			  if (card_number < 0) {
+			    fprintf(stderr, "envy24control: invalid ALSA audio device, invalid index or name for card: %s\n", optarg);
+			    exit(1);
+			  }
+			  name = optarg; /* e.g. optarg == "hw:M66" passed to snd_ctl_open() below */
 			}
 			break;
 		case 'c':
-			i = atoi(optarg);
-			if (i < 0 || i >= MAX_CARD_NUMBERS) {
-				fprintf(stderr, "envy24control: invalid card number %d\n", i);
+			card_number = snd_card_get_index(optarg); /* NPM: use correct ALSA-specific call to fix https://bugzilla.redhat.com/show_bug.cgi?id=602900  */
+			if (card_number < 0) {		/* NPM: code orig from alsa-utils/alsamixer/cli.c */
+				fprintf(stderr, "envy24control: invalid ALSA index or name for audio card: %s\n", optarg);
 				exit(1);
 			}
-			card_number = i;
-			sprintf(tmpname, "hw:%d", i);
+			sprintf(tmpname, "hw:%d", card_number); /* e.g. "hw:M66" for arg "-cM66" passed to snd_ctl_open() below */
 			name = tmpname;
 			break;
 		case 'f':

[-- Attachment #3: Type: text/plain, Size: 196 bytes --]

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev-cunTk1MwBs/CEJeg2xFRV2D2FQJk+8+b@public.gmane.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Niels Mayer]

[-- Attachment #1: Type: text/plain, Size: 3253 bytes --]

Actually, there's a much simpler version of this patch, since the
previous code provided some extra validation and pretty error
messages, but no information that couldn't be provided by
snd_ctl_open(), e.g.:
....
gnulem-336-~> envy24control -Dfoo
ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL foo
snd_ctl_open: No such file or directory
....

diff --git a/envy24control/envy24control.c b/envy24control/envy24control.c
index 0b2749e..3798ba3 100644
--- a/envy24control/envy24control.c
+++ b/envy24control/envy24control.c
@@ -2084,24 +2166,50 @@ int main(int argc, char **argv)
 	view_spdif_playback = 0;
 	profiles_file_name = DEFAULT_PROFILERC;
 	default_profile = NULL;
	while ((c = getopt_long(argc, argv, "D:c:f:i:m:Mo:p:s:w:vt:",
long_options, NULL)) != -1) {
 		switch (c) {
 		case 'D':
-			name = optarg;
-			card_number = atoi(strchr(name, ':') + sizeof(char));
-			if (card_number < 0 || card_number >= MAX_CARD_NUMBERS) {
-				fprintf(stderr, "envy24control: invalid card number %d\n", card_number);
-				exit(1);
-			}
+		/*
+		 * NPM: use ALSA code to fix/validate
+		 * https://bugzilla.redhat.com/show_bug.cgi?id=602900
+		 * The old code assumed ':' present, e.g. "-Dhw:66", (w/
+		 * .asoundrc "ctl.66 {type hw, card M66}") and would
+		 * coredump if given "-D66". Here, by not worrying about
+		 * "hw:" and passing "optarg" as-is via 'name' to
+		 * snd_ctl_open() below, resolves the issue, giving similar
+		 * behavior as 'amixer'.  However, letting snd_ctl_open()
+		 * validate gives less helpful error messages on
+		 * failure: "envy24control -Dhw:foo"
+		 *           ==> "snd_ctl_open: No such device"
+		 * So validate the arg as ALSA CTL, providing
+		 * a more specific error message and fail first if not valid.
+		 */
+			name = optarg; /* NPM: e.g. pass "-D66" unaltered to
snd_ctl_open() and let it validate valid ALSA CTL name */
+			if (index(optarg, ':')) { /* NPM: handle e.g. optarg == "hw:M66" */
+			    card_number = snd_card_get_index(strchr(optarg, ':') + sizeof(char));
+			    if (card_number < 0) {
+			      fprintf(stderr, "envy24control: invalid ALSA audio device,
invalid index or name for card: %s\n", optarg);
+			      exit(1);
+			    }
+			  }
 			break;
 		case 'c':
-			i = atoi(optarg);
-			if (i < 0 || i >= MAX_CARD_NUMBERS) {
-				fprintf(stderr, "envy24control: invalid card number %d\n", i);
+	        /*
+		  NPM: use snd_card_get_index() to fix/validate
+		  https://bugzilla.redhat.com/show_bug.cgi?id=602900
+		 * NPM: nb :"The accepted format is
+		 * an integer value in ASCII representation or the card
+		 * identifier (the id parameter for sound-card
+		 * drivers). The control device name like
+		 * /dev/snd/controlC0 is accepted, too."
+		 */
+			card_number = snd_card_get_index(optarg);
+			if (card_number < 0) {		/* NPM: code orig from alsa-utils/alsamixer/cli.c */
+				fprintf(stderr, "envy24control: invalid ALSA index or name for
audio card: %s\n", optarg);
 				exit(1);
 			}
-			card_number = i;
-			sprintf(tmpname, "hw:%d", i);
+			sprintf(tmpname, "hw:%d", card_number); /* e.g. "hw:M66" for arg
"-cM66" passed to snd_ctl_open() below */
 			name = tmpname;
 			break;
 		case 'f':

...................................

Niels
http://nielsmayer.com

[-- Attachment #2: fix-alsa-ctl-device-params.patch --]
[-- Type: text/x-patch, Size: 2831 bytes --]

diff --git a/envy24control/envy24control.c b/envy24control/envy24control.c
index 0b2749e..3798ba3 100644
--- a/envy24control/envy24control.c
+++ b/envy24control/envy24control.c
@@ -2084,24 +2166,50 @@ int main(int argc, char **argv)
 	view_spdif_playback = 0;
 	profiles_file_name = DEFAULT_PROFILERC;
 	default_profile = NULL;
	while ((c = getopt_long(argc, argv, "D:c:f:i:m:Mo:p:s:w:vt:", long_options, NULL)) != -1) {
 		switch (c) {
 		case 'D':
-			name = optarg;
-			card_number = atoi(strchr(name, ':') + sizeof(char));
-			if (card_number < 0 || card_number >= MAX_CARD_NUMBERS) {
-				fprintf(stderr, "envy24control: invalid card number %d\n", card_number);
-				exit(1);
-			}
+		/*
+		 * NPM: use ALSA code to fix/validate
+		 * https://bugzilla.redhat.com/show_bug.cgi?id=602900
+		 * The old code assumed ':' present, e.g. "-Dhw:66", (w/
+		 * .asoundrc "ctl.66 {type hw, card M66}") and would
+		 * coredump if given "-D66". Here, by not worrying about
+		 * "hw:" and passing "optarg" as-is via 'name' to
+		 * snd_ctl_open() below, resolves the issue, giving similar
+		 * behavior as 'amixer'.  However, letting snd_ctl_open()
+		 * validate gives less helpful error messages on
+		 * failure: "envy24control -Dhw:foo"
+		 *           ==> "snd_ctl_open: No such device"
+		 * So validate the arg as ALSA CTL, providing
+		 * a more specific error message and fail first if not valid.
+		 */
+			name = optarg; /* NPM: e.g. pass "-D66" unaltered to snd_ctl_open() and let it validate valid ALSA CTL name */
+			if (index(optarg, ':')) { /* NPM: handle e.g. optarg == "hw:M66" */
+			    card_number = snd_card_get_index(strchr(optarg, ':') + sizeof(char));
+			    if (card_number < 0) {
+			      fprintf(stderr, "envy24control: invalid ALSA audio device, invalid index or name for card: %s\n", optarg);
+			      exit(1);
+			    }
+			  }
 			break;
 		case 'c':
-			i = atoi(optarg);
-			if (i < 0 || i >= MAX_CARD_NUMBERS) {
-				fprintf(stderr, "envy24control: invalid card number %d\n", i);
+	        /*
+		  NPM: use snd_card_get_index() to fix/validate
+		  https://bugzilla.redhat.com/show_bug.cgi?id=602900
+		 * NPM: nb :"The accepted format is
+		 * an integer value in ASCII representation or the card
+		 * identifier (the id parameter for sound-card
+		 * drivers). The control device name like
+		 * /dev/snd/controlC0 is accepted, too."
+		 */
+			card_number = snd_card_get_index(optarg);
+			if (card_number < 0) {		/* NPM: code orig from alsa-utils/alsamixer/cli.c */
+				fprintf(stderr, "envy24control: invalid ALSA index or name for audio card: %s\n", optarg);
 				exit(1);
 			}
-			card_number = i;
-			sprintf(tmpname, "hw:%d", i);
+			sprintf(tmpname, "hw:%d", card_number); /* e.g. "hw:M66" for arg "-cM66" passed to snd_ctl_open() below */
 			name = tmpname;
 			break;
 		case 'f':

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [LAD] announcing envy24control, mudita (*) edition.

[Niels Mayer]

On Wed, Aug 4, 2010 at 12:00 PM, Tim E. Real <termtech@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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev