Alsamixer-Qt4 0.4.0 released

Alsamixer-Qt4 0.4.0 released

[Sebastian H.]

Hello everyone

I've been working on Alsamixer-Qt4 lately and compiled
the changes into a new release version 0.4.0.
Most importantly the cards list can be refreshed now
and the style got a little overhaul, too.
A more detailed changelog can be found at the xwmw.org page.

The new version 0.4.0 is available at the known places.
http://xwmw.org/alsamixer-qt4/
http://sourceforge.net/projects/alsamixer-qt4/files/

Any comments are welcome.

Cheers,
Sebastian

Re: Alsamixer-Qt4 0.4.0 released

[errordeveloper]

it crashes on my machine with one USB soundcard,
and an RME Hammerfall ..i think RME causes it -
i get a `Floating exception` ..hm, not a segfault this time :)

..i can do some tests ..have you got an svn or git?
basically RME alsa driver is different from all other drivers,
so far i only see one mixer that presented snd-hdsp options
in correct way ..it's mostly just tick boxes..
i'd say that you can just try to set up a condition
that if the card is RME, then just ignore that card :)
..otherwise check hdspmixer and hdspconf in alsa-tools.

On Wed, Aug 04, 2010 at 02:17:22PM +0200, Sebastian H. wrote:
> Hello everyone
> 
> I've been working on Alsamixer-Qt4 lately and compiled
> the changes into a new release version 0.4.0.
> Most importantly the cards list can be refreshed now
> and the style got a little overhaul, too.
> A more detailed changelog can be found at the xwmw.org page.
> 
> The new version 0.4.0 is available at the known places.
> http://xwmw.org/alsamixer-qt4/
> http://sourceforge.net/projects/alsamixer-qt4/files/
> 
> Any comments are welcome.
> 
> Cheers,
> Sebastian
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Alsamixer-Qt4 0.4.0 released

[Raymond Yau]

2010/8/4 Sebastian H. <vand2@gmx.de>

> Hello everyone
>
> I've been working on Alsamixer-Qt4 lately and compiled
> the changes into a new release version 0.4.0.
> Most importantly the cards list can be refreshed now
> and the style got a little overhaul, too.
> A more detailed changelog can be found at the xwmw.org page.
>
> The new version 0.4.0 is available at the known places.
> http://xwmw.org/alsamixer-qt4/
> http://sourceforge.net/projects/alsamixer-qt4/files/
>
> Any comments are welcome.
>

1) au8830 Equalizer
you can find the screenshot of the equalizer ( gnome volume control) and the
correct implementation of the equalizer of the vortexcontrol and python
version of the equalizer

the asound.state of au8830

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3678



2) CMI8788 's 8 Channels Master Volume Control

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4204

Card hw:0 'CMI8788'/'C-Media Oxygen HD Audio (rev 2) at 0xec00, irq 17'

  Mixer name	: 'CMI8788'
  Components	: 'AK4396 AK5385 CMI8788'
  Controls      : 23
  Simple ctrls  : 12
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right - Rear Left - Rear Right
- Front Center - Woofer - Side Left - Side Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 112 [44%] [-7.14dB] [on]
  Front Right: Playback 112 [44%] [-7.14dB] [on]
  Rear Left: Playback 178 [70%] [-3.12dB] [on]
  Rear Right: Playback 178 [70%] [-3.12dB] [on]
  Front Center: Playback 178 [70%] [-3.12dB] [on]
  Woofer: Playback 178 [70%] [-3.12dB] [on]
  Side Left: Playback 178 [70%] [-3.12dB] [on]
  Side Right: Playback 178 [70%] [-3.12dB] [on]


state.CMI8788 {
	control.1 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 8
		comment.range '0 - 255'
		comment.dbmin -9999999
		comment.dbmax 0
		iface MIXER
		name 'Master Playback Volume'
		value.0 112
		value.1 112
		value.2 178
		value.3 178
		value.4 178
		value.5 178
		value.6 178
		value.7 178
	}

Re: Alsamixer-Qt4 0.4.0 released

[The Source]

  04.08.2010 16:17, Sebastian H. пишет:
> Hello everyone
>
> I've been working on Alsamixer-Qt4 lately and compiled
> the changes into a new release version 0.4.0.
> Most importantly the cards list can be refreshed now
> and the style got a little overhaul, too.
> A more detailed changelog can be found at the xwmw.org page.
>
> The new version 0.4.0 is available at the known places.
> http://xwmw.org/alsamixer-qt4/
> http://sourceforge.net/projects/alsamixer-qt4/files/
>
> Any comments are welcome.
>
> Cheers,
> Sebastian
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
I know that mixer probably isn't the best place to implement this but it 
would be nice to see a simple ~/.asoundrc editor,
so user can add/modify/remove/set default devices. For example, 
configure plugs, dmixes, dsnoops, asyms using a GUI rather than text editor.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Alsamixer-Qt4 0.4.0 released

[Sebastian H.]

Am 05.08.2010 01:33, schrieb errordeveloper@gmail.com:
> it crashes on my machine with one USB soundcard,
> and an RME Hammerfall ..i think RME causes it -
> i get a `Floating exception` ..hm, not a segfault this time :)

This looks like a bug in the slider/painter code.
Maybe some ranges are screwed, like 0 to 0 or so and the slider
can't handle it.
A gdb backtrace would be helpful.
Could you compile with:

cmake -DCMAKE_BUILD_TYPE=Debug
make

and then create a backtrace with gdb:

echo -e "run\nwhere\nquit" > gdb_com.txt
gdb src/alsamixer-qt4 -batch -x gdb_com.txt > gdb.txt

and send me the gdb.txt file?

> ..i can do some tests ..have you got an svn or git?

Right now I only have a mercurial repository on my local machine.
I think sourceforge support mercurial now, I'll check on this later.

