[pulseaudio-discuss] module-switch-on-connect: handling virtual sinks
georg at chini.tk
Mon Nov 13 17:55:39 UTC 2017
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
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
> 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
> 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
So with the patch, the module will only switch to new hardware
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss