How to package the smixer modules?

How to package the smixer modules?

[Tanu Kaskinen]

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.

-- 
Tanu

https://www.patreon.com/tanuk

Re: How to package the smixer modules?

[Takashi Iwai]

On Mon, 07 Nov 2016 13:43:49 +0100,
Tanu Kaskinen wrote:
> 
> 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.

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

Re: How to package the smixer modules?

[Tanu Kaskinen]

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?

-- 
Tanu

https://www.patreon.com/tanuk

Re: How to package the smixer modules?

[Takashi Iwai]

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...


Takashi

Re: How to package the smixer modules?

[Tanu Kaskinen]

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. For now there's
nothing I need to change in the packaging.

-- 
Tanu

https://www.patreon.com/tanuk
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: How to package the smixer modules?

[Takashi Iwai]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel