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.
@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.
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.
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.
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.
Attached the log of switching speaker on, then off. Lots of "new_sound_buffer" messages
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)
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.
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 ...
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"
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.
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.
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.
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.
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 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?
Alternative way of adding it would be:
gstreamer1.0-pulseaudio | gstreamer1.0-alsa
Closing.
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:
(only the v1.0.x branch was affected as 2.0 no longer supports these old distros)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1457