[PD] [GEM] advices about midi latency ?

[pierre at 314r.net]

Hi Christof,

Le 2019-10-07 12:28, Christof Ressi a écrit :
>> reduce pd audio buffer to 3
> 
> generally, you shouldn't run audio in the video process (unless you
> really need it). if you don't use audio (DSP is off), there is no need
> for latency and therefore the buffer size doesn't have any effect (in
> fact, a different scheduling mechanism is used where the message
> system is ticked every ~1ms). This means you should get MIDI input as
> fast as possible with low jitter. So turn DSP off in your video patch!

Mmmm,
I think this is not exactly true :
adjusting audio delay, while dsp is *OFF* does something on midi latency 
(I'm on debian/ubuntu, dont know for other OS's),
if you have an midi interface you can try the attached patch.
(you will have to link, with a real midi cable, the input of the midi 
interface with the output for the patch to work)


>> all I want is to optimize midi latency
> 
> 1 frame at 60 fps is 16 ms. MIDI latency shouldn't be your bottleneck.


yep, if I use "pd -sleepgrain 0.1 -audiobuf 3" I get a midi latency 
around 4ms


> If you really want to minimize graphics output latency, then you would
> need to run at a higher framerate, assuming your hardware (monitor,
> projector) is capable. But what is your actual problem? Is it about
> your video output *noticeably* lagging behind your MIDI input?


I allways try to run the gemwindow around 60fps (depends on the output 
screen refresh rate)
what I notice is that when I open my big gem patches with 3d objects, 
textures, shaders etc, the lag is around 70ms.
and so I must adjust my 'delay line controler'(1) accordingly to keep 
things in sync
(1)https://www.thomann.de/fr/the_tracks_dl_2918_delay_line_controller.htm

Once the [gemwindow] is created
- 'nvidia-settings' tells that GPU utilization is around 30%,
- 'htop' tells the CPU utilization is around 25%

But yes, even if my CPU and GPU dont seems to be harassed, my visual 
output lag (~70ms)...
and I'm trying to understand why and where it happen.

>> - tcltk could also be a problem because I have big patches
> 
> the Pd GUI runs in another process.

ok but what I experiment is that if I select a lot of object in my big 
gem patch and move them,
the midi lag, as measured ans shown in the attached patch, go as high as 
200ms and higher...
So my conclusion is that in some way, the gui refresh influence the 
whole process (and not just its own thread)...

Sorry if I'm not as clear as needed here,
I have done somes investigations :
- profiled [gemhead] render chains with timers (inside pd)
- analysed my pd/Gem patch with the nvidia-settings app and from the 
nvidia nsight graphic debugger
- profiled midi lag with 'pd' and 'alsa-midi-latency-test'
i got somes results, but I think it can be way better...

In others words, what I want to do is somehow 'simple' :
draw a rectangle in sync with a short hi-hat coming from an electribe

(a short hi-hat is ~15ms long, a latency of ~20ms is acceptable)

If you have any ideas with that, I'll be very happy =)


Pierre


> 
> Christof
> 
>> Gesendet: Montag, 07. Oktober 2019 um 11:38 Uhr
>> Von: pierre at 314r.net
>> An: Pd-List <pd-list at lists.iem.at>
>> Betreff: [PD] [GEM] advices about midi latency ?
>> 
>> Hello all,
>> somes questions here about midi process optimization :
>> 
>> the midi setup :
>> a korg electribe send midi message (noteon and controlchanges) to an
>> usb soundcard (umc204hd) connect by USB to
>> puredata/gem to finally draw things on screen (3d objects, videos
>> textures, shaders etc) (nvidia hardware and drivers)
>> 
>> all I want is to optimize midi latency and be able to draw things as
>> fast as possible (considering this hardware)
>> ie reduce the time between the midi event and the generated graphics
>> 
>> what I've done :
>> reduce pd audio buffer to 3
>> use a 'delay line controler' to delay audio (something like 60ms is
>> needed) and so retreive an 'good' A/V sync
>> 
>> I know that :
>> - double buffering add latency (and solve flickering)
>> - somes videoprojectors add latency due to an internal video buffer
>> - the more I can draw frames/second the more I can draw small events 
>> on
>> screen (nyquist)
>> - tcltk could also be a problem because I have big patches
>> - when I measure midi lag by looping a midi message to and from the 
>> usb
>> soundcard I get around 2ms, which is very good ! (tested with pd and
>> also with alsa-midi-latency-test)
>> 
>> any experience or advice on theses questions ?
>> what are yours best setup/experiences to acheive really fast sync ?
>> thanks you all
>> 
>> 
>> Pierre
>> 
>> 
>> 
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
>> 
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list