anyway.
Plus what's very important is that every
kernel developer and driver
developer (even thirdparty, especially those
that do closed source stuff like Nvidia etc) takes into account the
latency problems that code paths that run for
too long time (or disable IRQs for too long etc) might create.
While I'm not a kernel expert I assume the premptible kernel alleviates
this problem but I guess it still cannot
completely get rid of low latency-unfriendly routines and drivers.
Yes, this is important. One problem I had recently with the Via EPIA
board was that unless 2D acceleration was disabled by setting 'Option
"NoAccel"' in /etc/X11/XF86Config-4, overloading the X server would
cause interrupts from the soundcard to be completely disabled for tens
of milliseconds. Users should keep in mind that by using 2D or 3D
hardware acceleration in X, you are allowing the X server to directly
access hardware, which can have very bad results if the driver is
buggy. I am not sure the kernel can do anything about this.
that's bad news.
VIA markets those mini-itx mainboards (with onboard audio/video/network)
as multimedia appliances and
therefore I'd expect the hardware providing low latencies when both
video acceleration and audio is used.
Hopefully only a driver issue (as in most of cases)
Since VIA released the unichrome (the gfx chipset contained in their
mainboards) sources someone should
contact these folks :
to check what is causing those latency spikes ?
Any unichrome developer lurking on LKML ?
cheers,
Benno