From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaroslav Kysela Subject: Re: [alsa-cvslog] [ALSA GIT]ALSA utilities repository branch master updated. v1.0.26-26-ge05b903 Date: Wed, 10 Apr 2013 11:20:34 +0200 Message-ID: <51652EE2.1060100@perex.cz> References: <20130408125154.6264F2651CD@alsa0.perex.cz> <51643937.5020602@perex.cz> <516474E7.1030501@canonical.com> <51650774.9060703@canonical.com> <516510B6.2010002@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail1.perex.cz (mail1.perex.cz [77.48.224.245]) by alsa0.perex.cz (Postfix) with ESMTP id E5333261704 for ; Wed, 10 Apr 2013 11:20:34 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: alsa-devel@alsa-project.org, David Henningsson List-Id: alsa-devel@alsa-project.org 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 >>>>>>>>>> Date: Mon Apr 8 14:49:31 2013 +0200 >>>>>>>>>> >>>>>>>>>> alsactl: move systemd config to the daemon mode >>>>>>>>>> >>>>>>>>>> Signed-off-by: Jaroslav Kysela >>>>>>>>> >>>>>>>>> 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 Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.