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

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#g9cb...

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; } }

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 )

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

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

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.

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