Hi Jaroslav,
I have some concern about your commit 2cfe6addaef6[1] for alsa-lib,
It adds new library API, 'snd_ctl_elem_id_compare()', to compare a pair of IDs for control element. In the implementation, the API call returns 0 if they are the same, else negative or positive numeric value according to contents of the IDs.
My concerns are:
1. evaluation of numid field is not covered.
This is not preferable since ALSA control core implementation covers two types of comparison; numid only, and the combination iface, device, subdevice, name, and index fields. If the API is produced for general use cases, it should correctly handle the numid-only case, in my opinion.
2. tri-state return value is semantically inconsistent
The ID structure includes three types of values; integer, enumeration, and string. In my opinion, tri-state return value from them has different meaning each other. It's better just to return comparison result by boolean value, in my opinion.
The reason I post this message instead of posting any fix is that the fix to the API affects to alsa-utils, in which the API is used by a patch you applied a few days ago[2]. The patch also includes change to 'AM_PATH_ALSA' declaration in configure.ac with bumped-up version to '1.2.5', and it disables to rebuild alsa-utils on the latest toolchain. (alsa-lib 1.2.5 is not released yet.)
I'd like to drop the usage of API from alsa-utils with equivalent alternative codes in alsa-utils side at first, apart from the new API in alsa-lib so that alsa-utils can be still build on the latest toolchains to avoid any confusion in user side. Then I'd fix the issued API carefully so that it can be used so long as exposed API without any issue.
[1] https://github.com/alsa-project/alsa-lib/commit/2cfe6addaef6a0afa72699ec07a4... [2] https://github.com/alsa-project/alsa-utils/commit/17b4129e6c89d1a96d4d86dabe...
Regards
Takashi Sakamoto