alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: "Sebastian H." <vand2@gmx.de>
To: Raymond Yau <superquad.vortex2@gmail.com>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>
Subject: Re: Alsamixer-Qt4 0.4.0 released
Date: Sun, 26 Sep 2010 12:36:09 +0200	[thread overview]
Message-ID: <4C9F2219.9040304@gmx.de> (raw)
In-Reply-To: <AANLkTi=4Uc_vy1xTZMzxy3Komt4up+OAAnioPZdAiO26@mail.gmail.com>

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

      reply	other threads:[~2010-09-26 10:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-04 12:17 Alsamixer-Qt4 0.4.0 released Sebastian H.
2010-08-04 23:33 ` errordeveloper
2010-08-05 11:22   ` Sebastian H.
2010-08-08 12:12     ` Sebastian H.
2010-08-05  7:20 ` Raymond Yau
2010-08-05 12:48   ` Sebastian H.
2010-08-06  0:26     ` Raymond Yau
2010-08-06 14:34       ` Sebastian H.
2010-08-12  1:38         ` Raymond Yau
2010-08-12  9:27           ` Sebastian H.
2010-08-05  8:46 ` The Source
2010-08-08 20:54 ` Niels Mayer
2010-08-09 14:08   ` Sebastian H.
2010-08-12 14:20     ` Niels Mayer
2010-08-15 13:14       ` Sebastian H.
2010-09-25  1:25 ` Raymond Yau
2010-09-25 10:42   ` Sebastian H.
2010-09-25 23:56     ` Raymond Yau
2010-09-26 10:36       ` Sebastian H. [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C9F2219.9040304@gmx.de \
    --to=vand2@gmx.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=superquad.vortex2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).