[alsa-devel] How to package the smixer modules?
Hi all!
What do the smixer modules do? I mean these files:
/usr/lib/alsa-lib/smixer/smixer-ac97.so /usr/lib/alsa-lib/smixer/smixer-hda.so /usr/lib/alsa-lib/smixer/smixer-sbase.so
Should they always be shipped along with the main libasound library? I maintain the alsa-lib package in OpenEmbedded, and currently OpenEmbedded has separate packages for libasound and the smixer modules, and I wonder if that's a good idea. It looks like the smixer modules don't get installed by default when libasound is installed. Debian, in contrast, ships the smixer modules in the libasound package.
After studying the source code a bit, it seems that the smixer modules are dynamically loaded by the "simple mixer" interface of libasound. I'm not familiar with the purpose of that interface. I don't know if there are many applications that use that interface, and I don't know if those applications that do use it suffer badly if the smixer modules aren't installed.
On Mon, 07 Nov 2016 13:43:49 +0100, Tanu Kaskinen wrote:
The simple mixer is another layer in ALSA mixer API, and actually it's mandatory. So, at least, sbase plugin should be provided always when alsa-lib mixer API is used. Other plugins are basically never used practically.
It doesn't matter whether to package them separately or not. The only point is that sbase plugin should be available when alsa-lib mixer API is used.
Takashi
On Tue, 2016-11-08 at 15:39 +0100, Takashi Iwai wrote:
Thanks for the explanation! If the sbase plugin is essentially a mandatory accompaniment of libasound, I'll move it to the libasound package, and since I don't see much benefit in keeping the hda and ac97 plugins in a separate package either, I'll move those too and get rid of the whole smixer plugin package.
Out of curiosity, in what situation are the hda and ac97 plugins used? You said that they are practically never used, but surely they have some purpose?
On Wed, 09 Nov 2016 15:39:26 +0100, Tanu Kaskinen wrote:
Actually, I was wrong. Even sbase.so isn't needed for the normal alsamixer / amixer operations. This is a base shared object that is needed for "basic" abstraction mode, but the normal mode (abstraction "none") doesn't need it.
That said, the whole /usr/lib*/alsa-lib/smixer/* stuff can be removed from your package as long as the normal mode is used.
There is an option -a to pass the abstraction level. When you pass "basic", the python module gets loaded. It was supposed to handle the card-specific abstraction parsed via python, but this seems currently broken. So it's maybe safer to disable as default...
Takashi
On Mon, 2016-11-14 at 11:38 +0100, Takashi Iwai wrote:
Ok, thanks for the update! I see you submitted a patch that disables these plugins if Python is disabled. OpenEmbedded builds alsa-lib without Python support, so I guess these plugins won't be available to OpenEmbedded users starting from alsa-lib 1.1.3. For now there's nothing I need to change in the packaging.
participants (2)
-
Takashi Iwai
-
Tanu Kaskinen