[PD] [GEM] advices about midi latency ?

Jakob jakkesprinter at web.de
Fri Oct 11 15:28:03 CEST 2019


Hey Pierre,
You probably know already that there is an openframeworks-ofelia package „ofxofelia“?!
Maybe it helps you with your openframework plans

All the best, Jakob

> Am 08.10.2019 um 15:23 schrieb pierre at 314r.net:
> 
> 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
> 
> 
> 
> _______________________________________________
> 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