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

[Georg Chini]

On 04.05.19 01:34, Alexander E. Patrakov wrote:
> пт, 3 мая 2019 г. в 23:04, Georg Chini <georg at chini.tk>:
>> On 03.05.19 16:32, Alexander E. Patrakov wrote:
>>> пт, 3 мая 2019 г. в 11:57, Georg Chini <georg at chini.tk>:
>>>> The channel layout of input/output
>>>> and the playback device is known to module-plugin-sink, so if
>>>> a filter needs it, it can be passed as parameter. No need to
>>>> have it in the interface.
>>> (I have also received your next email, ACK on the thought that the
>>> channel maps don't change on the fly).
>>>
>>> Having it (also with other properties like sink or port name) as a
>>> parameter is indeed a neat idea that solves a lot of problems.
>> Why would the filter code need the sink name? I understand
>> that it can be useful to know what kind of output you have,
>> but the sink name will not mean anything to the filter. The
>> plugins are compiled outside PA, similar to LADSPA plugins.
> Because filter sinks can, in theory, be moved, e.g. due to device
> hotplug or port status change, to a different master sink, to which
> they somehow know they are not applicable.

The filter cannot have a knowledge which sink is "good" or "bad",
as a user you can always rename a sink. This makes it impossible
for a filter to decide if it is applicable based on the sink name.
This is different if the filter is implemented within PA, like the
virtual surround sink. Here you could check after a move if the
number of channels or other conditions do still match.

>
>>> However, we should still think about the boolean bypass parameter, how
>>> it is supposed to work. Is my understanding below correct?
>>>
>>> 1. The virtual surround filter gets created by PulseAudio for 6 input
>>> and 2 output channels and gets the input channel layout (5.1), output
>>> channel layout (stereo), and playback sink and port as parameters.
>>> 2. Some audio plays through it.
>>> 3. The user unplugs headphones, so that the output now goes through
>>> stereo speakers
>>> 4. Before sending the next chunk of audio, PulseAudio updates the
>>> filter parameters related to the sink port (a), and/or calls the
>>> set_port callback function (b).
>>> 5a. The filter notices the parameter change, processes the audio
>>> anyway, and sets the self-disable parameter to true.
>>> 6a. PulseAudio reads the audio and the self-disable parameter, throws
>>> away the processed audio and downmixes 5.1 to stereo by itself.
>>> 5b. set_port says "no" or updates the self-disable parameter,
>>> PulseAudio notices and downmixes 5.1 to stereo by itself.
>> When the filter is in the chain, audio is processed by the filter.
>> Therefore, down mixing would have to be implemented in the
>> filter code. The next chunk after the parameter change would
>> need to be down mixed.
>> It is impossible to pass the original signal on to PA without
>> destroying and re-creating the sink input. (See also below).
> And that's exactly the problem with the filter sink model when the
> filter is applicable only in some cases that depend e.g. on what's
> connected.
>
> I have just tried to do this:
>
> 0. Make sure that both analog outputs and HDMI outputs are available
> as two sinks
> 1. Add a module-virtual-sink on top of analog stereo output, play some
> file in vlc through it.
> 2. Switch the analog sound card profile to 5.1 profile. AFAIK this
> could happen automatically on headphone unplugging on systems that
> have a separate headphone jack (mine doesn't, it only has line
> outputs, spdif, line input and microphone input on the back panel).
>
> Result: the virtual sink is still on top of the onboard analog sound
> card, and vlc is still playing through it.
Yes, but it is playing on a new sink. So if you really want to be
sure that the filter does not move, you can use the autoloaded
flag. This will kill the filter, if the master sink moves (that is
changes number of channels), but not if you switch from
headphones to speaker.
>
> I don't mind at all if you use the existing virtual surround sink code
> as an example to validate your API, but due to the above scenario, I
> think that it was a mistake to implement the virtual surround effect
> as a virtual sink. It should have been a special case in the remixer,
> just like the current LFE remixing code is now.

I don't use the virtual surround sink as an example for the external
API. I converted it to the internal version of the API though. To test
the external API I have written a small demo amplifier plugin. As
said above, the virtual surround sink module could check which
kind of sink it is playing on and react accordingly.