> basically RME alsa driver is different from all other drivers,
> so far i only see one mixer that presented snd-hdsp options
> in correct way ..it's mostly just tick boxes..
> i'd say that you can just try to set up a condition
> that if the card is RME, then just ignore that card :)
> ..otherwise check hdspmixer and hdspconf in alsa-tools.

I would like to avoid keeping a blacklist in the mixer application.
It's meant to be a general purpose mixer but it should'n crash on high
end hardware.

Sebastian

Re: Alsamixer-Qt4 0.4.0 released

[Sebastian H.]

Hello Raymond

>> I've been working on Alsamixer-Qt4 lately and compiled
>> the changes into a new release version 0.4.0.
> 
> 1) au8830 Equalizer
> you can find the screenshot of the equalizer ( gnome volume control) and the
> correct implementation of the equalizer of the vortexcontrol and python
> version of the equalizer
> 
> the asound.state of au8830
> 
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3678

Ok, I tried to figure out how this relates to alsamixer-qt4 (since I
don't have the sound card).

Please correct me if I'm wrong.

The "EQ Peaks" Simple Mixer Element has more channels than the 9
channels described in the snd_mixer_selem_channel_id_t enum.
( SND_MIXER_SCHN_FRONT_LEFT up to SND_MIXER_SCHN_REAR_CENTER ).

http://www.alsa-project.org/alsa-doc/alsa-lib/group___simple_mixer.html#g9cb8437b2f92d168c43e4da2c667e823

Alsamixer-Qt4 currently can only show these 9 channels - in the channels
mixer dialog - which is not sufficient.

I did not find a function like snd_mixer_selem_playback_channels
which would return the number of channels.
So to find out how many channels there actually are I would have to do
something like this

int num_playback = 0;
for ( int ii=0; ii < 1024; ++ii ) {
	if ( snd_mixer_selem_has_playback_channel ( elem, ii ) ) {
		num_playback += 1;
	} else {
		break;
	}
}



> 2) CMI8788 's 8 Channels Master Volume Control
> 
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4204
> 
> Card hw:0 'CMI8788'/'C-Media Oxygen HD Audio (rev 2) at 0xec00, irq 17'
> 
>   Mixer name	: 'CMI8788'
>   Components	: 'AK4396 AK5385 CMI8788'
>   Controls      : 23
>   Simple ctrls  : 12
> Simple mixer control 'Master',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right - Rear Left - Rear Right
> - Front Center - Woofer - Side Left - Side Right
>   Limits: Playback 0 - 255
>   Mono:
>   Front Left: Playback 112 [44%] [-7.14dB] [on]
>   Front Right: Playback 112 [44%] [-7.14dB] [on]
>   Rear Left: Playback 178 [70%] [-3.12dB] [on]
>   Rear Right: Playback 178 [70%] [-3.12dB] [on]
>   Front Center: Playback 178 [70%] [-3.12dB] [on]
>   Woofer: Playback 178 [70%] [-3.12dB] [on]
>   Side Left: Playback 178 [70%] [-3.12dB] [on]
>   Side Right: Playback 178 [70%] [-3.12dB] [on]
> 
> 
> state.CMI8788 {
> 	control.1 {
> 		comment.access 'read write'
> 		comment.type INTEGER
> 		comment.count 8
> 		comment.range '0 - 255'
> 		comment.dbmin -9999999
> 		comment.dbmax 0
> 		iface MIXER
> 		name 'Master Playback Volume'
> 		value.0 112
> 		value.1 112
> 		value.2 178
> 		value.3 178
> 		value.4 178
> 		value.5 178
> 		value.6 178
> 		value.7 178
> 	}

Basically the same issue?

Best,
Sebastian

Re: Alsamixer-Qt4 0.4.0 released

[Raymond Yau]

2010/8/5 Sebastian H. <vand2@gmx.de>

> Hello Raymond
>
> >> I've been working on Alsamixer-Qt4 lately and compiled
> >> the changes into a new release version 0.4.0.
> >
> > 1) au8830 Equalizer
> > you can find the screenshot of the equalizer ( gnome volume control) and
> the
> > correct implementation of the equalizer of the vortexcontrol and python
> > version of the equalizer
> >
> > the asound.state of au8830
> >
> > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3678
>
> Ok, I tried to figure out how this relates to alsamixer-qt4 (since I
> don't have the sound card).
>
> Please correct me if I'm wrong.
>
> The "EQ Peaks" Simple Mixer Element has more channels than the 9
> channels described in the snd_mixer_selem_channel_id_t enum.
> ( SND_MIXER_SCHN_FRONT_LEFT up to SND_MIXER_SCHN_REAR_CENTER ).
>

EQ Peaks is a  volatile control without write access  (i.e. you cannot use
slider since you cannot modify the value ) which provide the peak of  10
bands (31Hz, 63Hz, 125Hz, 250Hz, 500Hz, 1Kz, 2Kz, 4Kz, 8Kz , 16Kz) stereo
channels of the au8830's hardware equalizer  ,  ( one stereo vu-meters at
each band )

The values are ordered  by left channel of 10 bands followed by right
channel of 10 bands


 control.12 {
        comment.access read
        comment.type INTEGER
        comment.count 20
        comment.range '0 - 32767'
        iface MIXER
        name 'EQ Peaks'
        value.0 1
        value.1 1
        value.2 0
        value.3 0
        value.4 1
        value.5 1
        value.6 1
        value.7 1
        value.8 0
        value.9 0
        value.10 1
        value.11 1
        value.12 0
        value.13 0
        value.14 0
        value.15 0
        value.16 1
        value.17 1
        value.18 0
        value.19 0
    }

EQ enable switch control the output of DSP pass through/bypass the equalizer
,
so your application can based on the on/off state of the switch to
start/stop a timer which  read the value from EQ peak control and display on
10 stereo vu-meters at regular time intervals

There are also 10  stereo volume controls to control gain/atten of 10 bands
of the hardware equalizer

if your application are unable to display EQ peaks , it is better to skip
this "EQ peaks" control with count =20 or simple mixer control with 20
channels

All the EQ controls appear on capture side is a bug of alsa-lib or the
driver , either change the name of those  "EQ xx" controls to "EQ xx
Playback" in the driver or add "EQ" to the definition of the controls name


Simple mixer control 'EQ Peaks',0
  Capabilities: volume
  Playback channels: Front Left - Front Right - Rear Left - Rear Right -
Front Center - Woofer - Side Left - Side Right - Rear Center - ? - ? - ? - ?
- ? - ? - ? - ? - ? - ? - ?
  Capture channels: Front Left - Front Right - Rear Left - Rear Right -
Front Center - Woofer - Side Left - Side Right - Rear Center - ? - ? - ? - ?
- ? - ? - ? - ? - ? - ? - ?
  Limits: 0 - 32767
  Front Left: 0 [0%]
  Front Right: 0 [0%]
  Rear Left: 0 [0%]
  Rear Right: 0 [0%]
  Front Center: 0 [0%]
  Woofer: 0 [0%]
  Side Left: 0 [0%]
  Side Right: 0 [0%]
  Rear Center: 0 [0%]
  ?: 0 [0%]
  ?: 0 [0%]
  ?: 0 [0%]
  ?: 0 [0%]
  ?: 0 [0%]
  ?: 0 [0%]
  ?: 0 [0%]
  ?: 0 [0%]
  ?: 0 [0%]
  ?: 0 [0%]
  ?: 0 [0%]




>
> http://www.alsa-project.org/alsa-doc/alsa-lib/group___simple_mixer.html#g9cb8437b2f92d168c43e4da2c667e823
>
> Alsamixer-Qt4 currently can only show these 9 channels - in the channels
> mixer dialog - which is not sufficient.
>
> I did not find a function like snd_mixer_selem_playback_channels
> which would return the number of channels.
> So to find out how many channels there actually are I would have to do
> something like this
>
> int num_playback = 0;
> for ( int ii=0; ii < 1024; ++ii ) {
>        if ( snd_mixer_selem_has_playback_channel ( elem, ii ) ) {
>                num_playback += 1;
>        } else {
>                break;
>         }
> }
>
>

Re: Alsamixer-Qt4 0.4.0 released

[Sebastian H.]

> EQ Peaks is a  volatile control without write access  (i.e. you cannot use
> slider since you cannot modify the value ) which provide the peak of  10
> bands (31Hz, 63Hz, 125Hz, 250Hz, 500Hz, 1Kz, 2Kz, 4Kz, 8Kz , 16Kz) stereo
> channels of the au8830's hardware equalizer  ,  ( one stereo vu-meters at
> each band )
> 
> The values are ordered  by left channel of 10 bands followed by right
> channel of 10 bands
> 
> 
>  control.12 {
>         comment.access read
>         comment.type INTEGER
>         comment.count 20
>         comment.range '0 - 32767'
>         iface MIXER
>         name 'EQ Peaks'
>         value.0 1
>         value.1 1
>         value.2 0
>         value.3 0
>         value.4 1
>         value.5 1
>         value.6 1
>         value.7 1
>         value.8 0
>         value.9 0
>         value.10 1
>         value.11 1
>         value.12 0
>         value.13 0
>         value.14 0
>         value.15 0
>         value.16 1
>         value.17 1
>         value.18 0
>         value.19 0
>     }

Where do you get this listing from?
I greped through the alsa source but did not find it.
Is it an amixer output or so?

> EQ enable switch control the output of DSP pass through/bypass the equalizer
> ,
> so your application can based on the on/off state of the switch to
> start/stop a timer which  read the value from EQ peak control and display on
> 10 stereo vu-meters at regular time intervals
> 
> There are also 10  stereo volume controls to control gain/atten of 10 bands
> of the hardware equalizer
>

I see, thank you for the explanation!


> if your application are unable to display EQ peaks , it is better to skip
> this "EQ peaks" control with count =20 or simple mixer control with 20
> channels

For now I'll skip any element which is named "EQ peaks".
Would this be acceptable with regard to other cards?


> All the EQ controls appear on capture side is a bug of alsa-lib or the
> driver , either change the name of those  "EQ xx" controls to "EQ xx
> Playback" in the driver or add "EQ" to the definition of the controls name

There could be a workaround for this bug in the mixer but IMHO
it should better be fixed in the driver or alsa-lib.


I've enabled the Mercurial repository at sourceforge, it is at:

http://alsamixer-qt4.hg.sourceforge.net:8000/hgroot/alsamixer-qt4/alsamixer-qt4

Cloning and compiling should work like this:

hg clone
http://alsamixer-qt4.hg.sourceforge.net:8000/hgroot/alsamixer-qt4/alsamixer-qt4

cd alsamixer-qt4
mkdir build && cd build
cmake
make


The changes are in the repository if you want to give them a try.

Best,
Sebastian

Re: Alsamixer-Qt4 0.4.0 released

[Sebastian H.]

>> it crashes on my machine with one USB soundcard,
>> and an RME Hammerfall ..i think RME causes it -
>> i get a `Floating exception` ..hm, not a segfault this time :)
> 
> This looks like a bug in the slider/painter code.
> Maybe some ranges are screwed, like 0 to 0 or so and the slider
> can't handle it.

Indeed an 0 to 0 range exactly creates this kind of error.
I'll fix this within the next few days.

> A gdb backtrace would be helpful.
> Could you compile with:
> 
> cmake -DCMAKE_BUILD_TYPE=Debug
> make
> 
> and then create a backtrace with gdb:
> 
> echo -e "run\nwhere\nquit" > gdb_com.txt
> gdb src/alsamixer-qt4 -batch -x gdb_com.txt > gdb.txt
> 
> and send me the gdb.txt file?
> 
>> ..i can do some tests ..have you got an svn or git?
> 
> Right now I only have a mercurial repository on my local machine.
> I think sourceforge support mercurial now, I'll check on this later.

Ok, the mercurial repository is online (read only).

