[PD] about latency

[Alex]

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 at iem.at
>> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>
>
> _______________________________________________
> PD-list mailing list
> PD-list at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>