[snip]
UCM also does not currently support #include. The intention is to provide a
method to define mixer settings on a codec per codec basis and the these
could be #included into a machine UCM file. The machine UCM file would
also define settings for any quirks and would #include any codec UCM files
that were needed. PA would load the machine UCM file (based on
improvements to the driver naming above) intead of the generic UCM file
that is loaded atm.
Liam
We can fix this from driver level and user space level:
(1) to reporting more information from driver.
ALSA sound cards have 3 names. longname, shortname and drivername. e.g.
from soc-core.c :-
snprintf(card->snd_card->shortname, sizeof(card->snd_card->shortname),
"%s", card->name);
snprintf(card->snd_card->longname, sizeof(card->snd_card->longname),
"%s", card->long_name ? card->long_name : card->name);
snprintf(card->snd_card->driver, sizeof(card->snd_card->driver),
"%s", card->driver_name ? card->driver_name : card->name);
We can additionally set the long_name and driver_name in ASoC if they were not set.
The naming scheme could be :-
a) shortname is current machine driver name i.e. "byt-rt5640"
b) longname is DMI boardname + 1 i.e. "Minnowboard Max: byt-rt5640"
c) driver name is platform driver name i.e. "baytrail-pcm-audio"
(2) to enable UCM to support "include" parsing, so each codec will have its own UCM file to define all the use cases for the codec only, and the codec UCM file can be included and the codec use cases can be referenced by different machine driver UCM files.
I don't think a single codec UCM file would work since the register
settings would conflict. You will have to create different UCM snippets
for specific codec configurations that are included by machine drivers,
e.g. one for dmics, one for amics, one for stereo speakers, etc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
