The question of how to tune an all-pass to compensate phase shifts of an IIR filter is also part of my interest.
How to calculate the phase response of an IIR and then build an all-pass with the inverse phase-response?
Maybe @manuels can help here?
Or is a machine learning approximation required?

On latency: As all-pass filters add latency (the phase-compensation is addition of frequency-dependent latency), I would not be surprised if the all-over latency would be in the same order with FIR filters for such a low cutoff-frequency.

Looking at the filter:

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

@bklindgren Maybe "expected I/O latency" or "realtime processing budget"? I say that because if the actual latency is greater, you'll hear clicks as blocks are dropped or corrupted. But the expected latency can be set much greater than the actual latency without problems. Look at the following test:

REAPER sends the test tone on track 1 out its audio loopback driver to Pd, and Pd returns it on the next 2 channels in the loopback driver. I recorded the return signal on tracks 2 through 5 using Pd delay settings of 50, 20, 10, and 100 ms, respectively. The delays on the return tracks are 52, 21, 11, and 101 ms respectively.

@bklindgren It is usually called a buffer and set as "buffer size" in samples...

Pd is unusual in calling it "Delay".
The buffer size in samples divided by the sample rate equals the delay (latency) in seconds.

Of course the block size of 64 samples gives internal latency.
You only need to worry about latency for live work and live monitoring in a studio,
A latency of 2.9 milliseconds (128 samples at 44100Hz) is the same as moving an instrument just under 1 meter away from a listener...... so not really noticeable..... (speed of sound approximately 343 meters per second in air)
David.

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

plugdata sets its reported latency to 64 samples by default and appears to tell REAPER about it. REAPER then tries to correct for this latency using its plugin delay compensation scheme. 64 seems reasonable, right? That's what one might expect as overhead just to get signal into plugdata and back out again (e.g. it takes at least one buffer for Pd vanilla to shuttle signal to/from its own [pd~] subprocess).

But that's not what I'm seeing! I made a track that is silent except for a single 1 in the 2nd or 3rd sample, and have inserted a plugdata plugin that connects [adc~] directly to [dac~]. At 64 samples of latency, if I render the track, the output is completely silent. If I change plugdata's reported latency to 0, the output matches the track.

<spooky music/> Um ... wh-wha-what's going on?

What do you see on your DAW? impulse.wav passSignal.pd

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.

@whale-av said:

I am almost certain that Gui objects in TouchOSC can talk midi and OSC at the same time.
But I doubt that it will communicate over wireless (required for OSC messages) and USB at the same time.

GUI objects in TouchOSC can send Midi and OSC at the same time, and wired USB connection does work for both, no issues. no need for having the iPad on Wi-Fi. just takes a while for TouchOSC on the iPad to realize what the IP address of the laptop is.

The communications between Pd and touchOSC are set in the abstraction [osc-s-r] within the [globpitcharray1] patch in the zip I posted.
There is a TouchOSC layout plom.touchosc in the zip that should be used with this patch (for a test demo).

thanks for breaking this down for me!

You would need to fix the IP address of the Ipad (static address) and use that address for [netsend] and [netreceive] in [osc-s-r] ....... if you ever get over your fear of using Wi-Fi for this.... or just feel like trying it to see what it will do.......

yes, [osc-s-r] is definitely where it's at. thanks for spelling out the [netsend] and [netreceive] to me, cos looking at the screenshot i had, i can now realize where to input 11000 and 11001 for send + receive. the connect portion of the script was throwing me.

i hope i have it right now,

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