http://sourceforge.net/projects/alsamixer-qt4/develop

To create a clone type

hg clone
http://alsamixer-qt4.hg.sourceforge.net:8000/hgroot/alsamixer-qt4/alsamixer-qt4


>> basically RME alsa driver is different from all other drivers,
>> so far i only see one mixer that presented snd-hdsp options
>> in correct way ..it's mostly just tick boxes..
>> i'd say that you can just try to set up a condition
>> that if the card is RME, then just ignore that card :)
>> ..otherwise check hdspmixer and hdspconf in alsa-tools.
> 
> I would like to avoid keeping a blacklist in the mixer application.
> It's meant to be a general purpose mixer but it should'n crash on high
> end hardware.

Re: Alsamixer-Qt4 0.4.0 released

[Niels Mayer]

This mixer is a major improvement over alsamixergui and alsamixer.
Unfortunately with envy24-based soundcards, it doesn't do the right
thing w/r/t the ice1712's built-in digital mixer (
http://nielsmayer.com/envy24control/envy24mixer-architecture.png ).
There's up to eight pairs of input monitors and PCM output monitors
that feed the mixer through L/R sliders that look like:
http://nielsmayer.com/envy24control/Mudita24-102-Monitor-Inputs.png
http://nielsmayer.com/envy24control/Mudita24-102-Monitor-Outputs.png
(Application shown in screenshots is envy24control modification known
as "mudita24"
 http://nielsmayer.com/envy24control/mudita24-1.0.3.tar.gz . )

In alsamixer-qt4, both the left and right sides of these attenuators
are controlled simultaneously, rather than individually. Likewise, the
mutes are controlled simultaneously when they should be individually
controllable left and right. Note that each of these controls has a
front left capture and a front right capture that must be controlled
individually. Furthermore, there appears to be a bug alsamixer-qt4 in
that it takes the value for the left setting for one channel (ie.
shows 100%) and then for the next it takes the setting for the right
(i.e. shows 0%). This gives an alternating pattern of sliders and
mutes that doesn't correspond to the alsa values. Of course, once
alsamixer-qt4 changes the values, then you have to go back in
envy24control and fix all values where left and right sides got set to
same value. http://nielsmayer.com/envy24control/Screenshot-Alsamixer-Qt4.png
is what it looks like.
(Btw "Delta IEC958 Input Status" should not be "writeable" -- it's a
status indicator, but in alsamixer-qt4, it doesn't turn on when then
digital input has signal).

 Here are the associated controls from 'amixer -c M66' from an M-audio
Delta 66.

(1) L/R monitor/mix of IEC958 digital input:

Simple mixer control 'IEC958 Multi',0
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 96
  Front Left: Capture 93 [97%] [on]
  Front Right: Capture 0 [0%] [off]
Simple mixer control 'IEC958 Multi',1
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 96
  Front Left: Capture 0 [0%] [off]
  Front Right: Capture 93 [97%] [on]

(2) L/R Monitoring of four analog inputs (ice1712 supports up to eight)

Simple mixer control 'H/W Multi',0
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 96
  Front Left: Capture 96 [100%] [0.00dB] [on]
  Front Right: Capture 0 [0%] [-144.00dB] [off]
Simple mixer control 'H/W Multi',1
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 96
  Front Left: Capture 0 [0%] [-144.00dB] [off]
  Front Right: Capture 96 [100%] [0.00dB] [on]
Simple mixer control 'H/W Multi',2
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 96
  Front Left: Capture 92 [96%] [-6.00dB] [on]
  Front Right: Capture 0 [0%] [-144.00dB] [off]
Simple mixer control 'H/W Multi',3
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 96
  Front Left: Capture 35 [36%] [-91.50dB] [off]
  Front Right: Capture 92 [96%] [-6.00dB] [on]

(3) L/R monitoring of 10PCM outs: channels 0-7 and one SPDIF pair at 8,9:

Simple mixer control 'Multi',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 96
  Mono:
  Front Left: Playback 96 [100%] [0.00dB] [on]
  Front Right: Playback 0 [0%] [-144.00dB] [off]
Simple mixer control 'Multi',1
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 96
  Mono:
  Front Left: Playback 0 [0%] [-144.00dB] [off]
  Front Right: Playback 96 [100%] [0.00dB] [on]
Simple mixer control 'Multi',2
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 96
  Mono:
  Front Left: Playback 96 [100%] [0.00dB] [off]
  Front Right: Playback 0 [0%] [-144.00dB] [off]
Simple mixer control 'Multi',3
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 96
  Mono:
  Front Left: Playback 46 [48%] [-75.00dB] [off]
  Front Right: Playback 96 [100%] [0.00dB] [off]
Simple mixer control 'Multi',4
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 96
  Mono:
  Front Left: Playback 93 [97%] [-4.50dB] [on]
  Front Right: Playback 0 [0%] [-144.00dB] [off]
Simple mixer control 'Multi',5
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 96
  Mono:
  Front Left: Playback 0 [0%] [-144.00dB] [off]
  Front Right: Playback 93 [97%] [-4.50dB] [on]
Simple mixer control 'Multi',6
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 96
  Mono:
  Front Left: Playback 96 [100%] [0.00dB] [on]
  Front Right: Playback 0 [0%] [-144.00dB] [off]
Simple mixer control 'Multi',7
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 96
  Mono:
  Front Left: Playback 0 [0%] [-144.00dB] [off]
  Front Right: Playback 96 [100%] [0.00dB] [on]
Simple mixer control 'Multi',8
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 96
  Mono:
  Front Left: Playback 96 [100%] [0.00dB] [on]
  Front Right: Playback 0 [0%] [-144.00dB] [off]
Simple mixer control 'Multi',9
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 96
  Mono:
  Front Left: Playback 0 [0%] [-144.00dB] [off]
  Front Right: Playback 96 [100%] [0.00dB] [on]

-- Niels
http://nielsmayer.com

Re: Alsamixer-Qt4 0.4.0 released

[Sebastian H.]

Hello Niels

> This mixer is a major improvement over alsamixergui and alsamixer.

That's good to hear. It always bugged me that certain things that are
supposed to be simple can be extraordinary complicated in linux. Like
altering the output/input volume.

> Unfortunately with envy24-based soundcards, it doesn't do the right
> thing w/r/t the ice1712's built-in digital mixer (
> http://nielsmayer.com/envy24control/envy24mixer-architecture.png ).
> There's up to eight pairs of input monitors and PCM output monitors
> that feed the mixer through L/R sliders that look like:
> http://nielsmayer.com/envy24control/Mudita24-102-Monitor-Inputs.png
> http://nielsmayer.com/envy24control/Mudita24-102-Monitor-Outputs.png
> (Application shown in screenshots is envy24control modification known
> as "mudita24"
>  http://nielsmayer.com/envy24control/mudita24-1.0.3.tar.gz . )
> 
> In alsamixer-qt4, both the left and right sides of these attenuators
> are controlled simultaneously, rather than individually. Likewise, the
> mutes are controlled simultaneously when they should be individually
> controllable left and right. Note that each of these controls has a
> front left capture and a front right capture that must be controlled
> individually.

Ok, I thought that the main area - for simplicity - should only contain
combined mono sliders and if people really want to alter channels they
could use the channel mixer (button on the sidebar).

But if a combined mono slider is not appropriate at all for a
multi channel element I wonder how get to known about it from
the ALSA API. Or to put in an other way: When should all channel
sliders be displayed instead of a combined mono slider?
Is it when
  snd_mixer_selem_has_playback_volume_joined ( elem ) == 0?
or when
  snd_mixer_selem_is_capture_mono ( elem ) == 0?
or must there be a string comparison plus element
database in the mixer application (not desireable IMHO)?


> Furthermore, there appears to be a bug alsamixer-qt4 in
> that it takes the value for the left setting for one channel (ie.
> shows 100%) and then for the next it takes the setting for the right
> (i.e. shows 0%). This gives an alternating pattern of sliders and
> mutes that doesn't correspond to the alsa values. Of course, once
> alsamixer-qt4 changes the values, then you have to go back in
> envy24control and fix all values where left and right sides got set to
> same value. http://nielsmayer.com/envy24control/Screenshot-Alsamixer-Qt4.png
> is what it looks like.

For the combined sliders the left channel value is take because
SND_MIXER_SCHN_MONO == SND_MIXER_SCHN_FRONT_LEFT
and on a slider change all channel values are adjusted.
That seemed to me the most appropriate behaviour for a combined slider.
And if a combined slider is the wrong choice for ane element it's again
the question mentioned above.

As far as I can see the alsamixer-qt4 screenshot shows the
same value for the left channel as in the Mudita24 screenshot.
The alternating of the left channel is present there, too.


> (Btw "Delta IEC958 Input Status" should not be "writeable" -- it's a
> status indicator, but in alsamixer-qt4, it doesn't turn on when then
> digital input has signal).

Ok, this surely can be fixed, too. But how do I know that an element is
not writeable.

Best,
Sebastian

Re: Alsamixer-Qt4 0.4.0 released

[Raymond Yau]

2010/8/6 Sebastian H. <vand2@gmx.de>

>
> > EQ Peaks is a  volatile control without write access  (i.e. you cannot
> use
> > slider since you cannot modify the value ) which provide the peak of  10
> > bands (31Hz, 63Hz, 125Hz, 250Hz, 500Hz, 1Kz, 2Kz, 4Kz, 8Kz , 16Kz) stereo
> > channels of the au8830's hardware equalizer  ,  ( one stereo vu-meters at
> > each band )
> >
> > The values are ordered  by left channel of 10 bands followed by right
> > channel of 10 bands
> >
> >
> >  control.12 {
> >         comment.access read
> >         comment.type INTEGER
> >         comment.count 20
> >         comment.range '0 - 32767'
> >         iface MIXER
> >         name 'EQ Peaks'
> >         value.0 1
> >         value.1 1
> >         value.2 0
> >         value.3 0
> >         value.4 1
> >         value.5 1
> >         value.6 1
> >         value.7 1
> >         value.8 0
> >         value.9 0
> >         value.10 1
> >         value.11 1
> >         value.12 0
> >         value.13 0
> >         value.14 0
> >         value.15 0
> >         value.16 1
> >         value.17 1
> >         value.18 0
> >         value.19 0
> >     }
>
> Where do you get this listing from?
> I greped through the alsa source but did not find it.
> Is it an amixer output or so?
>

it is the content of file produced by "alsactl store -f  abc.txt"

alsactl is an alsa-util which store/restore the setting of the sound cards
when you logout/login or the system is shutdown/boot

BTW , it seem that the slider cannot individually control left or right
channels volume

How about selecting other CTL devices such as pulse (alsa-pulse plugin) or
equal ( alsa-equalizer plugin )

Re: Alsamixer-Qt4 0.4.0 released

[Sebastian H.]

Am 12.08.2010 03:38, schrieb Raymond Yau:
> 2010/8/6 Sebastian H. <vand2@gmx.de>
> 
>>
>>> EQ Peaks is a  volatile control without write access  (i.e. you cannot
>> use
>>> slider since you cannot modify the value ) which provide the peak of  10
>>> bands (31Hz, 63Hz, 125Hz, 250Hz, 500Hz, 1Kz, 2Kz, 4Kz, 8Kz , 16Kz) stereo
>>> channels of the au8830's hardware equalizer  ,  ( one stereo vu-meters at
>>> each band )
>>>
>>> The values are ordered  by left channel of 10 bands followed by right
>>> channel of 10 bands
>>>
>>>
>>>  control.12 {
>>>         comment.access read
>>>         comment.type INTEGER
>>>         comment.count 20
>>>         comment.range '0 - 32767'
>>>         iface MIXER
>>>         name 'EQ Peaks'
>>>         value.0 1
>>>         value.1 1
>>>         value.2 0
>>>         value.3 0
>>>         value.4 1
>>>         value.5 1
>>>         value.6 1
>>>         value.7 1
>>>         value.8 0
>>>         value.9 0
>>>         value.10 1
>>>         value.11 1
>>>         value.12 0
>>>         value.13 0
>>>         value.14 0
>>>         value.15 0
>>>         value.16 1
>>>         value.17 1
>>>         value.18 0
>>>         value.19 0
>>>     }
>>
>> Where do you get this listing from?
>> I greped through the alsa source but did not find it.
>> Is it an amixer output or so?
>>
> 
> it is the content of file produced by "alsactl store -f  abc.txt"
> 
> alsactl is an alsa-util which store/restore the setting of the sound cards
> when you logout/login or the system is shutdown/boot

