Hello,

I was running some tests with my mic and guitar on Pure Data and noticed some latency. I know this is a beginner's question, but where does this very Pd latency come from?

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

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

@whale-av Why is there both a buffer size and the Delay? It seems like there is an additional delay on top of the sound card buffer, which can't get below the buffer size.
But it sounds like they are cumulative, i.e.

( Sound Card Buffer + Delay ) % Pd Block Size

@Pandas As above..... Pd has an input > output delay equal to its block size.
Put something in and it will output 64 samples later.
But the soundcard cannot convert that to analogue instantly... so we add a buffer that gives it time to process the audio before the next block arrives.... MOTU 2-3ms with ASIO... On board soundcard usually 30-80ms.
I see you posted elsewhere on the forum..... https://forum.pdpatchrepo.info/topic/14495/sync-to-external-daw-midi-clock-audio-latency
I don't know those programs and maybe someone else will help.
Sending the audio samples to another program through a port will still not be instantaneous... but should be close unless you are listening to it at the same time.... but even media players will buffer at least 512 samples before they play a stream.

Does QSynth have compensation settings to delay the midi and attempt to match the audio timing?
What is your OS?
As you are communicating with software rather than a DAC you could try reducing the Delay (mSecs) in Pd media settings,,,,,, down to 3, then 2, then 1.. 0 probably not but you never know.... basically until it hangs and then go back to the last setting that worked.
Apply but don't save the settings until you are done.... or Pd might not start or might not let you change them again while it is "stuck" even if you restart it.
There is a fix for that..... I will upload it if that happens..

Running Pd at 96kHz audio rate should I think reduce the 64 sample (Pd internal) block delay.... you could try that too...... I think it should output in half the 48kHz time.

And try this..... it might help....... depends what you are wanting to achieve...... https://forum.pdpatchrepo.info/topic/13125/batch-processing-audio-faster-than-realtime
David.

@whale-av Thanks, David.

I'm on Linux. Here's a little on apps I mentioned.

JACK is a "low-latency" multiplexing sound server (i.e., audio patch bay for pro apps)
It's sister server, PulseAudio, is the system's generic "multiplexer" - these are needed because the modular driver system ("ALSA") doesn't do multiplexing, but only speaks to hardware.

Both JACK and PulseAudio are on trial overhaul with a new thing called PipeWire, which acts as an in-place substitution multiplexer server.

QSynth (fluidsynth) is a soundfont synthesizer - and yes, it has its own settings for buffers, but as long as audio apps are set to use the JACK multiplexer, they are bound by its hardware buffer size setting overall.

The Delay

The Pd delay I am getting is about 80ms, with the Pd "Delay" set to 40ms, and buffer size set to 1024 samples (at 48 kHz).

The QSynth is quite smaller, in fact, it is about 21ms, which equals 1024 samples.

Pd freezes if the "Delay" amount goes below 21 - but as I've mentioned, the overall Pd delay is 80ms.

(Reaper is a cross-platform DAW used by many)

The soundcard

The soundcard is M-AUDIO M-TRACK DUO.
M-AUDIO doesn't offer support for Linux, but ever since the Delta, I think, the driver is more or less similar and has been incorporated into Linux...

I can normally get recording-playback in the Reaper DAW going with 256 samples at 48 kHz steadily, and down to 128 samples with some underruns (for precision MIDI finger drumming, etc.)

The double buffer

One important thing to note is that along with hardware buffer size, the JACK system offers a config parameter of the number of buffers to use. Normally this is set at 2.
Perhaps that is the problem

@Pandas Maybe try just PipeWire..... there are new GUI options on page 2 here...... https://linuxmusicians.com/viewtopic.php?t=25768&sid=da2a4831d827495d8b05a7ec1931b92f&start=15 ... which will make experimentation much easier.
I only use Linux to make and recover disk images.... get into password locked windows machines etc... so I will not be much help.

@whale-av Thanks.

It seems the MIDI clock patch does not reset properly. Or, there should be a delay of some sorts when syncing to MIDI clock.

My apologies, this went a bit too far out of scope.

I can nudge the MIDI clock input to 0, and sync it properly.

Just need to figure out how to nudge it automatically.

Thanks a lot,
Raymond

EDIT:

I am resetting the PPQN counter to 0 on FA (MIDI clock PLAY).
But this does not sync properly.
Clock SOURCE according to MIDI spec should give some delay for the target to sync (1ms). Figuring out how to implement that....
24 is a weird number

TL;DR:

"Blocksize": hardware buffer size
"Delay": extra latency

Then, in the Pd audiosettings, you set the "Delay (msecs)". This sets the size of the buffer between Pd and the soundcard.

This is not true. (I don't blame anyone for making this mistake, as this is not obvious unless you know the Pd internals.)

By default, Pd uses the so-called "polling scheduler". The message system and DSP run in a dedicated thread which communicates with the actual audio callback via a (lock-free) ring buffer. "Delay" effectively controls the size of that buffer. It adds extra latency on top of the hardware buffer size.

The actual hardware buffer size is always controlled by the - confusingly named - "Blocksize" parameter. (Pd's internal blocksize is fixed at 64 samples.)

Alternatively, Pd may use the so-called "callback scheduler", which is enabled by the "Callbacks" option in the audio settings. In this case, the message system and DSP run directly in the audio callback and latency is only affected by "Blocksize". (This option has disappeared in Pd 0.54, but will likely reappear in the future after some scheduler bugfixes have been applied. See https://github.com/pure-data/pure-data/pull/1756.)

Tip: If you run Pd with the default "polling scheduler", then you should set "Blocksize" as low as possible and control latency with the "Delay", as it offers finer granularity.

@whale-av Update on pipewire - it is taking over; it is the default now, and both jack and pulseaudio have pipewire wrappers.
On Fedora distros, it is the default.

Even QjackCtl (control GUI for JACK) is now disabling it's hardware controls in favor of pipewire.

However, pipewire does not yet have a standardized GUI, but the visual patching component from QjackCtl has been forked into a standalone app.

Pipewire seems great, although I'd wish they'd ditch the video stuff and concentrate on audio more, and GUI / ease of use.

We'll see. Is it better than WASAPI or ASIO4ALL, I don't know. But it works out-of-the-box.