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

[Georg Chini]

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>