Oh, ok. thx

> BTW , it seem that the slider cannot individually control left or right
> channels volume

This should be possible in the channel mixer dialog (button on the
sidebar).
I also plan a right-mouse-button menu for each slider which would allow
to open the channel mixer dialog directly.

> How about selecting other CTL devices such as pulse (alsa-pulse plugin) or
> equal ( alsa-equalizer plugin )

Yes, definitely!
I'll try to implement at least a -D option for the next release.
A ctl selection may be a bit trickier though since some ctl entries may
require arguments.

Re: Alsamixer-Qt4 0.4.0 released

[Niels Mayer]

On Mon, Aug 9, 2010 at 7:08 AM, Sebastian H. <vand2@gmx.de> wrote:
> That's good to hear. It always bugged me that certain things that are
> supposed to be simple can be extraordinary complicated in linux. Like
> altering the output/input volume.

That's why I decided to improve envy24control ( aka mudita24 ) for
those w/ envy24-based cards.

> Ok, I thought that the main area - for simplicity - should only contain
> combined mono sliders and if people really want to alter channels they
> could use the channel mixer (button on the sidebar).
>
> But if a combined mono slider is not appropriate at all for a
> multi channel element I wonder how get to known about it from
> the ALSA API. Or to put in an other way: When should all channel
> sliders be displayed instead of a combined mono slider?
> Is it when
>  snd_mixer_selem_has_playback_volume_joined ( elem ) == 0?
> or when
>  snd_mixer_selem_is_capture_mono ( elem ) == 0?
> or must there be a string comparison plus element
> database in the mixer application (not desireable IMHO)?

I believe the compromise solution to this problem is to check for
capture mono versus capture stereo. If the values are different, put
up either two sliders for the different levels (which wastes a lot of
screen space), or put up a single level slider and a panpot control
directly below it to indicate it's a stereo channel and where L->R the
signal ends up going.

This is already available w/ the 'channel mixer' but it's hidden under
a popup. IMHO, if the existing L/R mix values are different, then it
is a bug to display them as a single slider, usually showing the LHS
value (from what I observed). Likewise, if the mute values are
different, then the actual values should be displayed, rather than
just "sampling" a single channels worth of information.

FYI, on Ice1712 each of the channels requiring a stereo capture looks like:

Simple mixer control 'H/W Multi',0
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 96
  Front Left: Capture 92 [96%] [-6.00dB] [on]
  Front Right: Capture 0 [0%] [-144.00dB] [off]
Simple mixer control 'Multi',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 96
  Mono:
  Front Left: Playback 93 [97%] [-4.50dB] [on]
  Front Right: Playback 0 [0%] [-144.00dB] [off]

>> same value. http://nielsmayer.com/envy24control/Screenshot-Alsamixer-Qt4.png
>> is what it looks like.
>
> For the combined sliders the left channel value is take because
> SND_MIXER_SCHN_MONO == SND_MIXER_SCHN_FRONT_LEFT
> and on a slider change all channel values are adjusted.
> That seemed to me the most appropriate behaviour for a combined slider.
> And if a combined slider is the wrong choice for ane element it's again
> the question mentioned above.
>
> As far as I can see the alsamixer-qt4 screenshot shows the
> same value for the left channel as in the Mudita24 screenshot.
> The alternating of the left channel is present there, too.

Yes this fits what I'm seeing :-) . I think it boils down to anybody
using an ice1712 as a standard soundcard may not care, and those
making use of its built-in digital mixer, as exposed via ALSA, will
feel the behavior of this mixer, and most other GUI mixers other than
alsamixer, envy24control & mudita24 , are broken w/r/t handling stereo
mixer channels on this card. You'd expect KDE to have gotten this
right, but kmix, for example, gets it wrong as well. Ive seen
countless situations where people have needed to ask for basic audio
help because they used a GUI that hid important information, instead
of allowing the user to notice some oddball value as they scroll
through 'alsamixer'.

'alsamixer' can display these stereo mixer channels correctly -- the
ASCII-block "faders" are split into narrow stereo pairs for the
channels where the levels are different. Unfortunately, it doesn't
handle displaying the stereo mute like envy24control/mudita24.

>> (Btw "Delta IEC958 Input Status" should not be "writeable" -- it's a
>> status indicator, but in alsamixer-qt4, it doesn't turn on when then
>> digital input has signal).
>
> Ok, this surely can be fixed, too. But how do I know that an element is
> not writeable.

Not sure about that. "IEC958 input status" is a new card-specific
feature I just added to mudita24. Since I've only seen it on M-Audio
delta cards, I added yet more card-specific checks and support to
mudita24 for all delta cards w/ digital inputs.

However, as an indicator, alsamixer-qt4 should show it "lighting up"
when I have a valid digital input signal. This is useful, for example,
in preventing a lockup if you switch the clock-sync input to the
digital in, you want to know there's something there to lock on to....
Which is why I added it to mudita24.

-- Niels
http://nielsmayer.com

