I use the following "chain" for VoIP audio processing: # VoIP apps: higher tone load-module module-ladspa-sink sink_name=spk-voip-eq-out plugin=mbeq_1197 label=mbeq control=-30.0,-19.1,-18.6,-18.6,-18.6,-10.0,-8.0,-6.5,1.5,1.5,1.5,8.5,10.6,10.6,10.6 # VoIP apps: joint volume control load-module module-null-sink sink_name=spk-voip-vol-out sink_properties='device.description="Speaker VoIP Volume Out"' load-module module-loopback source=spk-voip-vol-out.monitor sink=spk-voip-eq-out latency_msec=4 The problem is a huge, persistent, 100% reproducible delay that appears on the loopback after VT switch. The delay could be 5 seconds or even more, followable on volume meters of pavucontrol. No problem if loopback's sink is other loopback or hardware device instead of ladspa-sink OR user is a member of the `audio` group thus access is not suspended on VT switch. Need to restart pulseaudio to get rid of the introduced delay. Temporary moving of loopback's sink to other loopback or hardware device eliminates the delay but it returns after restore. Pulseaudio does not log anything that worth to mention. I have nothing special in my PA config but I can share as is if necessary. Fedora 27, pulseaudio-11.1-7.fc27.x86_64
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/156.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.