need to manage two sound cards with same name but different control

Duplicate of https://lf-automotivelinux.atlassian.net/browse/SPEC-1239#icft=SPEC-1239

Seems to me that the requirement is a duplicate of https://lf-automotivelinux.atlassian.net/browse/SPEC-1239#icft=SPEC-1239.

If the different cards have the exact same characteristics in ALSA, they won't be any way to distinguish them.

With current 4A version, it is already possible to select which hal will be loaded at 4a startup. All hal available in '/usr/libexec/agl/4a-hal/etc' are loaded.

Therefore, the solution to your issue with current 4A is to have two different hals and switching from one to another by moving them to/from '/usr/libexec/agl/4a-hal/etc' and reload 4a service.

@Dominig ar Foll : would you please tell us if you still encounter this issue with the new 4a audio framework ?  (Please also refer to Jonathan's comment posted earlier)

Same answer as for https://lf-automotivelinux.atlassian.net/browse/SPEC-1239#icft=SPEC-1239 :

Using new '4a-hal-generic' system, all hal .json configuration files beginning with 'hal-4a' presents in '/usr/libexec/agl/4a-hal/etc' are loaded as hals.
In the current agl master version all hals are deployed into '/usr/libexec/agl/4a-hal/etc.available', and are not detected.
It is the '4a-hal-generic' bitbake recipe that is moving the platform corresponding json configuration file(s) into '/usr/libexec/agl/4a-hal/etc' to auto-load it at startup.

So, to enable an hal at load, you just need to add it to '/usr/libexec/agl/4a-hal/etc' directory.
And, to disable an hal at load, you just need to remove it from '/usr/libexec/agl/4a-hal/etc' directory.

In a incoming feature, as '4a-hal-generic' uses the 'app-controller', we will be able to enable loading of a hal only if a specific line is available into an agl running platform file (e.g. as 'm3ulcb' in a '/etc/platform' file). That way, it will be easier to select which hal should be loaded at startup.

Will these solutions be fine for your use ?

A simple solution would be for 4a to only intialise the hal with are listed in the json configuration file rather than doing an initialisation of all the hal present in the directory.

For me it would lake sense to not load hal which are not listed.

Likely simple to implement.