From what I've understood in the link I've posted in this thread, you have to add audio and MIDI latency, to get the result of the delay you get with all the sound hardware.

That's exactly the case.

One thing I didn't figured out in this topic is that if MIDI latency is almost about one second when audio is on, then the audio latency must be be nearly this high latency as well, unless the amount of MIDI information is huge.

This is caused by an error in pd. Pd needs at least as much delay as the soundcard buffer. If you go below that pd starts to stutter and does weired things like delayin audio and MIDI. A similar thing happens when you go way beyond the maximum cpu consumption e.g. 300%.

Sorry if I'm picky on importance to know exactly how far the informations are delayed, I've been passing a kind of war in the computer just to get a few milliseconds in the PD processes, by reviewing how the objects [trigger] and [until] are used all along the application.

I don't know what kind of buffers are used internally in pd. Maybe one of the developers can say more about this.

Another point I've been thinking of that only concern latency and not MIDI nor XP, is that the player must have one meter latency (about 1000/320) if he do play with headphones, so 3ms would be perfect. With OSS driver on linux the delay goes above 5ms. I've got this result with dividing by two the output of [timer] with the two inlet connected to MIDI in and out.

As mentioned earlier the actual latency is not the most important thing as long as you can keep the jitter low. Think of a large orchestra where the timpany player may easiely 5 meters away from the first violin. That's 15 ms of latency. They can still play in sync because the latency stays consistant. Same thing for "acoustic" church organ in a large cathedral where the instrument itself is so large that there are even latencies between the differnt notes and registers. Not even talking about mechanical delays.

Ingo Scherzinger