On 12.11.2017 20:39, wellington wallace wrote: > On Sun, Nov 12, 2017 at 12:05 PM, Georg Chini <georg at chini.tk > <mailto: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? > No, there isn't. >> 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 > And as gmail considered your answer to mikhailnov a spam I did not > notice you had already asked to not do it :-( > Yes, unfortunately some mail providers consider .tk domains as spam. > > 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? I just sent a patch to the list that should solve your problem. I asked Tanu, and he said it would be OK if module-switch-on-connect ignores virtual sinks/sources by default. So with the patch, the module will only switch to new hardware sinks/sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20171113/6c433c55/attachment.html>
