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

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

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.

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.

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

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