In preparation for the upcoming release of X2Go Client 4.0.2.1, a preview build of X2Go Client for Windows is available for download under: http://code.x2go.org/releases/binary-win32/x2goclient/previews/4.0.2.1/
It is based on commit 093543e (which fixed bug #522) and the default build is the same as the nightly build 2014.06.27 (except for the updated version string in add/remove programs and the filename.) There are also the miscfonts, fullfonts, and debug build available: http://code.x2go.org/releases/binary-win32/x2goclient/previews/4.0.2.1/non-d...
You can read the changelog about what has changed. I have also updated nx-libs and all the bundled cygwin components to newer versions, I will update the changelog about those updated components: http://code.x2go.org/gitweb?p=x2goclient.git;a=blob;f=debian/changelog;h=e75...
-Mike#2
Included version of PulseAudion consumes too much CPU with default settings. I've observed such behaviour on my laptop with single core CPU and WinXP SP3 x86.
It looks like pulseaudio.exe uses some polling: (stacktrace from Process Explorer) ntdll.dll!KiFastSystemCallRet USER32.dll!GetLastInputInfo+0x105 USER32.dll!MsgWaitForMultipleObjects+0x1f libpulsecommon-5.0.dll!pa_poll+0x2f7 libpulse-0.dll!pa_mainloop_poll+0x185 pulseaudio.exe+0x13de kernel32.dll!RegisterWaitForInputIdle+0x49
and frequency depends on priority of process. By default pulseaudio.exe is started with high priority (13, I don't know whether this setting is set by PA or X2Go Client) and it leads to ~100% CPU load. 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.
Am 29.06.2014 13:51, schrieb Nable 80:
Included version of PulseAudion consumes too much CPU with default settings. I've observed such behaviour on my laptop with single core CPU and WinXP SP3 x86.
[...]
and frequency depends on priority of process. By default pulseaudio.exe is started with high priority (13, I don't know whether this setting is set by PA or X2Go Client) and it leads to ~100% CPU load. 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 can only partially confirm this on Windows 7 x64 and a dual core CPU (Core2Duo). Yes, pulseaudio runs at high priority, but the cpu load caused by it remains in the single-digit range (I tried playing a youtube video).
-Stefan
Hi Nable, sorry to hear you are running into this bug.
On Jun 29, 2014 7:52 AM, "Nable 80" <nable.maininbox@googlemail.com> wrote:
Included version of PulseAudion consumes too much CPU with default
settings.
I've observed such behaviour on my laptop with single core CPU and WinXP SP3 x86.
- Does this happen on 4.0.2.0? Both versions use PulseAudio 5.0. They even use the same exact build of PulseAudio.
- On 4.0.2.0 at least, I've observed this bug on my VM with the same OS. I assumed it was a compatibility bug with the virtual hardware (fedora 20 KVM, I'll check what sound adapter model).
It looks like pulseaudio.exe uses some polling: (stacktrace from Process Explorer) ntdll.dll!KiFastSystemCallRet USER32.dll!GetLastInputInfo+0x105 USER32.dll!MsgWaitForMultipleObjects+0x1f libpulsecommon-5.0.dll!pa_poll+0x2f7 libpulse-0.dll!pa_mainloop_poll+0x185 pulseaudio.exe+0x13de kernel32.dll!RegisterWaitForInputIdle+0x49
I'm not familiar much with polling.
and frequency depends on priority of process. By default pulseaudio.exe is started with high priority (13, I don't know whether this setting is set by PA or X2Go Client) and it leads to ~100% CPU load. 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 assuming our x2goclient code sets that priority. Id probably be ok with setting it to normal priority instead. I'll probably look into this matter today or tomorrow.
Could you please report this as a bug? http://wiki.x2go.org/doku.php/wiki:bugs
Mike1#, I'd like this to block 4.0.2.1. Especially because my this bug interferes with XP users using their computer, the computer becomes very unresponsive.
-Mike#2 Windows maintainer for X2Go Client
- Does this happen on 4.0.2.0? Both versions use PulseAudio 5.0. They even use the same exact build of PulseAudio. I've downloaded http://code.x2go.org/releases/binary-win32/x2goclient/releases/4.0.2.0/x2goc... and it behaves in the same way. I'm sorry that I didn't catch this in time: it looks like I didn't update X2Go client since summer 2013.
- Could you please report this as a bug? OK, I think that I've understood the manual and now able to submit bug in a right way.
Am 29.06.2014 14:22, schrieb Michael DePaulo:
- Mike1#, I'd like this to block 4.0.2.1. Especially because my this bug interferes with XP users using their computer, the computer becomes very unresponsive.
I'd like to veto that. As Nable confirmed that 4.0.2.0 acts the same way, we're not making things worse by releasing 4.0.2.1 with that bug unfixed.
(One could also argue that either the number of XP users amongst our users is very, very low, or that it's an issue that doesn't hit every XP user and needs other contributing factors to trigger, given that Nable is the first and so far only to report CPU hogging issues with pulseaudio.)
That doesn't mean we should put the issue on the back burner, only that we can release 4.0.2.1 as planned.
-Stefan
Hi Mike#2,
On So 29 Jun 2014 14:22:52 CEST, Michael DePaulo wrote:
- Mike1#, I'd like this to block 4.0.2.1. Especially because my this bug interferes with XP users using their computer, the computer becomes very unresponsive.
Ok. Release of 4.0.2.1 blocked until this has got fixed.
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.xf...
Am 29.06.2014 16:45, schrieb Mike Gabriel:
- Mike1#, I'd like this to block 4.0.2.1. Especially because my this bug interferes with XP users using their computer, the computer becomes very unresponsive.
Ok. Release of 4.0.2.1 blocked until this has got fixed.
No, please don't. The issue has been present in 4.0.2.0 already and no one complained back then, so we're not making things worse compared to the last stable release.
See my reasoning in http://lists.x2go.org/pipermail/x2go-dev/2014-June/007589.html
Let's get 4.0.2.1 out within the next two weeks, make this bug a blocker for 4.0.2.2, if you feel it's necessary, and get a bugfix release 4.0.2.2 out soon after 4.0.2.1.
-Stefan
Hi Stefan, hi Mike#2,
On So 29 Jun 2014 17:15:24 CEST, Stefan Baur wrote:
Am 29.06.2014 16:45, schrieb Mike Gabriel:
- Mike1#, I'd like this to block 4.0.2.1. Especially because my this bug interferes with XP users using their computer, the computer becomes very unresponsive.
Ok. Release of 4.0.2.1 blocked until this has got fixed.
No, please don't. The issue has been present in 4.0.2.0 already and no one complained back then, so we're not making things worse compared to the last stable release.
See my reasoning in http://lists.x2go.org/pipermail/x2go-dev/2014-June/007589.html
Let's get 4.0.2.1 out within the next two weeks, make this bug a blocker for 4.0.2.2, if you feel it's necessary, and get a bugfix release 4.0.2.2 out soon after 4.0.2.1.
-Stefan
Reasonable way of reasoning...
Let's get X2Go Client released by the end of the week. If the issue
gets solve by then, fine. If not, then we get a 4.0.2.2 released as
soon as this is fixed.
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.xf...
On Jun 29, 2014 11:23 AM, "Mike Gabriel" <mike.gabriel@das-netzwerkteam.de> wrote:
Hi Stefan, hi Mike#2,
On So 29 Jun 2014 17:15:24 CEST, Stefan Baur wrote:
Am 29.06.2014 16:45, schrieb Mike Gabriel:
- Mike1#, I'd like this to block 4.0.2.1. Especially because my this
bug
interferes with XP users using their computer, the computer becomes very unresponsive.
Ok. Release of 4.0.2.1 blocked until this has got fixed.
No, please don't. The issue has been present in 4.0.2.0 already and no one complained back then, so we're not making things worse compared to the last stable release.
See my reasoning in http://lists.x2go.org/pipermail/x2go-dev/2014-June/007589.html
Let's get 4.0.2.1 out within the next two weeks, make this bug a blocker for 4.0.2.2, if you feel it's necessary, and get a bugfix release 4.0.2.2 out soon after 4.0.2.1.
-Stefan
Reasonable way of reasoning...
Let's get X2Go Client released by the end of the week. If the issue gets solve by then, fine. If not, then we get a 4.0.2.2 released as soon as this is fixed.
Ok, let's do that.
Am 29.06.2014 19:12, schrieb Michael DePaulo:
Let's get X2Go Client released by the end of the week. If the issue gets solve by then, fine. If not, then we get a 4.0.2.2 released as soon as this is fixed.
Ok, let's do that.
Thank you, guys.
@Mike#2: can you provide a test build (pre02 or somewhere separate) with Alex' changes from 2014-06-12 undone, so we can check if his initial change (the one that broke the nightlies) and his later patch to fix the nightlies introduced bug #525, or if that has a different cause? I'd volunteer to test that.
If it *does* fix #525, I'd suggest reverting those commits for 4.0.2.1, and making the intended reason for Alex' changes a new bug, which blocks 4.0.2.2.
That way, we'd have two goals for 4.0.2.2:
- Bug #526 as reported by Nable
- Bug #<new> to fix/add what Alex was originally trying to fix/add.
If Alex' changes aren't the cause for Bug #525, we should ship 4.0.2.1 with Alex' latest changes included and #525 unfixed.
In that case, 4.0.2.2 would be blocked by #525 and #526.
-Stefan, wearing the X2Go-Releasemeister-in-training hat ;-)
On Sun, Jun 29, 2014 at 2:00 PM, Stefan Baur <newsgroups.mail2@stefanbaur.de> wrote:
Am 29.06.2014 19:12, schrieb Michael DePaulo:
Let's get X2Go Client released by the end of the week. If the issue gets solve by then, fine. If not, then we get a 4.0.2.2 released as soon as this is fixed.
Ok, let's do that.
Thank you, guys.
@Mike#2: can you provide a test build (pre02 or somewhere separate) with Alex' changes from 2014-06-12 undone, so we can check if his initial change (the one that broke the nightlies) and his later patch to fix the nightlies introduced bug #525, or if that has a different cause? I'd volunteer to test that.
If it *does* fix #525, I'd suggest reverting those commits for 4.0.2.1, and making the intended reason for Alex' changes a new bug, which blocks 4.0.2.2.
That way, we'd have two goals for 4.0.2.2:
- Bug #526 as reported by Nable
- Bug #<new> to fix/add what Alex was originally trying to fix/add.
If Alex' changes aren't the cause for Bug #525, we should ship 4.0.2.1 with Alex' latest changes included and #525 unfixed.
In that case, 4.0.2.2 would be blocked by #525 and #526.
-Stefan, wearing the X2Go-Releasemeister-in-training hat ;-)
As mentioned in the separate email thread, 4.0.2.0-pre02 is out. It contains the fix for #526.
-
Michael DePaulo -
Mike Gabriel -
Nable 80 -
Stefan Baur