* How to package the smixer modules? @ 2016-11-07 12:43 Tanu Kaskinen 2016-11-08 14:39 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Tanu Kaskinen @ 2016-11-07 12:43 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to package the smixer modules? 2016-11-07 12:43 How to package the smixer modules? Tanu Kaskinen @ 2016-11-08 14:39 ` Takashi Iwai 2016-11-09 14:39 ` Tanu Kaskinen 0 siblings, 1 reply; 6+ messages in thread From: Takashi Iwai @ 2016-11-08 14:39 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to package the smixer modules? 2016-11-08 14:39 ` Takashi Iwai @ 2016-11-09 14:39 ` Tanu Kaskinen 2016-11-14 10:38 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Tanu Kaskinen @ 2016-11-09 14:39 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to package the smixer modules? 2016-11-09 14:39 ` Tanu Kaskinen @ 2016-11-14 10:38 ` Takashi Iwai 2016-11-14 14:44 ` Tanu Kaskinen 0 siblings, 1 reply; 6+ messages in thread From: Takashi Iwai @ 2016-11-14 10:38 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to package the smixer modules? 2016-11-14 10:38 ` Takashi Iwai @ 2016-11-14 14:44 ` Tanu Kaskinen 2016-11-14 15:22 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Tanu Kaskinen @ 2016-11-14 14:44 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to package the smixer modules? 2016-11-14 14:44 ` Tanu Kaskinen @ 2016-11-14 15:22 ` Takashi Iwai 0 siblings, 0 replies; 6+ messages in thread From: Takashi Iwai @ 2016-11-14 15:22 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-11-14 15:22 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-11-07 12:43 How to package the smixer modules? Tanu Kaskinen 2016-11-08 14:39 ` Takashi Iwai 2016-11-09 14:39 ` Tanu Kaskinen 2016-11-14 10:38 ` Takashi Iwai 2016-11-14 14:44 ` Tanu Kaskinen 2016-11-14 15:22 ` Takashi Iwai
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).