[alsa-devel] alsactl init - implementation and more..
tiwai at suse.de
Thu Aug 14 08:06:35 CEST 2008
At Wed, 13 Aug 2008 19:26:25 +0200 (CEST),
Jaroslav Kysela wrote:
> On Wed, 13 Aug 2008, Takashi Iwai wrote:
> > At Wed, 13 Aug 2008 16:04:47 +0200 (CEST),
> > Jaroslav Kysela wrote:
> > >
> > > > The card-specific configs shouldn't be read from 00main, but read from
> > > > its file, i.e. 50hda. That is, the config files are to be simply
> > > > added / removed without modifying the existing file.
> > >
> > > I'm not sure if it's useful for our purposes. The 00main also contains
> > > some "global" configuration (like SYSFS_DEVICE setup and more variables
> > > can be added in future) and my initial (not saying that it's optimal)
> > > configuration assumes that first file lookup is a driver name.
> > >
> > > If you like to add extra configuration files in a directory, I would
> > > enhance 'INCLUDE' executer code to check, if the source path is directory
> > > and then include all files from it. But for the standard "database"
> > > purposes, I don't see a reason to check every file and skip contents of
> > > large files just after parsing first lines with false condition.
> > Of course, it's a question how fine-grained each file should be. But
> > in general, modifying the default configuration just for adding a new,
> > fairly independent item is a bad idea. In my scenario: you want to
> > add the support for a new hardware -- fine, just add the file without
> > changing anything else. This would make the maintenance a lot easier
> > (imagine you maintain a distro package).
> > If scanning too many files really matters, then they can be
> > concatenated at appropriate timing.
> My idea is to have a default database (which should be quite optimized for
> parser) and distro specific addons install to a directory as you
> suggested. So, something like (in alsactl init syntax) in 00main:
They should use number-scheme, too.
> The 00main file might remain (just to handle global specific
> Eventualy, another INCLUDE can be placed before the default database
> processing to override the default database.
Yes, sometimes we need a replacement and sometime an additional setup.
> > > > Another would-be-nice feature is one command to do both init and
> > > > restore. First initialize the hardware, then restore (overwrite) the
> > > > setting from the asound.state if already eixsts. This is what udev
> > > > needs to call.
> > >
> > > I'm not sure. The restore action will always overwrite all 'init' values
> > > (at least when control identifier list is not changed in the driver).
> > > Probably, I would prefer a buildin procedure like 'if restore fails then
> > > do init'. What about 'alsactl boot' action name?
> > The init makes sense in the case when the driver is updated and some
> > new controls. Then the newly added controls are set up properly, then
> > the other values are overwritten via restore.
> Upgrading a driver is quite specific process. In this case would be
> probably better to read saved state and compare it to the actual driver
> controls. If something differs, call init and then restore with force
> flag. At least, the init procedure would be skipped (almost every boot
> time) if all controls are present in the state file.
FYI, the force flag is already used as default in the current alsactl.
> So, I'm proposing this 'alsactl boot' behaviour:
> 1) read /etc/asound.state
> 2) if the state does not exist run 'alsactl init' and exit
> 3) if the state exists but controls do not match these in driver, run
> 'alsactl init'
> 4) run 'alsactl restore'
That would work although init can be done always when you run alsactl
More information about the Alsa-devel