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

Wed Apr 10 11:20:34 CEST 2013

Just to follow-up. I put back the static systemd configuration files to
the alsa-utils package and made them conditional by checking the
existence of the daemon mode swich file (by default, it is the file
/etc/alsa/state-daemon.conf). The udev restore rule also handles this
condition.

The nice thing is that the other unit configurations depending on the
alsa-restore.service (After= rules) do not need to be updated.

				Jaroslav

Date 10.4.2013 09:20, Takashi Iwai wrote:
> At Wed, 10 Apr 2013 09:11:50 +0200,
> David Henningsson wrote:
>>
>> On 04/10/2013 08:58 AM, Takashi Iwai wrote:
>>> At Wed, 10 Apr 2013 08:32:20 +0200,
>>> 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?
>>>
>>> Well, it's difficult to know beforehand when the device is removed :)
>>
>> 1. Kernel detects device has been plugged in.
>> 2. Kernel sets up mixer and reads all mixer values from the device.
>> 3. Kernel notifies userspace about the new device.
>> 4. Userspace might set volume on the device, too.
>>
>> (later)
>> 5. Kernel detects device has been removed.
>> 6. Kernel fires a udev event and waits for it to finish.
>> 7. Userspace reads mixer state and saves it.
>> 8. Kernel removes the device file.
> 
> It doesn't work reliably.  Not only that it would need a large change
> in kernel, you don't know when the kernel may remove device files.
> Waiting until a user-space read finishes?  It might not happen
> forever.  And the driver still keeps the card slot for that period.
> 
> 
>>>> 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.)
>>>>
>>>>> 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.
>>>
>>> There is no udev event per mixer value change.
>>> If it were, it's a too overload.
>>
>> I meant we could introduce one. We would also delay it, so in case of 
>> many changes in a row, we would only fire one uevent for all changes.
> 
> But udev event is costly.  I don't think it's so appropriate.
> 
> 
>>>>>> FWIW; another option is never to save it unless explicitly requested by
>>>>>> the user. There is definitely a use case where you want to avoid any
>>>>>> sound on bootup, e g if you often boot up your computer in a student
>>>>>> class - regardless of what it was when you turned it off earlier you
>>>>>> want silence on boot.
>>>>>>
>>>>>> (And now we haven't even touched PulseAudio's own save/restore volume
>>>>>> stuff...)
>>>>>
>>>>> I wonder what about other OS.  Is the mixer status of a USB device
>>>>> recorded and resumed after reboot at hotplug?
>>>>
>>>> Windows and Mac OS? I think they record it, but not sure. Slightly
>>>> related, I believe they're both system level (as is alsactl), where as
>>>> PulseAudio saves volume per user.
>>>
>>> Does PA record the volume of USB device properly, too?
>>
>> Yes. If the volume is changed from PA, that volume is also written to 
>> disk (after five seconds). So it writes on change, not on unplug.
> 
> OK, good to know.
> 
> 
> thanks,
> 
> Takashi
> 

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