[pulseaudio-discuss] new module module-plugin-sink

[Georg Chini]

On 04.05.19 20:54, Alexander E. Patrakov wrote:
> сб, 4 мая 2019 г. в 20:25, Georg Chini <georg at chini.tk>:
>> On 04.05.19 16:42, Alexander E. Patrakov wrote:
>>> сб, 4 мая 2019 г. в 16:17, Georg Chini <georg at chini.tk>:
>>>> Here is the new version of the header file, based on your feedback.
>>>> The main changes are:
>>>>
>>>> - The create_filter() function now receives the channel maps for input
>>>> and output.
>>>> - The create_filter() function receives a kill_filter() function and a
>>>> module pointer
>>>>       which makes it possible for the filter to initiate unloading of the
>>>> module if it
>>>>       detects that it is no longer applicable.
>>>> - An output_changed() function was added which communicates current sink
>>>>      and port name to the filter, so that it can detect if the output has
>>>> changed.
>>>>
>>>> Also I did a bit of cleanup and added a few more comments. Hope it looks
>>>> better now.
>>> It definitely looks better.
>>>
>>> I am still confused about disable_rewind and max_latency. Let's
>>> suppose that someone wants to implement a rewindable filter. In this
>>> case, they need to keep history, because PulseAudio can ask the filter
>>> to rewind some samples. And, as it is not allowed to say "no", they
>>> must keep enough history to satisfy any possible rewind request. But
>>> some upper bound must exist. Do I understand correctly that
>>> max_latency serves as such upper bound?
>>>
>>> Regarding the non-rewindable filters, we do need to limit the latency,
>>> but I believe it is wrong for each individual filter to specify its
>>> own value for such limit. It should be a global policy (the same value
>>> for all non-rewindable sinks), and I don't see any reason for the
>>> filter to be able to influence it.
>>>
>>> Therefore, I believe these two fields can be replaced by one,
>>> max_rewind, which is the size of history, in samples, that the filter
>>> is willing to keep. Zero means a non-rewindable filter.
>>>
>> That sounds like a good suggestion. I would however think
>> that it is better if 0 means that the filter will rewind as far as
>> PA wants it to. There may be filters that are stateless (like the
>> trivial amplifier example). We could use -1 to disable rewinding.
> OK.
>
>> That would also mean to limit the latency to whatever the filter
>> can rewind, correct? I would use the maximum of max_rewind
>> and the default latency for non-rewindable filters as the
>> max_latency value then, because I don't think it makes sense
>> to set the maximum latency even smaller than for non-rewindable
>> filters.
> Makes sense.
>
>> What do you think is reasonable for non-rewindable filters?
>> 50 ms?
> There were different opinions on that matter. 50 ms is indeed in a
> range that I would agree to.
>
Just finished the next version. Does this look OK to you now?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: filter-plugin.h
Type: text/x-chdr
Size: 13741 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20190504/019325b2/attachment-0001.h>