Hi Jaroslav,
Recent years I'm bothered about unexpected abort of pulseaudio and pipewire processes when testing user-defined control element set. They aborts at element removal event.
``` pulseaudio: mixer.c:149: hctl_elem_event_handler: Assertion `bag_empty(bag)' failed. wireplumber: mixer.c:149: hctl_elem_event_handler: Assertion `bag_empty(bag)' failed. ```
Would I ask your opinion about the design of alsa-lib mixer API?
As long as I investigate, these programs seem to have careless coding as alsa-lib mixer API application. Both of them attaches an instance of snd_mixer_elem_t to an instance of snd_hctl_elem_t by calling snd_mixer_elem_attach() when detecting element addition, but never detach it even if detecting element removal.
In the case, the link list (=bag) of mixer API internal never becomes empty. It has link entries as much as the number of registered mixer classes which attaches snd_mixer_elem_t. Then it hits the assertion.
I think the design of alsa-lib mixer API demands mixer class implementation to detach at element removal which attached at element addition. But I have less conviction about it since enough unfamiliar.
I'm glad if receiving your opinion about it.
I wrote test program for the issued behaviour: - https://gist.github.com/takaswie/8378fe3bc04652d83428694cd7573bc0
For test, please use sample script in alsa-gobject project: - https://github.com/alsa-project/alsa-gobject/blob/master/samples/ctl
The patches for pulseaudio/pipewire are prepared: - https://gitlab.freedesktop.org/takaswie/pulseaudio/-/commit/topic/fix-wrong-... - https://gitlab.freedesktop.org/takaswie/pipewire/-/commits/topic/fix-wrong-h...
Regards
Takashi Sakamoto