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

[Takashi Iwai]

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