[PD] [GEM] advices about midi latency ?

Christof Ressi christof.ressi at gmx.at
Mon Oct 7 18:27:48 CEST 2019


> 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: pierre at 314r.net
> An: Pd-List <pd-list at 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: 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
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>





More information about the Pd-list mailing list