Bug 96821 - module-echo-cancel: aec_method='webrtc', pulseaudio gets killed with SIGKILL
Summary: module-echo-cancel: aec_method='webrtc', pulseaudio gets killed with SIGKILL
Status: RESOLVED MOVED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: modules (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-05 12:55 UTC by Antonio Ospite
Modified: 2018-07-30 10:08 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
pulseaudio kets killed when loadng the echo-cancel module with method=webrtc (5.03 KB, text/x-log)
2016-07-21 16:17 UTC, Antonio Ospite
Details

Description Antonio Ospite 2016-07-05 12:55:39 UTC
Hi,

I am trying the webrtc AEC, and pulseaudio gets killed with SIGKILL when using relatively "higher quality" formats.

The issue happens if I load module-echo-cancel with use_master_format=1 (in my case that's format=s16le rate=16000 channels=4), but does not happen when using lower quality formats, e.g.: "format=s16le rate=8000 channels=4"

I can work around the issue and make the master format work by loading pulseaudio with --realtime=false

JFYI, I am using the standard kernel shipped by Debian, the CPU is a very old AMD Athlon(tm) 64 X2.

Thanks,
   Antonio
Comment 1 Arun Raghavan 2016-07-14 03:21:09 UTC
That's quite odd. On my laptop (admittedly a recent Core i7), I was running with rate=48000 channels=2 without anywhere near maxing out the CPU.

What is CPU usage like in the working case? And can you see what it's like before PA gets killed?
Comment 2 Antonio Ospite 2016-07-21 16:17:20 UTC
Created attachment 125234 [details]
pulseaudio kets killed when loadng the echo-cancel module with method=webrtc

Hi,

please find attached the output of "pulseaudio -v" after loading the module, the last line "Ucciso" is from the shell and means "Killed".
Comment 3 Arun Raghavan 2016-07-28 05:00:38 UTC
(In reply to Arun Raghavan from comment #1)
[...]
> What is CPU usage like in the working case? And can you see what it's like
> before PA gets killed?
Comment 4 Antonio Ospite 2016-07-28 15:16:45 UTC
(In reply to Arun Raghavan from comment #3)
> (In reply to Arun Raghavan from comment #1)
> [...]
> > What is CPU usage like in the working case? And can you see what it's like
> > before PA gets killed?

You are right, I didn't answer the question about CPU usage.

So, to recap, I am using the kernel from Debian, I am using pulseaudio 9.0 from the Debian packages (but it's the same if I compile my own) like this: LANG=C pulseaudio -v

LANg=C is needed here because of Bug #96819.

I load the echo-cancel module like this:

pactl load-module module-echo-cancel format=s16le rate=8000 channels=4 aec_method='webrtc' aec_args='"beamforming=1 mic_geometry=-0.03,0,0,-0.01,0,0,0.01,0,0,0.03,0,0"'

I start recording form the echo canceled source like this:
gst-launch-1.0 pulsesrc device-name=alsa_input.usb-OmniVision_Technologies__Inc._USB_Camera-B4.04.27.1-01.multichannel-input.echo-cancel ! fakesink

and the pulseaudio CPU usage is between 6% and 7.3%

If I load the module with other values for the rate parameter, and do nothing else pulseaudio gets killed after some seconds.

But I noticed that it stays alive if I start to record right after I loaded the module, regardless of the format, I even tried with 48000. The CPU usage is always in the range of 6-7.3% when recording.

What kind of logs should I send?
I will also try with the kinect  and see if I get the same behavior.

Thanks,
   Antonio
Comment 5 GitLab Migration User 2018-07-30 10:08:21 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/229.


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.