Hello, first post here.

I am working on a video mixer with effects using pdp and pidip. It consists of four parts each running a separate instance of pdextended 0.42.5 each on one core of my quadcore laptop 2.6.38.6 ArchLinux system. When one of the cores, running several video effects on a pdp stream, maxes out to over 90%, I totally lose realtime update of MIDI messages: when I turn a knob on my Vestax VCI-100 MIDI controller, the changes only filter through after sometimes several seconds! I am using the Vestax connected to each instance of PD through ALSA MIDI.
I already tried lowering the latency of PD and Jack: this certainly has an effect but updates are still to scarce.
I did find a solution: receiving the MIDI messages on the least loaded core and sending them through netsend to the loaded core.

Still I would like some solution to this problem or maybe at least an explanation of why this happens?

.gert.

On the puredata side:
You can put the midi communication patch in it's own instance with 1ms latency and the DSP off... Then send the messages with netsend/netreceive as you do now. Maybe try unloading the midi communication patch to a separate machine?
Check out this thread, Maelstorms response to the original poster helps explain it a bit more: http://puredata.hurleur.com/sujet-5032-midi-latency

On the hardware side:
With the CPUs being worked they will draw more power, starving the rest of the motherboard and causing a voltage dip that can effect the usb ports enough to cause a dropout for a few ms (don't laugh, it happens - some of those budget motherboards are cheap for a reason) - in which case you might need a beefier/more consistent power-supply to keep the voltage up across the board(ha!) - even under heavy load.

Is the Vestax powered by the usb port? on a usb hub? powered hub? or is plugged into a port on the motherboard? have you tried a different port? maybe a separate pci usb card?

When MIDI response is bad, this is only on the PD instances that have full workload, when using MIDI at the same time on a less worked core, response is still fast: so not the motherboard issue you are pointing at. (Thanks for the hints though)