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

Takashi Iwai tiwai at suse.de
Wed Apr 10 11:33:40 CEST 2013


At Wed, 10 Apr 2013 11:20:34 +0200,
Jaroslav Kysela wrote:
> 
> 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.

Sounds good.  Thanks for caring this!


Takashi

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


More information about the Alsa-devel mailing list