On Thu, Jul 23, 2020 at 11:56:35AM -0700, Len Ovens wrote:
On Thu, 23 Jul 2020, Takashi Sakamoto wrote:
$ 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). 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
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.
I have added comments to issues that are closed to
indicate what I have
tested. The closed issues do seem to be fixed.
I see your comments. Thanks for your help and patience! I merged the
topic issue for this RFT into master now.