X2Go Bug report logs - #537
Included PulseAudio consumes too much CPU when launched with high priority

Toggle useless messages

Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

From: Nable 80 <nable.maininbox@googlemail.com>

To: submit@bugs.x2go.org

Subject: Included PulseAudio consumes too much CPU when launched with high priority

Date: Sun, 29 Jun 2014 18:04:42 +0400

Package: x2goclient
Version: 4.0.2.0

When I use sound forwarding and launch inside X2Go session some application
with sound support, pulseaudio.exe at client side starts consuming ~100% CPU.
By default, X2Go Client starts pulseaudio.exe with high priority (13).
When I set priority to "Above Normal (10)" PA's CPU load drops to 10-20%.
With "Normal (8)" it drops to almost 0%, although sound is still played stable,
without any additional delays.

I'm using WinXP SP3 (32-bit) on my laptop with single core CPU.
This issue seems to be "PulseAudio 5.0 && WinXP"-specific.

Message #10 received at 526@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: Nable 80 <nable.maininbox@googlemail.com>, 526@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#526: Included PulseAudio consumes too much CPU when launched with high priority

Date: Sun, 29 Jun 2014 15:03:17 +0000

[Message part 1 (text/plain, inline)]

Control: tag -1 build-win32

Hi Nable,

On  So 29 Jun 2014 16:04:42 CEST, Nable 80 wrote:

> Package: x2goclient
> Version: 4.0.2.0
>
> When I use sound forwarding and launch inside X2Go session some application
> with sound support, pulseaudio.exe at client side starts consuming ~100% CPU.
> By default, X2Go Client starts pulseaudio.exe with high priority (13).
> When I set priority to "Above Normal (10)" PA's CPU load drops to 10-20%.
> With "Normal (8)" it drops to almost 0%, although sound is still  
> played stable,
> without any additional delays.
>
> I'm using WinXP SP3 (32-bit) on my laptop with single core CPU.
> This issue seems to be "PulseAudio 5.0 && WinXP"-specific.

thanks for handing this one in.

Our PA expert will take a look at that (I hope!).

Mike
-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #17 received at 526@bugs.x2go.org (full text, mbox, reply):

From: Nable 80 <nable.maininbox@googlemail.com>

To: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

Cc: 526@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#526: Included PulseAudio consumes too much CPU when launched with high priority

Date: Sun, 29 Jun 2014 19:47:44 +0400

[Message part 1 (text/plain, inline)]

Hi Mike!

> Our PA expert will take a look at that (I hope!).
I've attached possible workaround, although I'm not sure if it's acceptable.

[pa-disable-high-priority.diff (text/plain, attachment)]

Message #22 received at 526@bugs.x2go.org (full text, mbox, reply):

From: Michael DePaulo <mikedep333@gmail.com>

To: Nable 80 <nable.maininbox@googlemail.com>, 526@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#526: Bug#526: Included PulseAudio consumes too much CPU when launched with high priority

Date: Mon, 30 Jun 2014 10:11:03 -0400

[Message part 1 (text/plain, inline)]

Hi Nable,

1. thank you for the patch. Command line testing shows that it does
lower the priority for PulseAudio 5.0 on Windows to "normal".
PulseAudio 1.1 ignores the argument and remains at "high" priority,
even though --help states that it recognizes the argument. 0.9.6
defaults to normal priority anyway. None of them refuse to start when
the argument is passed though.