PS: digression -- has anybody used Vala to create a "mixer
construction kit" out of nicely wrapped ALSA constructs and
expeditiously-leveraged existing C/C++ code? ( i was thinking any
serious hacking on envy24control/mudita24 deserves at least this
centuries' programming languages&desktop support --
http://www.linuxaudio.org/mailarchive/lad/2010/8/11/172721 ).... IMHO
this approach could be leveraged into something more useful for ALSA
-- an ALSA "wizard" that could extract a high-level description of
hardware, apply a rule-base of test/solutions to solving traditional
and ongoing audio-setup or upgrading problems, and help visually
construct a custom system control panel interface to all the audio and
media devices on a particular person's system. It should also do the
dishes. :-)
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Alsamixer-Qt4 0.4.0 released

[Sebastian H.]

> That's why I decided to improve envy24control ( aka mudita24 ) for
> those w/ envy24-based cards.

The screenshots look good! (Don't have the card)

>> Ok, I thought that the main area - for simplicity - should only contain
>> combined mono sliders and if people really want to alter channels they
>> could use the channel mixer (button on the sidebar).
>>
>> But if a combined mono slider is not appropriate at all for a
>> multi channel element I wonder how get to known about it from
>> the ALSA API. Or to put in an other way: When should all channel
>> sliders be displayed instead of a combined mono slider?
>> Is it when
>>  snd_mixer_selem_has_playback_volume_joined ( elem ) == 0?
>> or when
>>  snd_mixer_selem_is_capture_mono ( elem ) == 0?
>> or must there be a string comparison plus element
>> database in the mixer application (not desireable IMHO)?
> 
> I believe the compromise solution to this problem is to check for
> capture mono versus capture stereo. If the values are different, put
> up either two sliders for the different levels (which wastes a lot of
> screen space), or put up a single level slider and a panpot control
> directly below it to indicate it's a stereo channel and where L->R the
> signal ends up going.

I prefer two parallel sliders but that sounds good.
So the rule would be:
Show all channel sliders if not all channels have the same value
(slider or check).

This would not handle the case where all channels have the same value
but easily could have different values. In that case the "channel mixer"
dialog must be fired up once. Maybe by right clicking the slider (not
implemented, yet).

> This is already available w/ the 'channel mixer' but it's hidden under
> a popup. IMHO, if the existing L/R mix values are different, then it
> is a bug to display them as a single slider, usually showing the LHS
> value (from what I observed). Likewise, if the mute values are
> different, then the actual values should be displayed, rather than
> just "sampling" a single channels worth of information.

Agreed, in such cases all channel sliders/checls should show up in the
main area.

> Ive seen
> countless situations where people have needed to ask for basic audio
> help because they used a GUI that hid important information, instead
> of allowing the user to notice some oddball value as they scroll
> through 'alsamixer'.

Hehe, that's exactly my experience. Everyone who e.g. fires up
flashy Skype fires up the _console_ alsamixer at maximum five
minutes later and not one of the GUI mixers.

> 'alsamixer' can display these stereo mixer channels correctly -- the
> ASCII-block "faders" are split into narrow stereo pairs for the
> channels where the levels are different. Unfortunately, it doesn't
> handle displaying the stereo mute like envy24control/mudita24.

I don't like showing both channels _always_ because in most situations
this is more information than needed and it floods precious
screen space. But in cases it should be possible to show up all channels
in the main area.


>>> (Btw "Delta IEC958 Input Status" should not be "writeable" -- it's a
>>> status indicator, but in alsamixer-qt4, it doesn't turn on when then
>>> digital input has signal).
>>
>> Ok, this surely can be fixed, too. But how do I know that an element is
>> not writeable.
> 
> Not sure about that. "IEC958 input status" is a new card-specific
> feature I just added to mudita24. Since I've only seen it on M-Audio
> delta cards, I added yet more card-specific checks and support to
> mudita24 for all delta cards w/ digital inputs.
> 
> However, as an indicator, alsamixer-qt4 should show it "lighting up"
> when I have a valid digital input signal. This is useful, for example,
> in preventing a lockup if you switch the clock-sync input to the
> digital in, you want to know there's something there to lock on to....
> Which is why I added it to mudita24.

Alsamixer-Qt4 just shows what it gets from the alsa-lib.
If alsa-lib doesn't trigger a "changed" event when the digital input has
signal then there's little the mixer can do about it.
Except polling of course. But that doesn't look like a case where
polling from the mixer should be neccessary.

One thing the mixer could try to determine writability is to write back
the first value it read and check if e.g.
snd_mixer_selem_set_playback_switch ( )
returns an error.

> 
> -- Niels
> http://nielsmayer.com
> 
> PS: digression -- has anybody used Vala to create a "mixer
> construction kit" out of nicely wrapped ALSA constructs and
> expeditiously-leveraged existing C/C++ code? ( i was thinking any
> serious hacking on envy24control/mudita24 deserves at least this
> centuries' programming languages&desktop support --
> http://www.linuxaudio.org/mailarchive/lad/2010/8/11/172721 ).... IMHO
> this approach could be leveraged into something more useful for ALSA
> -- an ALSA "wizard" that could extract a high-level description of
> hardware, apply a rule-base of test/solutions to solving traditional
> and ongoing audio-setup or upgrading problems, and help visually
> construct a custom system control panel interface to all the audio and
> media devices on a particular person's system. It should also do the
> dishes. :-)

Well, I could help with the dishes but the first part is slightly
beyond my comprehension. :-)

Best,
Sebastian

Re: Alsamixer-Qt4 0.4.0 released

[Raymond Yau]

2010/8/4 Sebastian H. <vand2@gmx.de>

> Hello everyone
>
> I've been working on Alsamixer-Qt4 lately and compiled
> the changes into a new release version 0.4.0.
> Most importantly the cards list can be refreshed now
> and the style got a little overhaul, too.
> A more detailed changelog can be found at the xwmw.org page.
>
> The new version 0.4.0 is available at the known places.
> http://xwmw.org/alsamixer-qt4/
> http://sourceforge.net/projects/alsamixer-qt4/files/
>
> Any comments are welcome.
>
> Cheers,
> Sebastian
>

