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

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

[Takashi Iwai]

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


Takashi

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

[Jaroslav Kysela]

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

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
- save the last state inside the driver and offer it to the userspace
  upon the card removal (seems overkill)
- run multiple daemon instances per hotplug card; the question is how
  to detect the static card in the system (perhaps checking the PCI
  config?) to avoid the daemon startup for those static cards

					Jaroslav

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

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

[Takashi Iwai]

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

> - run multiple daemon instances per hotplug card; the question is how
>   to detect the static card in the system (perhaps checking the PCI
>   config?) to avoid the daemon startup for those static cards

Yeah, when thinking a PCI hotplug, it's not easy.


Takashi

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

[Jaroslav Kysela]

Date 9.4.2013 18:11, 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@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@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.

Yes, it is. But it looks like the best (or at least easiest to manage)
idea to solve the hotplug issues for the moment and we can optimize
things later.

>> Some other quick ideas:
>>
>> - make the static/hotplug schemes depending on an environment variable
>>   passed through the bootloader

This variant seems most easy to implement using
ConditionKernelCommandLine or ConditionPathExists (this second option
may be probably better - a configuration file in /etc/alsa or so to
change the state management behaviour looks good).

>> - 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...
> 
>> - run multiple daemon instances per hotplug card; the question is how
>>   to detect the static card in the system (perhaps checking the PCI
>>   config?) to avoid the daemon startup for those static cards
> 
> Yeah, when thinking a PCI hotplug, it's not easy.

I will add the ConditionPathExists=/etc/alsa/state-static.conf and
ConditionPathExists=/etc/alsa/state-daemon.conf conditions and put back
the old static config files, if no better idea is offered.

					Jaroslav

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

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

[David Henningsson]

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

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


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

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

[Takashi Iwai]

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

Jaroslav's change is to start alsactl as a system daemon by systemd,
and let it keeping all mixer states in background.

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


Takashi

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

[Clemens Ladisch]

Takashi Iwai wrote:
> I wonder what about other OS.  Is the mixer status of a USB device
> recorded and resumed after reboot at hotplug?

(Some?) drivers save changed control values to the registry.


Regards,
Clemens

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

[David Henningsson]

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

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


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: [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@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@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

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

[David Henningsson]

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

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

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


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: [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@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@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

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

[Jaroslav Kysela]

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@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@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@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

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

[Takashi Iwai]

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@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@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@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project; Red Hat, Inc.
> 

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

[Jaroslav Kysela]

Date 10.4.2013 08:32, 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@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@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? 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.)

I'm not sure, if moving every logic to the kernel is a good idea.

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

I think that the daemon solution is a better idea. The consumed
resources are negligible and the daemon is woken in very long periods
(by default 150 seconds or a ctl event). Also, the consumed resources
for new tasks are higher than if all logic is in a daemon.

					Jaroslav

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