xpra icon
Bug tracker and wiki

Opened 10 months ago

Closed 9 months ago

Last modified 9 months ago

#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)

all.log (1.4 MB) - added by psycho_zs 10 months ago.
sound.log (135.8 KB) - added by psycho_zs 9 months ago.
manual_sound_output.txt (403.6 KB) - added by psycho_zs 9 months ago.
info_without_gstalsa.txt (40.7 KB) - added by psycho_zs 9 months ago.
info_with_gstalsa.txt (40.7 KB) - added by psycho_zs 9 months ago.

Download all attachments as: .zip

Change History (23)

Changed 10 months ago by psycho_zs

Attachment: all.log added

comment:1 Changed 10 months ago by Antoine Martin

Owner: changed from Antoine Martin to psycho_zs

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

comment:2 Changed 10 months ago by 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.

comment:3 Changed 10 months ago by Antoine Martin

Owner: changed from psycho_zs to Antoine Martin
Status: newassigned

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 9 months ago by Antoine Martin

Milestone: 2.1
Owner: changed from Antoine Martin to psycho_zs
Status: assignednew

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 9 months ago by psycho_zs

Attachment: sound.log added

comment:5 Changed 9 months ago by psycho_zs

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

comment:6 Changed 9 months ago by 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)

comment:7 Changed 9 months ago by 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.

comment:8 Changed 9 months ago by 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 ...

comment:9 Changed 9 months ago by 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"

comment:10 Changed 9 months ago by 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.

Changed 9 months ago by psycho_zs

Attachment: manual_sound_output.txt added

comment:11 Changed 9 months ago by 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.

comment:12 Changed 9 months ago by 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.

comment:13 Changed 9 months ago by 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.

Changed 9 months ago by psycho_zs

Attachment: info_without_gstalsa.txt added

Changed 9 months ago by psycho_zs

Attachment: info_with_gstalsa.txt added

comment:14 Changed 9 months ago by 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'.

comment:15 Changed 9 months ago by 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?

Last edited 9 months ago by Antoine Martin (previous) (diff)

comment:16 Changed 9 months ago by psycho_zs

Resolution: fixed
Status: newclosed

Alternative way of adding it would be:

gstreamer1.0-pulseaudio | gstreamer1.0-alsa

Closing.

comment:17 Changed 9 months ago by Antoine Martin

Milestone: 2.12.0

comment:18 Changed 9 months ago by 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)

Note: See TracTickets for help on using tickets.