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@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: pierre@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