> >Yes, I thought the same thing, and I did just that, but no, it doesn't
> >fix the latency issue. This system has very little running, I made sure
> >that there were no sound servers such as esd or arts running, nothing.
> >Basically, a plain KDE (with artsd disabled), mozilla, and Crossover
> >wine plugin. Even though I couldn't see how it would affect anything I
> >tried bumping up the priorities of other processes such as mozilla
> >itself, X, etc. Nothing fixed the problem except for lowering the
> >priority of the wine process.
> Feel like trying something else for grins? If it's thud.c type starvation
> you're seeing, the attached club should beat it into submission.
I gave this a try this morning and it still doesn't seem to solve my
issue. I have no idea what is going on with this particular scenario.
For now I've fixed it with a simple wrapper script that start up wine
with a '15' nice level.
I did do some playing, it seems the problem mostly goes away right
around nice level 8, before that I seen no noticable difference, after
that it seems completely gone. Would there be anything special about
I do have one, probably wildly incorrect theory. Most of the problems
I'm seeing seem to revolve around issues when there is a fairly CPU and
graphics intensive application running. In this case flash has lots of
glitzy stuff happening, interactive menus popping up using lots of
graphics and sound, etc., while in the meantime wine is using lots of
CPU to keep these things all working. It almost seems that it's the
combination of the two of them that leave too little time for sound to
be played correctly.
As a test of this idea I simply reniced the X server to 19 and the
problem did get a LOT better, although it did not go completely away. I
could make the problem go completely away with the X server niced at 19
and wine niced at 5. With X at it's normal 0 nice level I had to renice
wine to 8 before the problem was corrected.
This seems to match up with the issue that some people have noted that
their XMMS skips during virtual desktop switched, etc.
I'm not sure if any of that helps anything really, or if there is really
a "correct" fix for this, or even if this behavior would be considered
I've corrected it for now with some simple wrapper scripts to set nice
levels on the offending processes. So far this works great.
I'll gladly test any other patches, suggestions.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 07 2003 - 22:00:23 EST