Bug 100403 - module-echo-cancel: Should automatically switch to a new default source_master and sink_master...
Summary: module-echo-cancel: Should automatically switch to a new default source_maste...
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: modules (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
Depends on:
Reported: 2017-03-26 16:53 UTC by Robert
Modified: 2018-07-30 10:04 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Robert 2017-03-26 16:53:41 UTC
...at least if the parameter "source_master" and "sink_master" was not explicitly given  at load time of the module "module-echo-cancel".

My concrete  problem is that I have put the module in the default.pa for automatic loading at startup, and everything works fine.

But then I connect my Headset and Pulseaudio switches the Port automatically to "Headphones" (as it should do), but the "module-echo-cancel" does not automatically switches to the new "sink_master".

This is very annoying because now I have to unload the "module-echo-cancel" manually  and reload it again.
I think the same is happening if you have a USB- Headset and use the module "module-switch-on-connect".

My entries in  default.pa:

load-module module-echo-cancel use_volume_sharing=1 use_master_format=1 aec_method=webrtc aec_args="digital_gain_control=1 experimental_agc=1 analog_gain_control=0 noise_suppression=1 voice_detection=1 extended_filter=1" source_name=echoCancel_source sink_name=echoCancel_sink

set-default-source echoCancel_source
set-default-sink echoCancel_sink
Comment 1 Arun Raghavan 2017-03-27 07:15:58 UTC
A 'port' is not a new sink/source -- it is just a different route on the same device. So nothing should really change in this case (the echo canceller will continue to apply to the cancelled output).

With a USB headset, things are different because you get a new sink and source.

The ideal case, though, is that the program you're using just marks its own stream with the property 'filter.want=echo-cancel'. This will make PA dynamically apply echo cancellation on the streams where it is needed.
Comment 2 Robert 2017-03-27 19:29:48 UTC
In my case if I plug in my headset the default sink switches from "<alsa_output.pci-0000_00_1f.3.analog-surround-51>" to "<alsa_output.pci-0000_00_1f.3.analog-stereo>".

No I think in my case 'filter.want=echo-cancel' would be not the best solution, because I guess if I would start for example Mumble with 'filter.want=echo-cancel', and I don't use my Headset, the sounds of a game or the music player would not be filtered out.
This is the reason why I let everything run through my "echoCancel_source" and "echoCancel_sink", but correct me if I am wrong.
Comment 3 Robert 2018-02-18 15:35:49 UTC
Until today the "ideal case" which was talked about still is not reality, and I don't know if it ever will be, and even if, my favorite IM/VOIP program is running all the time and so the module-echo-cancel would be loaded all the time anyhow.

Another problem with this "ideal case" is that it is not possible to set a system wide enforced default for which parameters are used when the module-echo-cancel is automatically loaded.
The new not really documented "filter.apply.echo-cancel.parameters" would not help, because every developer would have to use this also, and I doubt that they would use the settings which I prefer and need.

So I still think that an option to tell the "module-echo-cancel" that it always should stick to the default source_master and sink_master would be helpful to many people.
Comment 4 GitLab Migration User 2018-07-30 10:04:30 UTC
-- 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/196.

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.