Re: R: New equalizer module (module-eqpro-sink), some questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16.04.19 21:40, Georg Chini wrote:
On 16.04.19 19:19, Tanu Kaskinen wrote:
On Thu, 2019-04-11 at 20:42 +0200, Georg Chini wrote:
On 11.04.19 19:36, Tanu Kaskinen wrote:
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:
Hi Andrea,


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.
For an interleaved audio port, there would be another control
port which holds the number of (interleaved) channels. So
this port would allow you to change the number of channels.
You could for example have an audio port named "Input"
and a control port "Number of input channels". Then the
get_info_port() function would return the index of the
"Number of input channels" control when called with the
"Input" port as argument. Or the other way round: If you
set "Number of input channels"  to 6 the plugin will expect
6 channels in the interleaved audio port (and you know
which control port sets the number of channels because
you can get it via the get_info_port() function.

The same applies to the number of bands. There must be a
control port which reflects the number of elements in the
control array which is the same as the number of bands.

Both values can be set to convenient defaults if the host does
not supply them (like 5 bands and 2 channels).
Ok, so the idea is to do the configuration while the filter is running. I think it would be better to do the configuration in the plugin setup phase. I imagine that would simplify the control port allocoation and management, since the setup doesn't have to run in the IO thread where malloc() is not allowed. I don't see much benefit in doing this kind of configuration while the filter is running, since the filter state most likely has to be reset anyway when the number of EQ bands is changed.

There could be a function for getting a description of what options the
plugin accepts, and a setup function for setting the options.

Why do you think that the filter must be configured while it is
running? In case of the equalizer the number of channels and
also the number of bands are known before the filter is run.
The LADSPA standard says all control ports must be connected
(and valid) before you can run the filter. If a parameter changes
at runtime, the filter must be reset like the current ladspa-sink
does.
One more comment: Parameter changes must in the end be
done in the IO thread anyway because the run() function is called
there. Only the initial setup can be done in the main thread when
the IO thread is not yet active. The sequence of a parameter
change is that you

1) Receive a parameter change in the main thread
2) Send a message to the IO thread to notify of the change
3) Copy the changed parameter(s) from the main thread
4) Reset the filter (by issuing a rewind request)

After that the filter can continue running.

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux