[LAD] [RFT] ALSA control service programs for Fireworks board module
o-takashi at sakamocchi.jp
Fri Jul 24 04:03:02 CEST 2020
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). 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
Restart alsa-restore.service after launching the service program
More information about the Linux-audio-dev