Hi,
Thanks for that. This is basically what I understood in the first place except for the output. I have tried these days to calculate the latency of my system: I played a rhythm from a sound file in pd, and I played the bass guitar on top of it. I recorded myself with writesf~ back in pd and I opened the sound file in a sound editor. The thing is depending on my patch and then on the CPU load used for it, the delay at the beginning of the file I have recorded is never the same. I have built a patch that allow me to play with other musicians on the Internet so it is very important (for resync purposes) that we know precisely the latency of our different systems. So far we guessed it while sound checking but I wonder if I could do a single patch that would tell me in ms how big is the lag just by loading it. (without having to record and then go into a sound editor). If somebody has an idea it will be great to share it.
Thanks a lot. Alex
On Wednesday, July 16, 2003, at 10:05 am, vanDongen/Gilcher wrote:
Hi,
A soundcard has an input and an output buffer. Both are divided into chunks called fragments or periods. Audio is read and written in these chunks. The input latency is usually one chunk, and the output latecy is the entire output buffer. I am not sure how portaudio handles all this, but the principle is the same for all systems.
To sync recorded material with an input stream you need to add a delay to the recorded material of a chunk's duration.
But there is also latency jitter. It can be caused by processor load. An (almost) inaudible buffer overrun (xrun) can cause a jump in the input latency, because the systems misses a deadline, so it skips a chunk. It will probably also result in output buffer underruns,but that doesn't affect sync, it just caused an unsteadiness in tempo I think (?). The overall result is that the latency changes. Because your chunk size is probably pretty large, it is very noticable.
You could try increasing the buffer so that the processor has more "breathing space", or you could try to decrease your fragment/chunk size, so that the jitter is smaller. But that requires more processing power, so you will have more smaller but more frequent variations. There are some command line arguments to set these.
The processorload might be caused by the loading of the patch. So you should check if it also happens if you turn on the audio processing after you have loaded all the patches.
hope this helps Gerard
On Wednesday 16 July 2003 00:03, Alex wrote:
Hi,
When I start up pd My version of portaudio tells me the latency I have: 46ms I have built a patch that records sound input on a tempo and I have noticed that my sound takes some times to get into pd. I have always thought that latency was the time the sound would put to get in then out but I thought that the sound would put something like 0.005ms to get in and a file played from the HD would put the same. So as I did not care about direct monitoring stuff, I did not mind. Recently I have recorded samples on a tempo generated in pd and when playing the samples back I have noticed that my samples were not synchronized with the tempo. Can somebody confirm me that the signal get some significant time before getting into pd ? Or else ? Also, I have then tried to play my samples a bit earlier than the tempo something like 89ms and then my samples where back on tempo. But 2 days later that 89ms became 130ms. (I used different patches) Can the in/output latency be variable according to the CPU I use ? Humm...
Alex
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list