[alsa-devel] Alsamixer-Qt4 0.4.0 released

[Niels Mayer]

On Mon, Aug 9, 2010 at 7:08 AM, Sebastian H. <vand2 at 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. :-)