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

[Alexander E. Patrakov]

пт, 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.

> > 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.

If this happens with a module-virtual-surround-sink, then it would
convert the 5.1 sound from vlc to stereo according to an algorithm
that is only valid for headphones (or, according to any other
algorithm that it falls back to), and then PulseAudio would upmix this
back to 5.1. Which is bad. The original 5.1 sound should have been
passed through. Or, if it was not 5.1, the remixing should have
happened from the original, not from the sound corrupted to stereo by
the virtual-surround effect.

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 do understand that there are cases where the "external filter plugin
sink" model is applicable. Just saying that virtual surround, if done
properly, is not one of them.

> > It would also be interesting to see what happens if unplugging the
> > headphones causes the number of channels (of the channel layout in
> > general) to change. Note that I don't have such setup, not even sure
> > how it is handled currently.
> >
> The sink input that the filter uses will not change, regardless
> what kind of sink the input is connected to. From the filter
> perspective the channel counts and layouts are static. What does
> PA usually do if the number of channels for a stream does not
> match the number of sink channels, for example if you play
> stereo content to a 5.1 sink?

It remixes the content according to the settings in daemon.conf such
as enable-remixing, remixing-use-all-sink-channels and
enable-lfe-remixing.

-- 
Alexander E. Patrakov