[alsa-devel] [alsa-cvslog] [ALSA GIT]ALSA utilities repository branch master updated. v1.0.26-26-ge05b903

[Takashi Iwai]

At Tue, 09 Apr 2013 17:52:23 +0200,
Jaroslav Kysela wrote:
> 
> Date 9.4.2013 14:47, Takashi Iwai wrote:
> > At Mon,  8 Apr 2013 14:51:54 +0200 (CEST),
> > GIT server wrote:
> >>
> >> This is an automated email from the git hooks/post-receive script. It was
> >> generated because a ref change was pushed to the repository containing
> >> the project "ALSA utilities repository".
> >>
> >> The branch, master has been updated
> >>        via  e05b903b1fb16e967d838edac408304cd4470fee (commit)
> >>       from  46cb355d4ff41c8065b02644b0534ab42d16cb72 (commit)
> >>
> >> Those revisions listed above that are new to this repository have
> >> not appeared on any other notification email; so we list those
> >> revisions in full, below.
> >>
> >> - Log -----------------------------------------------------------------
> >> commit e05b903b1fb16e967d838edac408304cd4470fee
> >> Author: Jaroslav Kysela <perex at perex.cz>
> >> Date:   Mon Apr 8 14:49:31 2013 +0200
> >>
> >>     alsactl: move systemd config to the daemon mode
> >>     
> >>     Signed-off-by: Jaroslav Kysela <perex at perex.cz>
> > 
> > I'm not thrilled by the silent default behavior change like this.
> > This will affect all systems using systemd from now on.
> > 
> > I understand the reason behind it, but I wonder whether it's an
> > overkill.  Yet another daemon, unconditionally no matter whether
> > hotplug or not?  Hmm...
> 
> The question is, how we can detect the hotplug scheme. Almost all
> systems have USB today and laptops have PCI express card slots, so....
> Fedora has the systemd configs in the alsa-utils package. A removal of
> this package is sufficient do disable the daemon.

Yes, but then this would break the formerly working environment, too.

> Eventually, we can
> save the state periodically using cron (without the changes tracking),
> but my measurement is that the alsactl daemon eats approx. 150kb of memory.

I'm not concerned about alsactl memory footprint so much.
But having another daemon unconditionally just to save/restore the
mixer status is a question.

> Some other quick ideas:
> 
> - make the static/hotplug schemes depending on an environment variable
>   passed through the bootloader
> - another two packages on top of alsa-utils with two configs

Manageable, but maybe will become a bit messy...

> - save the last state inside the driver and offer it to the userspace
>   upon the card removal (seems overkill)

This won't be that bad, I think.  But, accessing the information after
removal is the problem, after all.  The device and proc files are
removed at disconnection, so user-space can't access it.  Otherwise
the normal "alsactl store" should have worked.  So this can't be a
card-basis interface.

A possible w/a would be that we can keep some stable ctl lists and
provide it as a (one-time) death message from a global proc or a sysfs
file, for example.  Then we don't need periodical sync.

Whether this is a better option?  I dunno, honestly, too...

> - run multiple daemon instances per hotplug card; the question is how
>   to detect the static card in the system (perhaps checking the PCI
>   config?) to avoid the daemon startup for those static cards

Yeah, when thinking a PCI hotplug, it's not easy.


Takashi