delay (msec) is to create the total buffer size. Its important for round trip latency where PD is looping the input to the output - the delay (msec) gets added with the block size (which for compatibility with other patches just keep at 64)

Usually JUCE based programs just give you a "block" of audio, PD is more under the hood about the DSP, the 64 block is a ring buffer that the main patch is at (which is why you have to subpatch to reblock) and the delay msec is padding for the CPU.

Normally you only run into it when you have to up the amount with the sine playing in 'Media, test audio and midi' when you first install PD until it stops sounding scratchy

but also theres another patch in the help browser under 7.stuff/tools/latency you can loop back the output of your audio to the in and play around with lowering it. Either with a loopback function on a dac, or like a wire plugged from out ot line or just have the mic and speakers setup where they could cause feedback if turned up too loud. Tests on the internet for mostly vintage DACS doing round trip latency were actually done in PD.

playing around with it I found Intel macs can go down to 3, and prosumer asio (like an old external edirol dac) can go down to the lowest, 2. Its up to the low level driver to give you the real round trip latency.

usually as long as you can get the sine wave to play in Media.. test audio and midi you are good. Its really only for processing audio in with minimal audible latency - super small delays go off the rails the second you really hit the CPU with polyphony, delay lines, small block sizes.

For a while I had it at as low as it was without being scratchy, but as I got into more complicated (and bloated) synth designs I just kept mine at 50 because when it was having problems more latency than that never helped but less could cause stutters/scratchy sounds.

Linux and Windows are usually set by default to 50 or 100 tho I dont have a problem above 23, offhand I think intel macs were set to 5 or 10. the new arm macs can run into a problem where the old default was too small and should have it higher as well. So the real winners were old intel macs.

use callbacks is only for some older audio drivers in linux

Does this forum not send email notifications when a topic you create gets replies? I didn't get any.

Anyway...

My patch used Vanilla plus GEM and a few externals. I got all the updated versions of all the externals and Gem.
Gem is the one that's causing most of the trouble... or rather all of the trouble.

I get GL stack underflows, crashes when closing the gemwin, "someone sent a bogus pointer..." and other errors, none of which existed back when I created the patch. I have started reporting the bugs to Gem, but it's hard to isolate them, narrow them down and create minimal reproducing examples, as the patch is very, very complex, and the last time I touched it (and Pd) 12 years ago it was running seamlessly and very stable. I also tested on Windows and it's even worse: there it crashes when opening the gemwin.

