[alsa-devel] [alsa-cvslog] [ALSA GIT]ALSA utilities repository branch master updated. v1.0.26-26-ge05b903
tiwai at suse.de
Tue Apr 9 18:11:35 CEST 2013
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
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.
More information about the Alsa-devel