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?
Where does latency come from in Pure Data?
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
Oops! Looks like something went wrong!