2. I will incorporate your patch (it's only 1 line after all,) but
after talking with the PulseAudio developers, I will extend it so that
"normal" priority will only be set on Windows XP and Server 2003 /
Server 2003 R2. On Windows Vista / server 2008 and later, we will
continue to default to "high" priority.
(You are welcome to extend the patch to do this, or I will do extend
it later today or tomorrow.)

3. Right now I cannot test the patch with x2goclient because the
WIndows build VM has a networking problem. Mike#1 will fix that
problem sometime this week.

4. My testing reveals the following:
a. I am able to reproduce this bug. See setup #2 below.
b. I encountered a different bug with the virtual hardware (setup #1),
which is fixed by switching to a different sound driver (setup #2). I
will clone this bug report for my setup #1 bug.
c. This bug does not result in high CPU usage until audio is playing,
unlike my bug.
d. Manually  lowering the priority in task manager does appear to be a
valid workaround.

5. All my test details:

setup #1:
Note: default sound driver. I think I have a driverpacks.net driver
pack installed though, so it may not be the default driver for XP
without said driver pack.
Host & Hypervisor: Fedora 20 w/ KVM/virt-manager
VM accessed via: VirtViewer 0.6.0 64-bit for Windows w/ the SPICE protocol
Guest OS: Windows XP SP3 32-bit
vCPUs : 2 (host has 4 cores, core i5 750)
Sound setting in virt-manager: ac97
Sound adapter according to Windows: Intel(r) AC'97 Audio Controller -
SIgmaTel Codec
Driver Provider: SigmaTel
Driver Date: 12/20/2001
Driver Version: 5.10.0.7159

Results with: PulseaAudio 5.0, PulseAudio 1.1, and PulseAudio 0.9.6
launched from the command-line:
The combined CPU usage of pulseaudio.exe + "System" is very high, even
at normal priority, and the VM is extremely slow overall. This occurs
before any sound as playing. In other words, as the process is
started, the CPU usage immediately goes up and the VM immediately
becomes extremely slow. The combined CPU usage is always greater than
or equal to 1 CPU core.See #1 for notes on the behavior of the
priority. And yes, "System" CPU usage is normally 0% or just above 0%,
when pulseaudio.exe is not running.
The attached logs are from said results.

Results with x2goclient 4.0.2.0 (PulseAudio 5.0):
X2Go client GUI is extremely slow for same reason as on the
command-line. Cannot test any further.


setup #2
Note: same as before, except for a different sound driver:
Host & Hypervisor: Fedora 20 w/ KVM/virt-manager
VM accessed via: VirtViewer 0.6.0 64-bit for Windows w/ the SPICE protocol
Guest OS: Windows XP SP3 32-bit
vCPUs : 2 (host has 4 cores, core i5 750)
Sound setting in virt-manager: ac97
Sound adapter according to Windows: Intel(r) 82801AA AC'97 Audio Controller
Driver Provider: Microsoft
Driver Date: 7/1/2001
Driver Version: 5.1.2535.0

Results with: PulseaAudio 5.0, PulseAudio 1.1, and PulseAudio 0.9.6
launched from the command-line:
Whether I have normal priority or high priority, there is no high CPU
usage for either process, and no VM slowdown.

Results with x2goclient 4.0.2.0 (PulseAudio 5.0):
I reproduced this bug reported by Nable. I also observed that lowering
PulseAudio to normal fixes the problem. Only 1 vCPU was maxed out for
me (Nable had single core.) Also, unlike my problem with setup #1, the
VM is not extremely slow. Also, unlike my problem setup #1, CPU usage
is not high until audio is playing. Also, unlike my problem on
setup#1, "System's usage is 0% or a few % like normal.  There seems to
be a 1 second delay in audio, but that may be due to me accessing the
VM over Virt-Viewer. Also, the delay occurs at high priority.

-Mike#2

On Sun, Jun 29, 2014 at 11:47 AM, Nable 80
<nable.maininbox@googlemail.com> wrote:
> Hi Mike!
>
>> Our PA expert will take a look at that (I hope!).
> I've attached possible workaround, although I'm not sure if it's acceptable.
>
> _______________________________________________
> x2go-dev mailing list
> x2go-dev@lists.x2go.org
> http://lists.x2go.org/listinfo/x2go-dev

[pulse-0.9.6-on-xp-normal-priority-defaulted-log.txt (text/plain, attachment)]

[config.test.pa (application/octet-stream, attachment)]

[pulse-1.1-on-xp-normal-priority-ignored-log.txt (text/plain, attachment)]

[pulse-5.0-on-xp-normal-priority-log.txt (text/plain, attachment)]

Message #29 received at 526@bugs.x2go.org (full text, mbox, reply):

From: Michael DePaulo <mikedep333@gmail.com>

To: 526@bugs.x2go.org

Subject: Submitted as PulseAudio bug 80772

Date: Tue, 1 Jul 2014 17:30:03 -0400

Bug 80772 - Windows XP: PulseAudio consumes too much CPU when launched
with high priority

https://bugs.freedesktop.org/show_bug.cgi?id=80772

Message #44 received at 537@bugs.x2go.org (full text, mbox, reply):

From: Mike DePaulo <mikedep333@gmail.com>

To: 537-submitter@bugs.x2go.org

Cc: control@bugs.x2go.org, 537@bugs.x2go.org

Subject: X2Go issue (in src:python-x2go) has been marked as pending for release

Date: Tue, 8 Jul 2014 01:00:57 +0200 (CEST)

tag #537 pending
fixed #537 0.5.0.0
thanks

Hello,

X2Go issue #537 (src:python-x2go) reported by you has been
fixed in X2Go Git. You can see the changelog below, and you can
check the diff of the fix at:

    http://code.x2go.org/gitweb?p=python-x2go.git;a=commitdiff;h=837a73c

The issue will most likely be fixed in src:python-x2go (0.5.0.0).

light+love
X2Go Git Admin (on behalf of the sender of this mail)

---
commit 837a73ceb4ce9ba1774760087a976832a775575f
Author: Mike DePaulo <mikedep333@gmail.com>
Date:   Mon Jul 7 19:00:44 2014 -0400

    Windows: On XP & Server 2003 (R2), prevent high PulseAudio CPU usage by lowering its CPU priority to "normal" (Fixes: #537)

diff --git a/debian/changelog b/debian/changelog
index f685ff6..bfb39f1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -84,6 +84,9 @@ python-x2go (0.5.0.0-0x2go1) UNRELEASED; urgency=low
   [ Mike DePaulo ]
   * New upstream version (0.5.0.0):
     - Windows: Fix compatibility with PulseAudio 3.0 & later (Fixes: #532)
+    - Windows: Prevent high PulseAudio CPU usage on Windows XP by lowering
+      PulseAudio's CPU priority from "high" to "normal" on XP specifically.
+      Also do so on Windows Server 2003 (R2) (Fixes: #537)
 
  -- Mike Gabriel <mike.gabriel@das-netzwerkteam.de>  Sun, 05 Jan 2014 16:35:57 +0100
 

Message #56 received at 537@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: 537-submitter@bugs.x2go.org

Cc: control@bugs.x2go.org, 537@bugs.x2go.org

Subject: X2Go issue (in src:python-x2go) has been marked as closed

Date: Mon, 20 Oct 2014 12:50:23 +0200 (CEST)

close #537
thanks

Hello,

we are very hopeful that X2Go issue #537 reported by you
has been resolved in the new release (0.5.0.0) of the
X2Go source project »src:python-x2go«.

You can view the complete changelog entry of src:python-x2go (0.5.0.0)
below, and you can use the following link to view all the code changes
between this and the last release of src:python-x2go.

    http://code.x2go.org/gitweb?p=python-x2go.git;a=commitdiff;h=3fec411b839b53c0e51a73dd05c7a77dcde800e8;hp=3088eda9bf1494527afecc4b36c56a8caff314d0

If you feel that the issue has not been resolved satisfyingly, feel
free to reopen this bug report or submit a follow-up report with
further observations described based on the new released version
of src:python-x2go.

Thanks a lot for contributing to X2Go!!!

light+love
X2Go Git Admin (on behalf of the sender of this mail)

---
X2Go Component: src:python-x2go
Version: 0.5.0.0-0x2go1
Status: RELEASE
Date: Mon, 20 Oct 2014 12:40:34 +0200
Fixes: 334 358 500 508 532 537 588 602
Changes: 
 python-x2go (0.5.0.0-0x2go1) RELEASED; urgency=low
 .
   [ Mike Gabriel ]
   * New upstream version (0.5.0.0):
     - Split up session profile backend into generic and storage specific
       parts.
     - Fully rework backend concept in Python X2Go. Breaks compatibility
       with earlier versions of Python X2Go concerning backends (probably
       not really used by third-party products, if at all).
     - Fix setting default values in X2GoClientXConfig class.
     - Default to xdg-open as default PDF viewer command.
     - Provide session profile backend for a http broker.
     - Make session profile backends more unicode robust.
     - X2GoSessionProfile.get_server_hostname must return unicode objects.
     - Speed-optimize session profile ID <-> name mapping.
     - Handle injection of PKey (Paramiko SSH key) objects for authentication
       from the broker session profiles backend.
     - Allow catching "connection refused" errors while talking to an X2Go
       Session Broker (X2GoBrokerConnectionException).
     - Support cookie based authentication against a http(s) session broker.
     - On Windows: Improve debugging when a new X-Server port has to be
       allocated.
     - Capture broker connection problems during selectsession calls to the
       broker via a HOOK method.
     - Allow user interaction via a HOOK if broker connection problems occur.
     - Handle broker setups that don't require credentials. Connection can
       be established simply by leaving the password (and authid) empty.
     - Fix detection of matching path names in X2GoIniFiles.
     - Make sure X2GoClientXConfig config file really gets written to disk
       (after we changed the internas of X2GoIniFile for this new major release).
     - Rename hook method HOOK_no_known_xserver_found to
       HOOK_no_installed_xservers_found. Call this new hook if no installed
       X-Servers could be found on the system.
     - Only check running X-Servers that have the same WMI SessionId as the
       current X2Go application.
     - Session profiles: default value type for exports session profile option
       is an empty dictionary.
     - Make X2GoClient's constructor aware of non-usable X-Server ports.
     - Windows: Fix crash while attempting to find the session window.
     - Support SSH proxy autologin feature of X2Go Session Broker.
     - Provide Telekinesis support in Python X2Go.
     - Stop manipulating session profiles in X2GoSshProxy class. Esp. stop
       manipulating session profiles with deprecated session options.
     - Type-hardening of X2GoSshProxy class. Accept hosts as list and strings.
       If hosts are given as a list, a random list element will be taken as
       host (for connecting and for the SSH proxy tunnel setup).
     - Type-hardening of X2GoControlSession class's C{connect()} method.
       Handle hostnames that come in as lists gracefully.
     - Don't construct the sshproxy_tunnel parameter in x2go/utils.py. Leave
       that to higher level classes that know more about X2Go internals.
     - Add support for a subsystem string when setting up port forwarding
       tunnels.
     - Use gevent to spawn the TeKi client start-up process (instead of waiting
       for it to return).
     - Provide support for new session parameter: clipboard. (Fixes: #508).
     - Split up NX output and NX errors into two separate files.
     - Silent ignore it if we cannot detect the local Xlib.display.Display()
       instance (happens with polyinstantiated /tmp dirs).
     - Don't start telekinesis client if not support server-side. Don't attempt
       at starting telekinesis client, if it is not installed.
     - Disallow server-side users to override X2Go Server commands via
       ~/bin (or similar). (Fixes: #334).
     - Handle non-available color depth in X2Go session name gracefully.
       (Fixes: #358).
     - Make sure that the x2gosuspend-session/x2goterminate-session commands
       are sent to the X2Go Server before we take down the NX proxy subprocess.
     - Create a "session.window" file in the session directory. This file for now
       contains one line "ID:<window-id>". The file appears once a session window
       comes up (start/resume), and disappears once the session window closes
       (suspend/terminate).
     - Only enable Telekinesis client debugging if the logger instance is in
       debug mode.
     - Performance tests have shown, that enabling SSH compression is not a
       good idea. NX should handle that instead (and does).
     - Better control the startup bootstrap of the Telekinesis client
       subsystem.
     - Newly understand our own Paramiko/SSH forwarding tunnel code. Become
       aware of handling multiple connects on the same tunnel.
     - Rename LICENSE.txt to COPYING.
     - Be more exact when detecting the NX proxy window id.
     - On non-Windows platforms, enforce usage of the "ares" DNS resolver in
       python-gevent (which is available since Python gevent 1.0~). (Fixes:
       #588).
     - Use Xlib to detect client-side destop geometry.
     - For reverse port forwardings use IPv4 localhost address only.
     - Assure proper NX Proxy cleanup when sessions suspends/
       terminates.
     - Assure proper Telekinesis client cleanup when sessions suspends/
       terminates.
     - Clean up terminal sessions properly when the clean_sessions() method
       of the control session has got called.
     - Don't use compression on  TeKi sshfs mounts.
     - Handle duplicate profile names gracefully (i.e. append a " (1)",
       " (2)", ... to the session profile name). (Fixes: #500).
     - Support server-side Telekinesis versions that ship their own
       (teki-)sftpserver.
     - Use session_name, not session_info object's __str__() method to obtain
       session name (in X2GoTelekinesis).
     - Handle socket errors on the reverse port forwarding tunnels more
       gracefully.
     - Handle sudden control session death during local folder sharing
       gracefully.
     - Don't choke on non-initialized SSH transport objects when initializing
       SFTP client.
     - Fix transport lock release in X2GoControlSession._x2go_sftp_put().
     - Fix session lock release in various methods of the X2GoSession class.
     - Release _share_local_folder_lock on instance X2GoTerminalSession
       destruction.
     - Detect non-installed sshfs (required for Telekinesis).
     - X2GoControlSession: Don't mess with the associated_terminals dict if
       the control session has already died away (i.e. been forcefully
       disconnect).
     - If the listsessions command detects a terminated or suspended session,
       we have to destroy the corresponding X2GoTerminalSession() to trigger
       a proper cleanup of that instance.
     - Fix various hrefs in __doc__ strings.
     - Fix creating/renaming/reconfiguring session profiles. Handle host
       option properly (as list).
     - Make sure we do a deepcopy of the default session profile parameters.
     - Detect more exceptions in the requests module when authenticating against a
       session broker.
     - Only convert the value of the export session profile option if not
       already a Python dictionary.
     - Capture X2GoControlSessionException occurrences during client-side folder
       sharing initializaation while starting/resuming a session.
     - X2GoSessionRegistry: Don't report about sessions that have a not yet
       fully assigned session name / profile name / profile id.
   * debian/control:
     + Add dependencies: python-requests, python-simplejson.
     + Add R (python-x2go): sshfs.
     + Add S (python-x2go): telekinesis-client, mteleplayer-clientside.
     + Update D (python-x2go): python-paramiko (>= 1.15.1-0~). (Fixes: #602).
   * python-x2go.spec:
     + Add dependencies: python-requests, python-simplejson.
     + Additionally adapt to building on openSUSE/SLES.
     + Add all python packages under R to BR (for epydoc run).
     + Update R for python-x2go: python-paramiko >= 1.15.1.
 .
   [ Mike DePaulo ]
   * New upstream version (0.5.0.0):
     - Windows: Fix compatibility with PulseAudio 3.0 & later (Fixes: #532)
     - Windows: Prevent high PulseAudio CPU usage on Windows XP by lowering
       PulseAudio's CPU priority from "high" to "normal" on XP specifically.
       Also do so on Windows Server 2003 (R2) (Fixes: #537)

Send a report that this bug log contains spam.