David Olofson wrote:
On Thursday 25 March 2010, at 13.32.43, David Olofson
<david(a)olofson.net>
wrote:
On Thursday 25 March 2010, at 12.49.31, Ralf
Mardorf <ralf.mardorf@alice-
dsl.net> wrote:
[...]
> Btw. the
> graphics has access to the main memory, unfortunately it's a shared RAM,
> OTOH I used HPET so unwanted interrupts because of a shared RAM
> shouldn't be the cause, if I do understand the workings of HR timers
> correctly.
>
[...interrupts, DMA etc...]
BTW, the most common problem with graphics and realtime systems seems to be
drivers abusing PCI port blocking as a performance hack. When the command
buffer on the video card is full, the PCI bus blocks the CPU (completely - no
IRQs, no nothing), instead of the driver going to sleep and waiting for an IRQ
or some other proper solution. Might improve the 3D framerates slightly, but
kills lowlatency audio...
Mobo: M2A-VM HDMI
Graphics: ATI Radeon X1250-based graphics, *onboard*
Slot for another graphics is an PCI Express slot, no AGP etc.
The HDMI card is demounted from the PCI Express slot and HDMI is
disabled by the BIOS.
I'm not using a proprietary 3D driver and I wasn't able to test one,
because it doesn't work using Linux, even though there is a 3D driver
for this card and Linux, perhaps the problem is "...-based".
The USB MIDI interface is a 1 in and 1 out, very cheap swissonic.
I suspect the graphics and the USB device causing to much MIDI jitter.
I need to search for an old test, but have no time to do it right now,
but I do remember that Windows without HPET was better, than Linux with
HPET as sequencer timer source, while all other Linux sequencer timer
sources were much more out of time.
Btw. I don't think that Windows would solve this issue for me, the
jitter for my current system is bad with both OSs. I know people where
Linux is bad and Windows does solve this issue ... perhaps Windows will
cause other issues for them ;).