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

[Takashi Iwai]

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 :)

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

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


Takashi