On Mon, 14 Nov 2016 15:44:03 +0100, Tanu Kaskinen wrote:
On Mon, 2016-11-14 at 11:38 +0100, Takashi Iwai wrote:
On Wed, 09 Nov 2016 15:39:26 +0100, Tanu Kaskinen wrote:
On Tue, 2016-11-08 at 15:39 +0100, Takashi Iwai 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.
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?
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...
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.
Correct.
For now there's nothing I need to change in the packaging.
Right :)
Takashi