On 04.05.19 01:34, Alexander E. Patrakov wrote:
пт, 3 мая 2019 г. в 23:04, Georg Chini <georg@xxxxxxxx>:
On 03.05.19 16:32, Alexander E. Patrakov wrote:
пт, 3 мая 2019 г. в 11:57, Georg Chini <georg@xxxxxxxx>:
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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
