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

[Jaroslav Kysela]

Date 9.4.2013 18:11, Takashi Iwai wrote:
> 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.

Yes, it is. But it looks like the best (or at least easiest to manage)
idea to solve the hotplug issues for the moment and we can optimize
things later.

>> Some other quick ideas:
>>
>> - make the static/hotplug schemes depending on an environment variable
>>   passed through the bootloader

This variant seems most easy to implement using
ConditionKernelCommandLine or ConditionPathExists (this second option
may be probably better - a configuration file in /etc/alsa or so to
change the state management behaviour looks good).

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

I will add the ConditionPathExists=/etc/alsa/state-static.conf and
ConditionPathExists=/etc/alsa/state-daemon.conf conditions and put back
the old static config files, if no better idea is offered.

					Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.