tuxpaint and other tux SDL driven apps slow down and/or freeze thin client terminals (ltsp)

I'm going to send this to the tux4kids mailing lists for comments. We will need more information but I'm not sure what.

Have you tried SDL applications that aren't from tux4kids?

First questions from upstream -

Which version of tuxpaint and ltsp is this? Which version of Ubuntu? Hardy or..?

What specs for the PCs in the network? Are you on a 100M network or 10M?

new ->incomplete

Ubuntu 8.04.2

latest tuxpaint and tux suite apps... but it happens on all of them
since at least a year...

gigabit network... its definitely not the network... as even google
earth and video streaming work fine without bringing as many computers
down.
We see the slow down on our dual xeon processor server with 16 gigs of
ram with only 10-15 users starting up the tux suite. Its the most
dramatic slow down and freeze of any software on the thin client
systems, and we're trying to figure out why.

here is a related bug post:
http://osdir.com/ml/linux.ubuntu.user.edubuntu/2007-12/msg00182.html

I can test some other non tux4kids SDL stuff if you like, but I know
gcompris and childsplay work much better... Over the next couple days
I'll try running a bunch of other SDL stuff and see how it fares
compared to tux4kids stuff...

anyway here are the version numbers:
tuxpaint: 1:0.9.17-1ubuntu3
tuxmath: 1.5.8-2
tuxtyping: 1.5.15.dfsg1-3ubuntu1

If you need anything else, let me know

Kind Regards,
David Van Assche

On Fri, Sep 12, 2008 at 7:36 PM, Caroline Ford
<email address hidden> wrote:
> First questions from upstream -
>
> Which version of tuxpaint and ltsp is this? Which version of Ubuntu?
> Hardy or..?
>
> What specs for the PCs in the network? Are you on a 100M network or
> 10M?
>
> --
> tuxpaint and other tux SDL driven apps slow down and/or freeze thin client terminals (ltsp)
> https://bugs.launchpad.net/bugs/269082
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Ubuntu 8.04.1 Desktop (i386)
100MBit network/Thin-clients, 1GB link to LTSP server

All thin-clients were at least PII 500MHz w/256MB RAM (older Compaq iPaqs)

Latest version of Tuxpaint:

---
jerickson@Fibonacci:~$ apt-cache show tuxpaint
Package: tuxpaint
Priority: optional
Section: graphics
Installed-Size: 388
Maintainer: Ubuntu Core Developers <email address hidden>
Original-Maintainer: Ben Armstrong <email address hidden>
Architecture: i386
Version: 1:0.9.17-1ubuntu3
---

This has been an issue since Gutsy (7.10). I recall talking with one of
the developers a long time ago, he seemed to see something pretty basic
as to at least speed things up a *bit* that had to do with SDL
refreshing or something (it's been a LONG time so forgive me if I'm wrong).

HTH,
Jordan

Caroline Ford wrote:
> First questions from upstream -
>
> Which version of tuxpaint and ltsp is this? Which version of Ubuntu?
> Hardy or..?
>
> What specs for the PCs in the network? Are you on a 100M network or
> 10M?
>
>

Has there been any progress on this.

I have the same problem.
Set up a ltps server running Ubunti 8.04.1 (With the Edubuntu add-ons) on a dual xeon 2.5GHz server.
When I boot up just 1 thin client (IBM Netvista 300MHz w/128MB RAM) I can run everything else acceptable Firefox / open office / etc.. but when I launch TuxMath it grinds to a halt and uses 100% of one processor on the server. We have a dedicated 100Mb network.

Thanks,
Eric
<email address hidden>

.

