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