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: > > 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.
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 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
