[PD] [GEM] advices about midi latency ?

pierre at 314r.net pierre at 314r.net
Tue Oct 8 15:23:49 CEST 2019


Le 2019-10-07 18:27, Christof Ressi a écrit :
>> 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.


thanks to have a look into this !
I've edited m_sched.c accordingly (lines 515 and 555) but with no luck :
latency vary again with delay parameter
looking forward your 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.


yep true, I also dont think that it is midi code which is slowing down 
Pd,
but the thing is midi is delayed and this is what I want to avoid


> Unfortunately, I can't help much with GEM,
> but there are other people around on the list who might have something
> to say.


Yeah I hope I'm not the only one having this kind of consideration =)


> 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].

yep, I can do somes tests with nogui and/or another pd instance


> Alternatively, you might give Ofelia a try and see if you
> get better graphics performance.


I'm currently learning openframeworks, mainly because of this latency 
problems

anyway, thx for your help


Pierre



> 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