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

[Takashi Iwai]

At Wed, 13 Aug 2008 12:59:32 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> Hi,
> 
> 	some developers probably already noted, I commited to alsactl 
> utility (alsa-utils package) initial implementation of soundcard 
> initialization stuff aka 'alsactl init'.

Yeah, looks good.

> 	The basic idea was to "reuse" nice udev configuration style and 
> modify it to ALSA purposes. I hope that I ended up with a syntax which is 
> easy understandable and configuration can be created with minimal effort.
> Please, look to 'man 7 alsactl_init' for more details and to 
> alsa-utils/alsactl/init directory for example files.

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.

One missing feature is to store the values in dB unit.  That would be
more robust and commonly used over different hardwares than raw
values, even if they have different resolutions.  Also, enum value
strings are missing.

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.

> 	Note that the runtime evaluation of commands can be modified using 
> environment variables like udev does. Just try 'alsactl -E CMD=help init' 
> or 'CMD=help alsactl init'.
> 	Hardware can be detected using sysfs. For older kernel, I'm 
> plannig to add some compatibility layer to read at least 
> ATTR{subsystem_vendor} and ATTR{subsystem_device} information from procfs 
> (codec files).

In the case of HD-audio, there could be still a bit pain.  Some
hardwares cannot be detected via PCI SSID but only via codec SSID
(PKU) or codec revision ID which aren't exposed via sysfs.  But, I
guess this is a rare case and the mixer settings are likely same among
these devices with the same PCI SSID.

> 	Also, a way to gather working configurations for specific hardware 
> is required. A nice script alsa-info.sh is already in the alsa-driver 
> package, so I just created a simple persistent "file" dabatase on 
> www.alsa-project.org: http://www.alsa-project.org/cardinfo-db/ and 
> modified alsa-info.sh to use this database for the contents upload by 
> default. Developers can download whole database in a tar package to 
> extract necessary information using command line text tools and use this 
> database also for other purposes (HDA codec graphing and so).

This is a good action, indeed.


thanks,

Takashi