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)[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. Regards Takashi Sakamoto _______________________________________________ Linux-audio-dev mailing list [email protected] https://lists.linuxaudio.org/listinfo/linux-audio-dev
