Abnormal CPU usage on server while client is connected

[psycho_zs]

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.

[Antoine Martin]

@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.

[psycho_zs]

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.

[Antoine Martin]

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.

[Antoine Martin]

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.

[psycho_zs]

Attached the log of switching speaker on, then off. Lots of "new_sound_buffer" messages

[Antoine Martin]

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)

[psycho_zs]

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.

[Antoine Martin]

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 ...

[psycho_zs]

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"

[Antoine Martin]

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.

[psycho_zs]

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.

[Antoine Martin]

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.

[psycho_zs]

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.

[psycho_zs]

On the other hand, if a sound backend is missing, and server is able to detect that, it could set speaker default to 'off'.

[Antoine Martin]

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?

[psycho_zs]

Alternative way of adding it would be:

gstreamer1.0-pulseaudio | gstreamer1.0-alsa

Closing.

[Antoine Martin]

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)