Caroline Ford, we have all given you answers to your question (which I'm assuming is why we have an incomplete status on this bug) - can we move forward with this now that you have sufficient information?

Yes - has there been any progress on this?
I am a software developer and would be willing to donate a little time to help fix this if someone would point me in the right direction.

Setting to high considering that ltsp is a very common configuration for Edubuntu.

Made a bug upstream. Launchpad doesn't seem to be able to cope with new sourceforge tracker URLs.

https://sourceforge.net/tracker2/?func=detail&aid=2161843&group_id=66938&atid=516295

Has anyone managed to test this on other SDL non-tux4kids applications?

http://osdir.com/ml/linux.ubuntu.user.edubuntu/2007-12/msg00182.html says that there may be a sound connection. Are people running with sound on or off, and does it make a difference.

http://myt.ag/URLWeb.aspx?email=steve%40fooworks.com&url=https%3a%2f%2flists.ubuntu.com%2farchives%2fedubuntu-users%2f2007-December%2fthread.html%233025&sn=

http://myt.ag/URLWeb.aspx?email=steve%40fooworks.com&url=https%3a%2f%2flists.ubuntu.com%2farchives%2fedubuntu-users%2f2007-August%2fthread.html%231777&sn=

These reports go back to feisty, and yet no-one actually filed a bug so we didn't know.

Yeah, its an old problem that has affected LTSP since its inception on
ubuntu, and is most likely related to SDL. As far as I can tell, it
doesn't matter if Sound is on or off, it still brings down the network
with 10 clients running it. There are also constant complaints of the
exit screens hanging. I have not had a chance to compare it to other
SDL driven programs, but I will run a few tests at a school....

Kind Regards,
David Van Assche

On Sun, Oct 12, 2008 at 7:45 PM, Caroline Ford
<email address hidden> wrote:
> http://osdir.com/ml/linux.ubuntu.user.edubuntu/2007-12/msg00182.html
> says that there may be a sound connection. Are people running with sound
> on or off, and does it make a difference.
>
> http://myt.ag/URLWeb.aspx?email=steve%40fooworks.com&url=https%3a%2f%2flists.ubuntu.com%2farchives
> %2fedubuntu-users%2f2007-December%2fthread.html%233025&sn=
>
> http://myt.ag/URLWeb.aspx?email=steve%40fooworks.com&url=https%3a%2f%2flists.ubuntu.com%2farchives
> %2fedubuntu-users%2f2007-August%2fthread.html%231777&sn=
>
> These reports go back to feisty, and yet no-one actually filed a bug so
> we didn't know.
>
> --
> tuxpaint and other tux SDL driven apps slow down and/or freeze thin client terminals (ltsp)
> https://bugs.launchpad.net/bugs/269082
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Hi,

I'm the maintainer for Tuxmath and Tuxtype. Below is what I sent out yesterday to our dev list:

"This is puzzling as the three programs don't really share much code
(the menu stuff from Tuxtype was adapted for Tuxmath, and the Comet
Zap activity in Tuxtype is an adapted version of Tuxmath, but that's
about it). I hate to just say "it must be SDL", but it seems weird
that three independently-coded programs would all create the same bug.

From reading the posts on the launchpad forum, it sounds like Tuxmath
is using all the cpu cycles on the server when run from a thin client.
 It certainly doesn't do this when run on a single machine - a quick
check with top on my desktop machine (amd64 dual 3800, 2 gig RAM)
shows that neither tuxmath itself nor Xorg exceeds about 3% cpu. Of
course it would use more on less powerful hardware, but I would expect
a typical server machine to be able to run quite a few instances of
tuxmath. I started up 10 instances just now on my desktop with no
discernable effect on system performance.

So, I don't have any immediate ideas. It might be helpful to know at
what point in the program the resources all get eaten up (menus vs.
game itself). Also, if the problem is 100% cpu utilization, it could
be very informative to profile tuxmath with valgrind to see where all
of the cycles are going. Tim is our resident valgrind expert and he
might know how to do this."

So, I think someone with a running network needs to get some more specific info about what is happening to bog the system down (cpu utilization vs. network saturation, where in the programs the problem is seen, etc) and ideally do some actual profiling. The programs do not tax the machine much at all when run locally, even on old, slow computers, so I suspect that something is happening in either SDL or Xorg functions related to the remote X session that is slowing the server down.

David Bruce

I can only speak to tuxmath right now, and the interesting thing is that it does not seem so bad under a openSUSE ltsp server setup.
I have tried to make it lock up and failed. The cpu cycles on the server stay relatively low (< 10%) when running.

I cannot try on my ubuntu server anymore because it self destructed yesterday (funny smell then beeping motherboard - unfortunately it was a nice Athlon64X2 3800 that someone jsut donated - soo I'll have to fix it!)

My server is a pentium 4 HT 3.2GHz

Client is either a 1.4GHz - core 2 duo - reasonbly modern and fast
and
an IBM NetVista 2800 8364 Thin Client PII 266 MHz 128MB

and both seem to perform fine (although the game speed on the netvista is slow even if I set --speed , but that is another issue)

I am off to Germany for 2 weeks but when I get back I will see if I can get some Valgrind dumps etc...

but yes on my ubunut server it would hog all processors 100% and refuse to shutdown on the client. Then I woudl sometimes kill it and it would no longer appear in "ps -A" but the server would still be showing 100% cpu utilization.

-Eric

I just installed Tuxpaint on my own LTSP server and launched with my thin-client (a LTSP-Term 1220PXE available from disklessworkstations.com and 100% supported by LTSP ) and will attach the following strace. The strace contains data from me simply starting Tuxpaint, drawing an "X" on the blank slate, adding 4 "Stamps" (2 of one Tux face and 2 of another), and then attempting to exit. When I exit, it asks me if I'm done, and I clicked Yes. It asked me if I wanted to save, and I said No. From there, the program locked up and I had to 'killall -9 tuxpaint' to close it. Normal 'killall tuxpaint' wouldn't work.

Note that on my single LTSP thin-client, starting Tuxpaint took 55% of the CPU time, which is:

----
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping : 2
cpu MHz : 2210.121
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc
bogomips : 4423.66
clflush size : 64

processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping : 2
cpu MHz : 2210.121
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc
bogomips : 4420.14
clflush size : 64
----

I hope this information helps. I have a 7 schools ready to use Tuxpaint for the younger students, but this is preventing us from doing so in our LTSP environment. Please ask if there's any more troubleshooting I can do.

In response to an earlier comment, I can confirm that using the --nosound switch with tuxpaint corrects the issue with high CPU usage and failure to exit cleanly.

Let's have some other people test this by running tuxpaint from a terminal with the following command:

---
tuxpaint --nosound
---

If this proves to help other LTSP users, maybe we can have some code to detect whether tuxpaint is being run from a thin-client terminal or not, and either disable sound accordingly, or fix the actual issue so sound can be used correctly.

Cheers,
Jordan

I can also confirm using --nosound on tuxmath & tuxtype corrects the issue with high CPU usage and failure to exit cleanly.

Thanks very much for this. I'll send this information to the three
upstream projects once I have a second.

On Wed, Nov 05, 2008 at 10:28:18PM -0000, Jordan Erickson wrote:
> In response to an earlier comment, I can confirm that using the
> --nosound switch with tuxpaint corrects the issue with high CPU usage
> and failure to exit cleanly.
>
> Let's have some other people test this by running tuxpaint from a
> terminal with the following command:

Does sound actually work (i.e., do you hear anything) in Tux Paint over
LTSP when "--nosound" is not being used? If so, there could be a crash
happening when it cannot find a sound device. (We've noticed an issue with
SDL recently regarding crashes and missing sound devices.)

So any other SDL based apps exhibit similar behavior (high CPU usage,
crash on exit) when run over LTSP? Does asking them to not use sound
help them, too?

Thanks much,

--
-bill!
"Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux!
Download it today! http://www.tuxpaint.org/

Thank you so much. I've forwarded your comments to the email addresses
of the developers.

On Wed, Nov 05, 2008 at 10:39:14PM -0000, Jordan Erickson wrote:
> I can also confirm using --nosound on tuxmath & tuxtype corrects the
> issue with high CPU usage and failure to exit cleanly.

Can you try out one of the SDL demos that comes with SDL source, or
perhaps another game (most of mine listed at
http://www.newbreedsoftware.com/linux/ use SDL and are widely packaged,
e.g., 'Defendguin' or 'Circus Linux!'). Of course, best to try something
I wasn't involved in, to make sure it's not something _I_ am in a habit
of doing that's causing this.

If other SDL apps are exhibiting the same problems, we should move this to an
SDL bug. At that point, it may end up being a Linux sound driver bug,
or not, but we should try and figure out if it's an app-level issue or not.
(It's looking like: not :^) )

Thanks again,

--
-bill!
"Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux!
Download it today! http://www.tuxpaint.org/

Bill, thanks for such a quick response!

I tried both defendguin and circuslinux - both of them exibit the same behavior of unclean exit and high CPU usage, and disabling sound with their respective switches eliminates this issue in, at least, my own LTSP network running from my single thin-client.

I am confident this issue is coming to a conclusion, and that it affects a wide range of SDL applications in Linux.

- Jordan/Lns

Does setting SDL_AUDIODRIVER change the behaviour of these programs?

Try some of the following:

$ SDL_AUDIODRIVER='pulse' tuxpaint
$ SDL_AUDIODRIVER='alsa' tuxpaint
$ SDL_AUDIODRIVER='esd' tuxpaint

Jeremy,

SDL_AUDIODRIVER='pulse' tuxpaint - fixes the issues experienced.
SDL_AUDIODRIVER='alsa' tuxpaint - does not fix the issues.
SDL_AUDIODRIVER='esd' tuxpaint - fixes the issues.

I'm not an expert in how Pulse Audio routes/emulates other sound daemons in LTSP, but I can say that I have the default Ubuntu LTSP setup which uses PA.

Cheers,
Jordan/Lns

In case sdl checks for a local device this indeed would explain the probem ... LTSP starts a pulse daemon on the client and usually has the esd as well as the native pulse plugins installed server side.
On login PULSE_SERVER as well as ESPEAKER (pointing to the client) get set in the session on the server and asoundrc creates a virtual pulseaudio device, so all sound output gets forwarded to the pulse daemon running on the client, be it esd, alsa or pulse sound.
If the app tries to attach to the local device on the server but is told to actually forward all sound traffic on a higher level via the network there is indeed a discrepancy, since the found sound device is definately not the actual output device no matter which of the drivers you use.

On Thu, Nov 06, 2008 at 12:38:44AM -0000, Jordan Erickson wrote:
> SDL_AUDIODRIVER='pulse' tuxpaint - fixes the issues experienced.
> SDL_AUDIODRIVER='alsa' tuxpaint - does not fix the issues.
> SDL_AUDIODRIVER='esd' tuxpaint - fixes the issues.

Out of curiosity, in which case(s) does sound actually play on the thin client?

--
-bill!
"Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux!
Download it today! http://www.tuxpaint.org/

In this case, the bug should be called "SDL applications do not use PulseAudio on LTSP", because if I understand correctly, PulseAudio is the only way of getting sound to LTSP clients.

IMO, this should be a global Ubuntu default, not just Edubuntu, as users are likely to experience problems (like I have many times) in this area.

An SDL patch was applied to Intrepid in #216397 which greatly improves SDL's compatibility with PulseAudio. Setting the 'pulse' audio driver as SDL's default should definitely be done.

> Out of curiosity, in which case(s) does sound actually play on the thin
> client?
>

None of the cases, actually.

Tim Holy (<email address hidden>) sent me a private e-mail for some reason, but gave me this URL regarding SDL/Alsa/Pulse bugs:

---
Hi Jordan,

Sadly I'm not an expert in audio, but I'm happy to help where I can. Are you, or do you know, the maintainer for the SDL-audio in Ubuntu?

Have you seen this thread?
http://www.nabble.com/ALSA-output-doesn't-set-buffer-size-(likely-fix-for-pulse-problems)-td21457593.html
It sounds like it might be a partial fix for some configurations?
---

Maybe this info will help..?

Pulse had changed in Jaunty so we should check it there.

Sent from a mobile device.

On 16 Feb 2009, at 18:10, Jordan Erickson <<email address hidden>
 > wrote:

> Tim Holy (<email address hidden>) sent me a private e-mail for some
> reason,
> but gave me this URL regarding SDL/Alsa/Pulse bugs:
>
> ---
> Hi Jordan,
>
> Sadly I'm not an expert in audio, but I'm happy to help where I can.
> Are
> you, or do you know, the maintainer for the SDL-audio in Ubuntu?
>
> Have you seen this thread?
> http://www.nabble.com/ALSA-output-doesn't-set-buffer-size-(likely-fix-for-pulse-problems)-td21457593.html
> It sounds like it might be a partial fix for some configurations?
> ---
>
> Maybe this info will help..?
>
> --
> tuxpaint and other tux SDL driven apps slow down and/or freeze thin
> client terminals (ltsp)
> https://bugs.launchpad.net/bugs/269082
> You received this bug notification because you are a member of
> Edubuntu
> Bugsquad, which is subscribed to tuxpaint in ubuntu.

I was at a school today on a fully updated (w/ -updates and -backports, chroot included) 8.04 server. Installed tuxtype/math/paint and they *all* crash upon exit. The --nosound option still works but we need sound as it's important to the experience for kids.

I did an strace on all of these apps - This is the process I used for all apps (excluding tuxpaint which I simply drew random lines and added a stamp):

$ strace tux(paint/math/type) > strace-(paint/math/type).txt 2&>1

Attached is the resulting strace text files for troubleshooting. I hope they are of use.

Looked at the debbugs report and there was never a fix released due to nobody actually knowing if the bug was present in Debian - I changed the status, hope "Incomplete" is a sane replacement.

@Caroline re: #32: Here are two replies I got from people running Jaunty LTSP setups:

---
Tuxmath and tuxtyping both started, with sound and everything working,
and when I exited, it worked fine, no problems, no lockup.

Of course only one user here.

Hope that helps,

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.04
DISTRIB_CODENAME=jaunty
DISTRIB_DESCRIPTION="Ubuntu 9.04"

ace
---
I had the same experience with the same setup. TuxType and TuxMath
both work as expected with no lockup on Jaunty.

Patrick McKnight
---

HTH!

On Tue, Jul 28, 2009 at 04:04:05PM -0700, Bill Kendrick wrote:
> > On Tue, Jul 28, 2009 at 03:35:15PM -0700, Jordan Erickson wrote:
>> > > https://bugs.launchpad.net/ubuntu/+source/tuxpaint/+bug/269082 - check
>> > > out my latest comments.

Googling around furiously...

  urbanterror crash with pulseaudio
  https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/224399

    "the game crashed completly on exit, no sound and the cpu is on
    100 percent the hole time. When i change my ubuntu settings back
    to alsa everything works fine."

  Re: [HOWTO] SDL sound (read: ALSA) support for Enemy Territory
  http://ubuntuforums.org/showthread.php?t=362231&page=14

    "You need to have the corresponding libSDL package installed. If
    you have libsdl-alsa, SDL apps will use ALSA output (but ALSA support
    is broken when using PulseAudio as sound system). To use ESD or
    PulseAudio in SDL apps, you'll need libsdl-esd ou libsdl-pulseaudio,
    respectively. Also, you can install libsdl-all to have all sound
    outputs, but unless you specify it with the SDL_AUDIODRIVER variable
    (as does ET-SDL), the default system used will be ALSA."

  [Hedgewars] 0.9.11 Released!
  http://www.hedgewars.org/node/1507

    "Ubuntu's Pulseaudio is even more broken than usual with SDL.
    I've run into the same issues.
    hwengine hanging - kill pulseaudio, hwengine will be able to exit
    Client sucking up CPU - turn off music and restart - frontend SDL
    not playing nice with pulseaudio will be solved."

In all three cases, people seem to be concluding that SDL-that-uses-pulse
works, while generic-SDL-(that-uses-ALSA) causes problems.,

That seems to agree with the SDL mailinglist post that was attached to
the bug regarding the Tux4Kids apps:

  ALSA output doesn't set buffer size (likely fix for pulse problems)
  http://www.nabble.com/ALSA-output-doesn't-set-buffer-size-(likely-fix-for-pulse-problems)-td21457593.html

    "I just noticed that the alsa audio output never set the alsa
    hardware's buffer size. I think this is why SDL has such latencies
    when pulse audio is in use."

So... can someone try installing:

  libsdl1.2debian-pulseaudio

and see if the Tux4Kids app (and anyone else) still go berzerk in the
LTSP environments?

(That is, assuming those environs aren't _already_ using SDL-that-uses-pulse,
in which case I'm at a total loss.)

Thank you!!!

If this does fix it, I'll also add a note to the Tux Paint website under
"Known Issues", to help spread the word a little more.

-bill!
---
Sounds like we're onto something. Let me try and figure out how to get these fixes on Hardy.

Sorry for the comment chatter...documenting things. I'll test out tomorrow when I'm at an actual thin client - this is when I attempt installation of the debian libsdl pulseaudio package on my server remotely:

---
jerickson@Fibonacci:~$ apt-cache search libsdl1.2debian-pulseaudio
libsdl1.2debian-pulseaudio - Simple DirectMedia Layer (with X11 and PulseAudio options)
jerickson@Fibonacci:~$ sudo apt-get install libsdl1.2debian-pulseaudio
[sudo] password for jerickson:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  libsdl1.2debian-alsa
The following NEW packages will be installed:
  libsdl1.2debian-pulseaudio
0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 206kB of archives.
After this operation, 4096B disk space will be freed.
Do you want to continue [Y/n]? y
Get:1 http://us.archive.ubuntu.com hardy/universe libsdl1.2debian-pulseaudio 1.2.13-1ubuntu1 [206kB]
Fetched 206kB in 2s (70.2kB/s)
dpkg: libsdl1.2debian-alsa: dependency problems, but removing anyway as you request:
 libsdl1.2debian depends on libsdl1.2debian-alsa (= 1.2.13-1ubuntu1) | libsdl1.2debian-all (= 1.2.13-1ubuntu1) | libsdl1.2debian-esd (= 1.2.13-1ubuntu1) | libsdl1.2debian-arts (= 1.2.13-1ubuntu1) | libsdl1.2debian-oss (= 1.2.13-1ubuntu1) | libsdl1.2debian-nas (= 1.2.13-1ubuntu1) | libsdl1.2debian-pulseaudio (= 1.2.13-1ubuntu1); however:
  Package libsdl1.2debian-alsa is to be removed.
  Package libsdl1.2debian-all is not installed.
  Package libsdl1.2debian-esd is not installed.
  Package libsdl1.2debian-arts is not installed.
  Package libsdl1.2debian-oss is not installed.
  Package libsdl1.2debian-nas is not installed.
  Package libsdl1.2debian-pulseaudio is not installed.
(Reading database ... 158872 files and directories currently installed.)
Removing libsdl1.2debian-alsa ...
Processing triggers for libc6 ...
ldconfig deferred processing now taking place
Selecting previously deselected package libsdl1.2debian-pulseaudio.
(Reading database ... 158864 files and directories currently installed.)
Unpacking libsdl1.2debian-pulseaudio (from .../libsdl1.2debian-pulseaudio_1.2.13-1ubuntu1_i386.deb) ...
Setting up libsdl1.2debian-pulseaudio (1.2.13-1ubuntu1) ...

Processing triggers for libc6 ...
ldconfig deferred processing now taking place
jerickson@Fibonacci:~$
---

SUCCESS!

For the record, installing the 'libsdl1.2debian-pulseaudio' package cures the issues I have had with all mentioned programs (Tuxpaint, tuxmath, tuxtype, even circuslinux which I hadn't mentioned before but was experiencing similar issues). The CPU utilization is MUCH better (~3-5% for a single instance of a game instead of near 90%!).

Thank you all so much for the collab. This is a huge win for 8.04 LTSP networks =)

Cheers,
Jordan/Lns

I've uploaded tuxmath, tuxpaint, and tuxtype packages including Jordan Erickson's fix for Hardy, Intrepid, and Jaunty to https://launchpad.net/~edubuntu-dev/+archive/edubuntu-testing . Let me ( or edubuntu-devel mailing list) know if they work or don't work for the different releases. If they work I plan on moving them to an edubuntu-updates PPA. This fix won't be able to make the normal -updates repos because libsdl1.2debian-pulseaudio is in Universe.

I can confirm that 8.10 doesn't experience this issue. What's strange is that my 8.10 has libsdl1.2debian-alsa installed (and doesn't have libsdl1.2debian-pulse), but as I said the issue doesn't appear.

In response to Jordan on 2009-07-30: did Ubuntu 8.10 include Pulseaudio? Was it running by default?

I don't think it was running by default. I think that was in 9.04

There is a newly released libSDL with pulse audio bug fixes. We should
test this.

Sent from a mobile device.

On 31 Oct 2009, at 11:31, João Pinto <email address hidden> wrote:

> *** This bug is a duplicate of bug 454879 ***
> https://bugs.launchpad.net/bugs/454879
>
> ** This bug has been marked a duplicate of bug 454879
> Applications using libsdl1.2-alsa randomly use 100% cpu and have
> broken sound playback
>
> --
> tuxpaint and other tux SDL driven apps slow down and/or freeze thin
> client terminals (ltsp)
> https://bugs.launchpad.net/bugs/269082
> You received this bug notification because you are a direct subscriber
> of the bug.

the libsdl-pulseaudio workaround no longer works for me on 9.10

Pulse audio and SDL are problematic in 9.10.

Sent from a mobile device.

On 22 Jan 2010, at 17:30, mehturt <email address hidden> wrote:

> *** This bug is a duplicate of bug 203158 ***
> https://bugs.launchpad.net/bugs/203158
>
> the libsdl-pulseaudio workaround no longer works for me on 9.10
>
> --
> tuxpaint and other tux SDL driven apps slow down and/or freeze thin
> client terminals (ltsp)
> https://bugs.launchpad.net/bugs/269082
> You received this bug notification because you are a direct subscriber
> of the bug.