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

[Jaroslav Kysela]

Date 10.4.2013 08:32, David Henningsson wrote:
> On 04/10/2013 08:10 AM, Takashi Iwai wrote:
>> At Tue, 09 Apr 2013 22:07:03 +0200,
>> David Henningsson wrote:
>>>
>>> On 04/09/2013 06:11 PM, 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.
>>>>
>>>>> 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...
>>>
>>> Coming from a non-systemd world...
>>>
>>> Is the problem you're trying to solve that mixer state is not saved on
>>> hot-unplug; and if so, is this not working for non-systemd installations
>>> either then? Or is it systemd that causes this problem?
>>>
>>> I was expecting that when you unplug something, some kind of synchronous
>>> udev event was fired, which could read the current mixer state and save
>>> it, before it all goes away. But perhaps this was too optimistic...
>>
>> This was the implementation, so far, and known to be broken.  alsactl
>> was triggered by udev. But, in the case of hotplug, when it's
>> unplugged, there is no more device file.  Thus you can't get the mixer
>> status _after_ the unplug. And, of course, the udev event is triggered
>> at the disconnection, that is, it's performed after the unplug.
> 
> Is it possible to add a uevent that synchronously fires just before the 
> device file is removed? Then the mixer state could be read. (The mixer 
> state must be completely stored in kernel, of course, since you can't 
> read it from unplugged hardware.)

I'm not sure, if moving every logic to the kernel is a good idea.

>> Jaroslav's change is to start alsactl as a system daemon by systemd,
>> and let it keeping all mixer states in background.
> 
> Btw, one could also fire udev events on mixer changes (possibly delayed 
> by a few seconds to avoid a uevent storm). Then at least the daemon 
> would not be running constantly. As a minor benefit, this would also 
> protect against settings getting lost on sudden power outages.

I think that the daemon solution is a better idea. The consumed
resources are negligible and the daemon is woken in very long periods
(by default 150 seconds or a ctl event). Also, the consumed resources
for new tasks are higher than if all logic is in a daemon.

					Jaroslav

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