On Thu, 2019-04-11 at 15:16 +0200, Georg Chini wrote: > On 08.04.19 09:27, Georg Chini wrote: > > On 05.04.19 13:29, Tanu Kaskinen wrote: > > > On Tue, 2019-04-02 at 20:28 +0200, Georg Chini wrote: > > > > On 06.11.18 22:14, Andrea A wrote: > > > > > Thanks a lot for the reply > > > > > > > > > > > If the preset files are expected to be shared between users, then the > > > > > database.h stuff isn't good, because different users can have their > > > > > pulseaudio configured with different database formats. I like the > > > > > "ini- > > > > > style" configuration file style that pulseaudio uses for .conf files. > > > > > There are no helpers for writing those files, though, but that's > > > > > probably not a big issue. > > > > > > > > > > I can write a parser for ini-style file however since PA is > > > > > multiplatform I need some information about how to store user and > > > > > system settings. System settings can be hardcoded at least, but the > > > > > directory of user config depends on the platform I think. > > > > > > > > > > > Iwould love to have the equalizer as a LADSPA plugin > > > > > My fear is that a LADSPA plugin will be too hard to use for a lot of > > > > > desktop users. I think that a GNU desktop user would like to have a > > > > > fully working audio equalizer in his distribution and PA is default in > > > > > almost all GNU distributions. Configuring a LADSPA plugin may be hard > > > > > and boring for the average user and GNU will continue to don't have a > > > > > standard equalizer. Beyond the issues you've already listed. > > > > > > > > > > > It's not very uncommon that some core > > > > > change requires changes in all sinks, so even if the module is perfect > > > > > and doesn't require maintenance in form of bug fixes, there are other > > > > > kinds of real maintenance costs. > > > > > > > > > > As far as I know the actual equalizer is deprecated so if this mine > > > > > equalizer will be adequate I think that the actual can be substitute > > > > > and the number of modules to maintain will not change. > > > > > > > > > > Andrea993 > > > > > > > > > > > > > > Hi Andrea, > > > > > > > > > > > > maybe there is a chance now to have your equalizer included as a > > > > module. > > > > The messaging API patches > > > > should have their final form (at least I do not think the public > > > > functions will change anymore) and today > > > > I submitted a patch series that consolidates the code of the current > > > > virtual sinks and moves the common > > > > code to a separate file. Using the common code should significantly > > > > reduce the maintenance cost of an > > > > additional sink. > > > > > > > > So if you are still interested to have it included, at least I would > > > > welcome a new patch. > > > > > > > > > > > > Arun, Tanu, what do you think? > > > I think it would anyway make sense to make one or more LADSPA plugins > > > out of the equalizer code (I say one or more, because of the lack of > > > parametrization support in LADSPA). That way the equalizer would be > > > available also to other software than just PulseAudio (I'm thinking > > > PipeWire in particular). > > > > > > If a suitable LADSPA plugin existed, we might or might not still need a > > > separate equalizer module, but in any case we wouldn't need to maintain > > > the DSP code in PulseAudio. If there's some reason why module-ladspa- > > > sink isn't (and can't become) suitable for implementing the integration > > > in PulseAudio, then a specialized module is fine. > > > > > > I'm not saying that I'm dead against hosting the DSP code in > > > PulseAudio, but I'd certainly prefer not to. > > > > > It surely would make sense to have one or several LADSPA > > plugins, but for me a good equalizer should be an integral > > part of pulseaudio. And as you say yourself, the full flexibility > > cannot be achieved by a single LADSPA plugin. The equalizer > > we are currently providing is buggy and completely unsupported. > > The new equalizer would at least be fully documented, so that > > it is possible to maintain. Additionally I agree with Andrea that > > handling LADSPA plugins is somewhat cumbersome. From a > > user point of view, a module is much easier to handle. > I have taken a more detailed look on the LADSPA standard and > to me it appears like you would not only need different plugins for > different numbers of equalizer channels but in addition also > for different number of audio channels. Both, the number of > single-value parameters and number of input-/output-channels > seem to be fixed, so producing a bunch of plugins is rather > impractical. An equalizer plugin doesn't need multiple channels, one mono plugin can be instantiated for each channel. Or does this equalizer have some cross-channel effects? > I wonder if there is a chance to extend the standard a bit to > allow a variable number of audio channels and allow control > ports to be arrays. It can be done with two more constants and > one additional function, see attached diff. This extension would > allow to reduce many of our virtual sinks to one plugin-sink and > also allow full integration of Andrea's equalizer. Do you have in mind actually extending the LADSPA standard (i.e. something to be promoted to other projects as well), or just creating a new custom (i.e. non-standard) plugin API for PulseAudio that is based on LADSPA? If you want a better plugin standard, are you aware of LV2 and PipeWire's SPA (the latter doesn't seem to be properly documented yet, but to my understanding it's supposed to have a stable and flexible API)? You say that your extension allows full integration of Andrea's equalizer, but I don't see how it allows the host to tell the plugin how many channels and how many frequency bands it should initialize. Which virtual sinks do you think could be replaced by the one plugin- sink? -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
