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