[alsa-devel] alsactl init - implementation and more..

[Takashi Iwai]

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:
> 
> INCLUDE="addon"
> 
> Tree:
> 
> /usr/share/alsa/init/addon/Acer_XY80
> /usr/share/alsa/init/addon/Acer_ZY91
> 
> etc...

They should use number-scheme, too.

> The 00main file might remain (just to handle global specific 
> configuration).
> 
> 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
restore anyway.


Takashi