Somehow the mail did not go to the list.
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.
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.
Regards
Georg
--- src/modules/ladspa.h 2018-12-28 14:48:36.743533708 +0100
+++ /home/georg/ladspa_extended.h 2019-04-11 14:46:42.916944707 +0200
@@ -62,6 +62,11 @@
have been connected to the relevant data location (see the
`connect_port()' function below) before it is asked to run.
+ For plugins that use the extended specification, control ports
+ may also be arrays. If they are, there must be another contol port
+ that specifies the size of the array. This port can be retrieved
+ using the get_info_port() function.
+
Plugins will reside in shared object files suitable for dynamic
linking by dlopen() and family. The file will provide a number of
`plugin types' that can be used to instantiate actual plugins
@@ -164,10 +169,22 @@
port. */
#define LADSPA_PORT_AUDIO 0x8
+/* Property LADSPA_PORT_ARRAY indicates that a control port is an array.
+ Only used by the extended standard. */
+#define LADSPA_PORT_ARRAY 0x10
+
+/* Property LADSPA_PORT_INTERLEAVED indicates that an audio port contains
+ interleaved data. If an audio port is interleaved, it is expected that
+ there are no other ports of the same type (input or output). Only used
+ by the extended standard. */
+#define LADSPA_PORT_INTERLEAVED 0x20
+
#define LADSPA_IS_PORT_INPUT(x) ((x) & LADSPA_PORT_INPUT)
#define LADSPA_IS_PORT_OUTPUT(x) ((x) & LADSPA_PORT_OUTPUT)
#define LADSPA_IS_PORT_CONTROL(x) ((x) & LADSPA_PORT_CONTROL)
#define LADSPA_IS_PORT_AUDIO(x) ((x) & LADSPA_PORT_AUDIO)
+#define LADSPA_IS_PORT_ARRAY(x) ((x) & LADSPA_PORT_ARRAY)
+#define LADSPA_IS_PORT_INTERLEAVED(x) ((x) & LADSPA_PORT_INTERLEAVED)
/*****************************************************************************/
@@ -466,6 +483,20 @@
unsigned long Port,
LADSPA_Data * DataLocation);
+ /* If a control port is an array, there must be another control port
+ which holds the size of the array. The function will return the
+ index of the port that holds the array size.
+
+ If a port is an audio port which uses interleaved format, then the
+ function will return the port which contains the number of
+ interleaved channels.
+
+ If the Port argument is no control array or interleaved audio
+ port, the function must return unsigned long -1. This function
+ is only needed for the extended standard. */
+ unsigned long (*get_info_port)(LADSPA_Handle Instance,
+ unsigned long Port);
+
/* This member is a function pointer that initialises a plugin
instance and activates it for use. This is separated from
instantiate() to aid real-time support and so that hosts can
@@ -574,7 +605,13 @@
"ladspa_descriptor" with the following function prototype within
the shared object file. This function will have C-style linkage (if
you are using C++ this is taken care of by the `extern "C"' clause
- at the top of the file).
+ at the top of the file). If the library contains plugins that follow
+ the extended specification, it must provide a function called
+ "ladspa_extended_descriptor". The ladspa_descriptor function should
+ only enumerate those plugins that follow the original standard while
+ ladspa_extended_descriptor enumerates all plugins. This ensures that
+ libraries containing extended plugins can still be used by hosts
+ that implement the normal standard.
A host will find the plugin shared object file by one means or
another, find the ladspa_descriptor() function, call it, and
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
