On Mon, 2020-01-27 at 09:07 +0100, Jaroslav Kysela wrote:

Dne 27. 01. 20 v 4:38 Tanu Kaskinen napsal(a):

...

Hi all,

I was looking at the UCM files, and most paths have the following structure:

 <cardname>/<cardname>.conf

I noticed that the "HDA Intel PCH" configuration uses some other scheme:

 HDA Intel PCH/HDAudio-DualCodecs.conf
 HDA Intel PCH/HDAudio-Gigabyte-ALC1220DualCodecs.conf
 HDA Intel PCH/HDAudio-Lenovo-DualCodecs.conf

How are the directory and file names determined? If I write configuration for some random sound card that I don't have myself, where do I find the various identifiers in the alsa-info output? I don't even really know for sure what the <cardname> in the first example is, I've been assuming it's the name that appears in the square brackets in /proc/asound/cards.

The ucm has scheme <longname>/<longname>.conf and <drivername>/<drivername>.conf (fallback).

The ucm2 has scheme <drivername>/<longname>.conf and <drivername>/<drivername>.conf (fallback).

Example proc output:

2 [device ]: USB-Audio - USB Video device 317GAWCM001LON3BC1AZ USB Video device at usb-0000:00:14.0-4.2.4, high speed

The driver name is 'USB-Audio' here. The longname is '317GAWCM001LON3BC1AZ USB Video device at usb-0000:00:14.0-4.2.4, high speed' here. The name in brackets is the user selectable identifier for the card (card id). It can be used instead the sound card number.

Thanks, seems pretty straightforward!

...

I think the lookup logic should be explained in the ucm2/README.md file. I can write a patch if someone expains the logic to me, but probably it's easier if you just write the patch yourself.

Yes, a better documentation for the internals is missing. Unfortunately, I hit other real problems with the current UCM logic and trying to resolve them. Unfortunately, I am interrupted with other things so things are going slowly than I want.

Does this mean that the file lookup logic is likely to still change?