Greetings all (again :-),

I have another peculiarity I've encountered on my machine. This was not a problem on non-Ubuntu setup, so it is likely something specific to my configuration. Yet, I am at a loss as to what may be the cause of this.

I am using 32-bit Ubuntu Hoary, Pd 0.38, Gem 0.90, h/w is eMachines M6807 (AMD64) laptop with the latest BIOS installed. Video driver is fglrx (proprietary ATI) on top of X.org.

I've installed realtime-lsm and it works fine (good latency via jack etc.). It is using default settings. The kernel in quesiton is 2.6.10. Pd also runs fine, *except* in the following 2 scenarios:

1) When running as a root or non-root user with -rt flag and I start any Gem example, once the Gem window is created *and* enabled, if I move any open window (Pd-related or non-Pd-related), the system starts hanging for a couple of seconds, then I guess the pd watchdog kicks in (albeit extremely sporadically) and allows me a split second to release mouse button (or click a couple times as if the release I made during the hanging process did not get registered properly) and if I am lucky the hick-up stops (the cpu usage during the hang is 100%). By this time my dragged window usually shows up somewhere else on the desktop. If I do not move the window, everything is fine. Clicking on the buttons/options inside the patch is not a problem as well as doing anything else on computer.

Ironically, when running Pd without -rt flag, there are no problems whatsoever of this kind (could it be that perhaps Gem somehow is not quite aware of the realtime-lsm behavior or something like this in respect to X server, so it supersedes the X server itself in importance, or something like that?).

2) When trying to play Gem examples that use prerecorded movies as textures of the OpenGL objects. Trying to play videos (by sending "auto" option, like in ../gem/examples/04.pix/movie.pd) eats so much resources in user mode that I have to kill the X server (sometimes I have to even forcefully shut the machine down). Cycling through the frames using the frame number inlet/counter (right inlet on pix_movie) is no problem whatsoever. Using the same patch as root allows everything to proceed but at an extremely low framerate (the video card is ATI mobility 9600 so this should not be an issue), i.e. 0.5 frames/sec. Again, manually cycling through the frames via the frame number inlet (I guess one could use metro for this) is a breeze as long as the "auto" is turned off. When trying to run patches which utilize movies I get the following messages depending upon the movie format: .avi file: <ffindeo3> : doesn't support DR1 .mpg file: mpeg3video_seek: frame accurate seeking without a table of contents is no longer supported. Use mpeg3toc <mpeg file> <table of contents> to generate a table of contents and load the table of contents instead. .mov is fine.

Doing the same thing without the -rt flag makes playing of the movie painfully slow (similar like when running as a root), but again when using frame counter instead it's an absolute breeze no matter how quickly you cycle through the frames.

At any rate, I would greatly appreciate any help I can get regarding these two issues.

Best wishes,

Ico