24 Jul
2020
24 Jul
'20
6:03 a.m.
On Fri, Jul 24, 2020 at 10:37:35AM +0900, Takashi Sakamoto wrote:
On Thu, Jul 23, 2020 at 11:56:35AM -0700, Len Ovens
wrote:
Oops. I overloop your demand to restore status of control element set
automatically. I register an issue for this topic and queued for my future
work:
Restart alsa-restore.service after launching the service program
https://github.com/alsa-project/snd-firewire-ctl-services/issues/9
Thanks
Takashi Sakamoto
On Thu, 23 Jul 2020, Takashi Sakamoto wrote:
That sounds like what I am seeing. Perhaps alsa-restore.service. I will try
with that disabled. Yes that is the difference, it works as expected. I
would guess this module would be added to alsa before alsa-restore.service
after release. Restore would then be able to fix my clock settings.
As long as I know, alsactl has some bugs to represent the content of
control element set in cache file.
I guess you hit this bug since the feature called as user-define control
element set had not been used for a long time except for alsa-lib
'softvol' PCM plugin.
If alsactl worked expectedly, the order to execute the system service
for alsactl and the service program does not matter as long as they
don't run simultaneously.
> $ cargo run --bin snd-fireworks-ctl-service 2
This worked great the first time, but after the next boot alsamixer showed a
subset of the same controls (rather than no controls found) and I could not
restart snd-fireworks-ctl-service. Is it expected that once the above
I think that some users install system service for alsactl(1)[1]. In this
case, the system services add control element sets from cache file after
reboot. For the case the service program has a care to run with the element