[pulseaudio-discuss] module-switch-on-connect: handling virtual sinks

wellington wallace wellingtonwallace at gmail.com
Sun Nov 12 19:39:20 UTC 2017

On Sun, Nov 12, 2017 at 12:05 PM, Georg Chini <georg at chini.tk> wrote:

> On 12.11.2017 14:36, wellington wallace wrote:
> Another thing that would work is telling Pulseaudio that null sinks
> created by PulseEffects should never be used as fallback devices. If this
> was a null sink property I could set it in PulseEffects code and the user
> would not have to mess with Pulseaudio's configuration.
> As we are talking about null sinks I would like to ask one more question.
> Is it possible to change a null sink rate after it was created? I searched
> in the libpulse api docs but I could not find a way. I am asking because at
> PulseEffects startup I set the null sink rate to the same rate of the
> current fallback device. If the user changes the fallback device to one
> with different sampling rate while PulseEffects is open we will have
> unnecessary resampling as the null sink is using the rate of the previous
> device.
> Best regards
>                Wellington
> Please don't top post. Does that mean the original question was not about
> virtual sinks
> but about the null sink? The null sink is not counted as a virtual sink
> and the patch I sent
> is useless in that case. The null sinks could however be excluded in
> module-switch-on-connect by a similar approach.
> I guess it would also be possible to set some "do-not-use-as-default"
> property on a sink
> that could be parsed by the default sink selection process, but that would
> not only affect
> module-switch-on-connect but would also need to be considered in the core.
> On Sat, Nov 11, 2017 at 10:03 AM, Михаил Новоселов, Думалогия <
> mikhailnov at dumalogiya.ru> wrote:
>> Yes, of course, it's possible to unload module-switch-on-connect, but
>> that is breaking the existimg user setup.
>> "a command line switch could be added
>> to the module so that it ignores virtual sinks" Will be best. Does this
>> flag exist now?
>> 11 ноября 2017 г. 14:26:21 GMT+03:00, Georg Chini <georg at chini.tk>
>> пишет:
>>> On 11.11.2017 05:28, Михаил Новоселов, Думалогия wrote:
>>>>  Hello,
>>>>  PulseEffects, an application, that can apply different effects or
>>>>  equalize both input and output sound, cannot work properly when
>>>>  module-switch-on-connect is on. PulseEffects creates a virtual sinks,
>>>>  but PulseAudio's module-switch-on-connect makes it a default sinks
>>>>  automatically what severely breaks the logic of PulseEffect's work.
>>>>  Please see https://github.com/wwmm/pulseeffects/issues/99
>>>>  1) Can we specify that the created sink is a virtual one?
>>>>  2) Maybe there are other ways to prevent module-switch-on-connect from
>>>>  making a newly created virtual device a default one?
>>>>  I wrote the script Dumacast https://github.com/mikhailnov/dumacast
>>>>  (first of all for my company's (Dumalogiya, http://думалогия.рф <http://xn--80agbsneq0b4h.xn--p1ai>)
>>>>  internal usage), and starting with the newest version of Ubuntu, where
>>>>  module-switch-on-connect is on, I ran into the same troubles. My
>>>>  script
>>>>  https://github.com/mikhailnov/dumacast/blob/master/usr/bin/dumacast
>>>>  creates virtual sinks via pactl (lines 135-149), and they are also
>>>>  made default and break the logic of how the script works. I currently
>>>>  have no idea how to handle it without unloading module-switch-on-connect.
>>>>  I tried both Ubuntu's 17.10 default PulseAudio and built from dEbian
>>>>  sources PulseAudio 11, the situation is the same with them both.
>>>>  What can be done?
>>> Do you really need module-switch-on-connect? If not, you could just
>>> check with
>>> "pactl list modules short" if the module is loaded and unload it prior
>>> to starting
>>> your application. You can also remove it from default.pa, so that it
>>> never gets
>>> loaded.
>>> If you need module-switch-on-connect, a command line switch could be added
>>> to the module so that it ignores virtual sinks. The default behavior
>>> however can
>>> not be changed, because other applications might rely on the current setup.
>>> Regards
>>>               Georg
>>> --
>> Простите за краткость, создано в K-9 Mail.
> --
> Prof.° Wellington Wallace Miguel Melo
> CEFET/RJ Uned Nova Iguaçu
> Sorry for the top post. I forgot this is not allowed in this list. And as
gmail considered your answer to mikhailnov a spam I did not notice you had
already asked to not do it :-(

Yes, what I am using in PulseEffects are null sinks. The workflow is more
or less the following. The audio application sink input is moved from the
default sink to a null sink created by PulseEffects. Then a Gstreamer
pipeline records from this null sink monitor and applies effects. After
that Gstreamer plays to the default sink. I use a similar logic to apply
effects for microphone. But in that case Gstreamer records from the
microphone applies effects and then plays to a null sink. Applications
recording from this null sink monitor will have the audio from the
microphone with effects applied. So we have 2 null sinks and the last one
loaded is being set as default sink by module-switch-on-connect. This
obviously breaks all the logic I am using.

I think we can live with a switch in module-switch-on-connect. In this case
I would have to use libpulse api to detect it is running and then
unload/load it with the new option to ignore null sinks. Could this
loading/unloading performed while Pulseaudio is running be a problem?

Thank you for your time


Prof.° Wellington Wallace Miguel Melo

CEFET/RJ Uned Nova Iguaçu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20171112/117820c2/attachment.html>

More information about the pulseaudio-discuss mailing list