> > [...] Upon looking a little further it
> > seemed that the kernel was dynamically boosting the priority of the
> > process much higher than it probably should be, in the end, not leaving
> > enough CPU for playing the sounds without skipping.
>
> Yes, it seems that too many real-world applications are accidentally
> triggering this problem.
no, the problem is exactly the opposite. Here's the key observation:
> the problem seemed to be caused by the fact that the pluginserver (wine)
> was using 100% of the CPU. I simply reniced this process to -10 and
> everything started working fine.
the kernel has detected this process to be a CPU-hog - and indeed the
traces and the above description all say that it really is a CPU hog.
by renicing it to -10 it gets super-attention from the scheduler, so it
can be a CPU hog _and_ create sound.
this is analogous to the 'game problem'. Games too tend to be CPU hogs,
and if anything else is running on the system, they might be hurt and see
longer latencies in getting scheduled. By renicing them the user
(sysadmin) signals towards the kernel that despite these application's CPU
usage pattern, they should get extra attention.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/