> I think this is not exactly true : ha, I just had a look at the code and you're right! Here's the offending line:
sys_setmiditimediff(0, 1e-6 * sys_schedadvance); I think it should be: sys_setmiditimediff(0, sched_useaudio != SCHED_AUDIO_NONE ? 1e-6 * sys_schedadvance : 0); There's no need to delay MIDI if DSP is off. I'll make a PR. --- anyway, MIDI latency is certainly not the problem here, it rather seems like Pd/GEM is running slowly. If Pd blocks, then incoming MIDI will have to wait as well. Unfortunately, I can't help much with GEM, but there are other people around on the list who might have something to say. If you have a really heavy Pd GUI, you can try to move it to another Pd process and communicate with the video process with [netsend]. Alternatively, you might give Ofelia a try and see if you get better graphics performance. Christof > Gesendet: Montag, 07. Oktober 2019 um 17:33 Uhr > Von: pie...@314r.net > An: Pd-List <pd-list@lists.iem.at> > Betreff: Re: [PD] [GEM] advices about midi latency ? > > 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: pie...@314r.net > >> An: Pd-List <pd-list@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@lists.iem.at mailing list > >> UNSUBSCRIBE and account-management -> > >> https://lists.puredata.info/listinfo/pd-list > >> > > > > > > > > _______________________________________________ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > https://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list