My goal is not to use the old version of Pd and Gem to run the patch. That would be my very, very last resort. One one hand I suspected a bc-breaking change in how Pd handled some kinds of messages and wanted to test that, but I have already discarded that; on the other hand I wanted to see if I could run the patch without issues on the old versions, and from there either (a) start trying to narrow down the issues, always comparing between the two versions (because I don't remember how half of the stuff works, so if I reduce it to a minimal patch and still get issues, I'm never sure whether I'm introducing errors in the patch) or maybe (b) offer the Gem developers my whole patch (I cannot publish it but I would trust them) as a black box that certainly triggers a bunch of bugs even though it's very far from a minimal test case. I can still do that but it would be nice to confirm that the patch runs with no errors with the older version on a modern machine and OS.

In the end I was able to compile Pd 0.43-3 (pretty sure it would have been the same with 0.43-4) with the "new" build system by using CXXFLAGS="-std=c++98" for configure.

Now I have another issue:

Pd runs but only if I launch it from the correct folder. That is if I do from a terminal:

cd /path/to/pd-043-3/src
pd

it works (that is where the compiled binary was created; anyway everything holds true if I move it to ../bin/).
But if I do:

cd /path/to/pd-043-3
src/pd

then I get the error:

Error in startup script: couldn't read file "../tcl//pd-gui.tcl": no such file or directory

Not a huge deal, I can write a shell script that cds into the directory and runs pd, but it makes me think that something is not quite right.

I'm also trying and unable to compile the old version of Gem, but I'll open a separate thread about that.

@EEight The same graph seems to be available in Bitwig for windows...... https://forum.cockos.com/showthread.php?t=213288
30 day free trial...... https://www.bitwig.com/download/

Not the same, but this portable program (run, not installed) will report dropped frames with a 1000ms deadline, current latency, and maximum latency........ so the info you are looking for..... maybe, maybe not...
DPC latency monitor.zip
Graph on my machine while scrubbing audio in Pd and Video in GEM.......

There is another... I think better.... which gives a massive amount of information also about your drivers, setup, etc. and will tell you which kernels are having trouble...... latencymon 7.31......
https://www.resplendence.com/downloads
David.

@ddw_music Oh OK, well I redid the test using a 1033.6 Hz sine wave (1.5 cycles/64 sample block) and the result is consistent with a 64 sample shift (i.e. 180 degrees out of phase), plus it goes away when I set plugdata's latency to 0. I'm gonna check on the REAPER forum to see what they say about PDC--maybe the issue is that REAPER assumes a base 64 sample latency for all plugins so plugdata doesn't need to report that portion.

It would still be interesting to see if other DAWs behave similarly. Maybe I have to dig out my old laptop and struggle with Cubase again. 1033.6 Hz sine.wav

BTW, is there a way to set plugdata's reported latency to the host programmatically? I have an FFT resynthesis patch that uses different block sizes. Camomile has that facility.

Update: I think I'm seeing the same behavior in Audacity, but my understanding of Audacity is weak. I also tested an FFT resynthesis patch in REAPER using a 16384 block size and set plugdata's latency to 16320 (16384 - 64) ; that produced the alignment I was expecting. So I'm provisionally declaring that you should set plugdata's latency to the latency of your patch as measured between adc~ and dac~. In retrospect that seems completely obvious, but I was thrown by plugdata's default of 64.

0 samples

Using same technique as @katjav 's latency-meter, which was 1 sample off, here is a fixed version:
https://forum.pdpatchrepo.info/topic/13814/catch-would-like-to-set-the-name-programmatically/20

And there is a latency-tester in PD's doc:
07.stuff/tools/latency.pd

As long as there is no windowing, reblocking or delay line involved, objects usually have no latency.

The amount of input-->output latency comes from the soundcard driver settings, specifically, the hardware buffer size.

"Where does latency come from" is this:

The audio card driver processes blocks of audio. (If it didn't process blocks of audio, then it would have to call into audio apps once per sample. There is no general purpose computer that can handle 40000+ interrupts per second with reliable timing. The only choice is to clump the samples into blocks so that you can do e.g. a few dozen or hundred interrupts per second.)

Audio apps can't start processing a block of input until the entire block is received. Obviously this is at the end of the block's time window. You can't provide audio samples at the beginning of a block for audio which hasn't happened yet.

You can't hear a block of output until it's processed and sent to the driver.

| --- block 1 --- | --- block 2 --- |
| input.......... |                 |
|                \|                 |
|                 \_output......... |

This is true for all audio apps: it isn't a Pd problem. Also Pd's block size cannot reduce latency below the soundcard's latency.

You can't completely get rid of latency, but with system tuning, you can get the hardware buffer down to 5 or 6 ms (sometimes even 2 or 3), which is a/ good enough and b/ as good as it's going to get, on current computers.

hjh

@lucassilveira http://puredata.info/docs/manuals/pd/x2.htm Chapter 2.4.5 onwards explains the internal workings, and how delays can be wrongly introduced into the Pd audio thread.
But the simple fact that audio is processed in blocks of 64 samples when it is passed in from [adc~] and sent out through [dac~] introduces 1.45 milliseconds of latency.
Then, in the Pd audiosettings, you set the "Delay (msecs)". This sets the size of the buffer between Pd and the soundcard.
Using core audio, or ASIO in windows, and depending on the actual soundcard, you could get this delay down to 2 msecs but you might find you need 3 or 4, or 5 or more to avoid dropouts.
If you are using MIMO with a computer built-in soundcard then 30 might be as low as you can get..... so another 30 milliseconds of latency.

Asio4All is a universal ASIO driver for Windows...... and nowadays internal soundcards are often ASIO compliant so it is maybe worth trying, although if your computer has such a soundcard then the manufacturers driver should be available and might be good enough...... select ASIO in the Pd media settings before choosing the driver in Pd audiosettings.
David.

yes, Katja's meter measures 1 sample latency additionally, so real latency is -1 sample.

here are threads of other forums:

https://forum.rme-audio.de/viewtopic.php?id=23459
linking to
https://web.archive.org/web/20160315074034/https://www.presonus.com/community/Learn/The-Truth-About-Digital-Audio-Latency

and an older comparision:
parts 1 2 3:
https://original.dawbench.com/audio-int-lowlatency.htm

https://gearspace.com/board/music-computers/618474-audio-interface-low-latency-performance-data-base.html

the patch looks legit:

in Real Life latency occurs in every part: converter, port, driver / os, pd.

Linux can be set up to be very responsive on audio with realtime-priority ect. (how can this be done in Win?)

USB(1 and 2) introduces 1 or 2 ms of fixed latency.
RME pci(e) cards are the fastest hardware and drivers you can get (Linux too). Marian could be sameish (no Linux, last time I asked).

Today there are USB3 / Thunderbold, too - but don't know about their latency.

If you have headroom, 96k should be faster.

Because of the complexity of the chain, I would be surprised if latency would be same anytime, or to put it differently:
If the patch relies on it, I'd do the measurement each time on startup (with a free io channel or switching patchbay), even more in a live-concert. But empiricism on your system could disprove it, - and now I realize that this actually is your question, but no, I can not share experience on reliability of latency in Windows.

@jameslo which post of katjav are you referring to?
Recurrently there has been some conversation about latency on the pd-list.

@s.elliot.perez My setup looks like this..... but different soundcards of course...... and only 2 including the built-in Realtek.


I needed very low latency.... so extreme Delay (msec) of 2 setting for Pd....... and an ASIO buffer of 64.

I notice that I have selected all the stereo pairs for the Motu...... rather than the "whole device" that you have chosen for the GP-10.
I would try turning on only one device at a time in Asio4all and making sure that the buffer sizes all match in the dedicated control panels for those soundcards that have one. But I think you posted that the buffers matched.
Ticking the callbacks box in Pd might help.
I cannot see anything "wrong" in your screenshots.
You could try using this DPC latency checking program to see if interrupts or dodgy drivers are causing problems.........DPC latency check.zip
Lastly, modern computers often use internal usb ports for the mouse, keyboard, bluetooth etc.
Changing external port so that you are using a different hub could also help.
Where are you hearing the glitches.... on one device or all?
David.