#1457 closed defect (fixed)
Abnormal CPU usage on server while client is connected
Reported by: | psycho_zs | Owned by: | psycho_zs |
---|---|---|---|
Priority: | major | Milestone: | 2.0 |
Component: | server | Version: | trunk |
Keywords: | Cc: |
Description
Using r15223, while client is connected, server hogs CPU. Even if no X clients are running.
Attached log of -d all
: server started, client connected, client disconnected, server stopped.
Attachments (5)
Change History (24)
Changed 4 years ago by
comment:1 Changed 4 years ago by
Owner: | changed from Antoine Martin to psycho_zs |
---|
comment:2 Changed 4 years ago by
top reports 100% for xpra, load average closing to 1. So it seem to load one core to the top.
It is indeed caused by sound forwarding. Switching it off removes the load.
comment:3 Changed 4 years ago by
Owner: | changed from psycho_zs to Antoine Martin |
---|---|
Status: | new → assigned |
I assume that the OS is Debian Stretch again.
Will take a look when I get a chance, we're not seeing that on any other distro.
comment:4 Changed 4 years ago by
Milestone: | → 2.1 |
---|---|
Owner: | changed from Antoine Martin to psycho_zs |
Status: | assigned → new |
I cannot reproduce on Debian Stretch: I've tried 1.0.4 as client, server and both client and server on the same VM - the load was as expected (a few percent with speaker forwarding enabled), please run with XPRA_SOUND_DEBUG=1
and attach the output.
You may also want to grab a few gdb backtraces to see what exactly the code is busy waiting on.
Changed 4 years ago by
comment:5 Changed 4 years ago by
Attached the log of switching speaker on, then off. Lots of "new_sound_buffer" messages
comment:6 Changed 4 years ago by
There is nothing unexpected in that log sample: we get a new_sound_buffer
every 40ms and process it. Any modern CPU should be able to handle this easily.
The gstreamer pipeline we use is shown as:
autoaudiosrc name="src" ! \ queue name=queue min-threshold-time=0 max-size-buffers=0 max-size-bytes=0 max-size-time=50000000000000 leaky=2 ! \ audioconvert ! \ volume name=volume volume=1.0 ! opusenc complexity=0 ! \ oggmux max-delay=20000000 max-page-delay=20000000 ! \ appsink name=sink emit-signals=true max-buffers=10 drop=true sync=false async=false qos=false
You should be able to run the same pipeline without using xpra:
gst-launch audioconvert ! ...
(just replace "appsink name=..." with "fakesink")
Does that produce the same level of CPU usage?
You may want to try different sound codecs (see --speaker-codec=help
option), in particular the ones that compress badly or not at all (wav+lz4, wav+lzo, wav)
comment:7 Changed 4 years ago by
Tried running this in shell:
gst-launch-1.0 audioconvert \! volume name=volume volume=1.0 ! opusenc complexity=0 \! oggmux max-delay=20000000 max-page-delay=20000000 \! appsink name=sink emit-signals=true max-buffers=10 drop=true
and
gst-launch-1.0 audioconvert \! volume name=volume volume=1.0 ! opusenc complexity=0 \! oggmux max-delay=20000000 max-page-delay=20000000 \! fakesink
It didn't load CPU.
Running xpra with --speaker-codec=wav
still results in 100% CPU usage.
comment:8 Changed 4 years ago by
Then it looks like using gstreamer through the python bindings is what is causing the unexpected CPU usage.
You can identify the command line of the xpra sound subprocess with:
ps -ef | grep [s]ound_record
Then you can run it manually (ie: using the command line I get - yours will be different, probably python2 and a different device):
python3 /usr/bin/xpra _sound_record - - pulsesrc device=alsa_output.pci-0000_00_1f.3.analog-stereo.monitor opus+ogg 1.0
If that still uses too much CPU then you can more easily run it within GDB or with gstreamer debugging turned on:
GST_DEBUG=5 python3 /usr/bin/xpra ...
comment:9 Changed 4 years ago by
cmdline of the CPU hogging process is:
/usr/bin/python /usr/bin/xpra _sound_record - - autoaudiosrc wav 1.0
But running it manually results in error:
xpra initialization error: not enough arguments File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 139, in main return run_mode(script_file, err, options, args, mode, defaults) File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 1225, in run_mode return run_sound(mode, error_cb, options, args) File "/usr/lib/python2.7/dist-packages/xpra/sound/wrapper.py", line 170, in run_sound assert len(args)>=6, "not enough arguments"
comment:10 Changed 4 years ago by
The "options" argument (where my command line specifies the device) is empty in your case, just use an empty string instead:
/usr/bin/python /usr/bin/xpra _sound_record - - autoaudiosrc "" wav 1.0
I'm not sure why your system uses autoaudiosrc and not pulsesrc, only pulsesrc is really well tested. That could well be part of the problem.
Changed 4 years ago by
Attachment: | manual_sound_output.txt added |
---|
comment:11 Changed 4 years ago by
Attached stdout.
Stderr was this:
2017-03-13 13:26:13,501 Warning: failed to parse dictionary option '1.0': 2017-03-13 13:26:13,501 need more than 1 value to unpack 2017-03-13 13:26:14,093 using audio codec wav
Pulseaudio is not installed, so I guess it is normal that pulsesrc is not used.
comment:12 Changed 4 years ago by
The fact that pulseaudio is not installed may be an important part of the puzzle, please make sure to record that information in the ticket earlier in the future.
See the guidelines here: wiki/ReportingBugs (having the exact command lines for example)
Using other sound servers is not fully supported: it's not well tested at all, though it should still work, at least in theory.
I've just removed pulseaudio
and pulseaudio-utils
from my Debian Stretch VM and I get the exact same command line as you for the sound_record subprocess... and ~5% CPU usage.
I bet there's something else that is different on your system.
comment:13 Changed 4 years ago by
I've found the difference. No CPU hog after installing gstreamer1.0-alsa. It probably should go to recommends as it is not covered by any of gstreamer1.0-plugins-* that are already there.
Changed 4 years ago by
Attachment: | info_without_gstalsa.txt added |
---|
Changed 4 years ago by
Attachment: | info_with_gstalsa.txt added |
---|
comment:14 Changed 4 years ago by
On the other hand, if a sound backend is missing, and server is able to detect that, it could set speaker default to 'off'.
comment:15 Changed 4 years ago by
On the other hand, if a sound backend is missing, and server is able to detect that, it could set speaker default to 'off'.
On Posix, we try "pulsesrc" if it is installed (we have to, because "auto" won't let us choose hardware devices), otherwise we use the "autoaudiosrc" source. We have no way of knowing what "auto" is actually going to be using as backend.
This can be overriden with --source-source=PLUGIN
, see --source-source=help
for options.
r15292 adds gstreamer1.0-pulseaudio
to recommends, since that is the best supported sound server.
I was reluctant to add gstreamer1.0-alsa
to recommends, but this adds no new dependencies of its own, so r15293 adds it too.
These changes should land in the next 1.0 update.
Can I close this ticket?
comment:16 Changed 4 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Alternative way of adding it would be:
gstreamer1.0-pulseaudio | gstreamer1.0-alsa
Closing.
comment:17 Changed 4 years ago by
Milestone: | 2.1 → 2.0 |
---|
comment:18 Changed 4 years ago by
I should have been more careful: the changes in r15292 + r15293 are causing problems with Ubuntu Precise and Debian Wheezy as those older releases do not have the required packages... So:
- r15456 makes it platform conditional for the buildbot
- r15457 bumps the release to make new builds for those 2 platforms
(only the v1.0.x branch was affected as 2.0 no longer supports these old distros)
comment:19 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1457
@psycho_zs: the only events I see between 09:17:40 and ~09:17:48 are sound packets.
How much CPU was being used? If it is only a few percent, then it is definitely audio forwarding that is causing this. Run with
--speaker=off
and turn it back on when needed via the tray menu.