How about those inactive controls ? snd_mixer_selem_is_active()

e.g. for those motherboard with 3 audio jacks at the rear panel,  the pink
and blue jacks are retasked as output pins after turn the "Smart 5.1" switch
on , the controls of "Mic" and "Line-in" , "ceter/lfe" and "rear"  are
active/inactive

Re: Alsamixer-Qt4 0.4.0 released

[Sebastian H.]

Am 25.09.2010 03:25, schrieb Raymond Yau:
> 2010/8/4 Sebastian H. <vand2@gmx.de>
> 
>> Hello everyone
>>
>> I've been working on Alsamixer-Qt4 lately and compiled
>> the changes into a new release version 0.4.0.
>> Most importantly the cards list can be refreshed now
>> and the style got a little overhaul, too.
>> A more detailed changelog can be found at the xwmw.org page.
>>
>> The new version 0.4.0 is available at the known places.
>> http://xwmw.org/alsamixer-qt4/
>> http://sourceforge.net/projects/alsamixer-qt4/files/
>>
>> Any comments are welcome.
>>
>> Cheers,
>> Sebastian
>>
> 
> How about those inactive controls ? snd_mixer_selem_is_active()
> 
> e.g. for those motherboard with 3 audio jacks at the rear panel,  the pink
> and blue jacks are retasked as output pins after turn the "Smart 5.1" switch
> on , the controls of "Mic" and "Line-in" , "ceter/lfe" and "rear"  are
> active/inactive

snd_mixer_selem_is_active() has been ignored so far since I wasn't sure
what it really meant.

Seems the proper way to handle and *inactive* element is to hide the
slider/switch/enum widgets completely.
Alternatively they could be greyed out. But showing dead
widgets would probably just distract users and waste screen space.

Btw. I'm still working on a alsamixer-qt4. There've been just so many
changes in the background that it takes some time to stabilize
everything again. And there're still open issues (mostly QT stuff).
So I would estimate two or three more weeks for a new release.

Re: Alsamixer-Qt4 0.4.0 released

[Raymond Yau]

2010/9/25 Sebastian H. <vand2@gmx.de>

>
>
> snd_mixer_selem_is_active() has been ignored so far since I wasn't sure
> what it really meant.
>
> Seems the proper way to handle and *inactive* element is to hide the
> slider/switch/enum widgets completely.
> Alternatively they could be greyed out. But showing dead
> widgets would probably just distract users and waste screen space.
>
> Btw. I'm still working on a alsamixer-qt4. There've been just so many
> changes in the background that it takes some time to stabilize
> everything again. And there're still open issues (mostly QT stuff).
> So I would estimate two or three more weeks for a new release.
>

Seem I have quoted a wrong example

Refer to patch_via.c , when "Independent Headphone" switch is on/off,
In via_independent_hp_put() function call activate_ctl() which set the
"Headphone Playback volume" and "Headphone Playback switch" controls to
active/inactive

This mean that the controls are only temporary inactive and can become
active again
the driver also call snd_ctl_notify(codec->bus->card,
SNDRV_CTL_EVENT_MASK_VALUE, &ctl->id)

Does it mean that the mixer application receive an event about the change of
the active/inactive state of the control ?

Re: Alsamixer-Qt4 0.4.0 released

[Sebastian H.]

Am 26.09.2010 01:56, schrieb Raymond Yau:
> 2010/9/25 Sebastian H. <vand2@gmx.de>
> 
>>
>>
>> snd_mixer_selem_is_active() has been ignored so far since I wasn't sure
>> what it really meant.
>>
>> Seems the proper way to handle and *inactive* element is to hide the
>> slider/switch/enum widgets completely.
>> Alternatively they could be greyed out. But showing dead
>> widgets would probably just distract users and waste screen space.
>>
>> Btw. I'm still working on a alsamixer-qt4. There've been just so many
>> changes in the background that it takes some time to stabilize
>> everything again. And there're still open issues (mostly QT stuff).
>> So I would estimate two or three more weeks for a new release.
>>
> 
> Seem I have quoted a wrong example
> 
> Refer to patch_via.c , when "Independent Headphone" switch is on/off,
> In via_independent_hp_put() function call activate_ctl() which set the
> "Headphone Playback volume" and "Headphone Playback switch" controls to
> active/inactive
> 
> This mean that the controls are only temporary inactive and can become
> active again
> the driver also call snd_ctl_notify(codec->bus->card,
> SNDRV_CTL_EVENT_MASK_VALUE, &ctl->id)
> 
> Does it mean that the mixer application receive an event about the change of
> the active/inactive state of the control ?

The quick answer is likely yes.
Although the active/inactive evaluation part
it is not implemented, yet. But this shouldn't be too difficult with
the new dynamic design which roughly looks like this.

Buffer A - Offline buffer in in the background.
           Contains snd_mixer_t and snd_mixer_elem_t structs.
           Gets created once during mixer loading (or reloading).

Buffer B - Online buffer. Corresponds to the widgets.
           The layout (also means widgets visibility) can be changed
           on demand.


The value update flow then goes somewhat like this

- Socket event on the snd_mixer_t!
- Read the whole mixer state from the snd_* functions into Buffer A
- Value evaluation in Buffer A.
  On demand:
  - Adjust Buffer B to separate sliders with unequal channel values
  - Adjust Buffer B to hide/reveal inactive/active sliders (to be done)
- Copy the state from Buffer A into Buffer B updating the GUI widgets.

The slider separation already works (and is pretty neat :).
Though there still is an issue with channel values changing
one by one and not all together. This makes the Buffer A evaluator
think the sliders should be separated just to become equal again
directly after. I already thought about introducing a delay of a
second or so for slider separation (to be done).

The active/inactive state evaluation will be another check in the Buffer
A evaluation step. The check then can adjust Buffer B to
show/hide the respective GUI widget (to be done).