I'm a bit confused... I know that latency is the time that the CPU (or whatever) takes processing the audio, till the audio is audible throw the speakers (or whatever)... but, if I'm using a mic in, for a loop-station... the latency is in the input too?

I mean, if I record something, and then, I start the recording... would it have the default latency... or the latency multiplied by 2? (the recording and the playing).

The workarround to fix this latency is, when the recording ends and it is automatically played... to play it ADVANCED IN TIME with the latency lenght (eg 5.3ms)... or the latency time * 2 (10.6ms)?

For the moment, I'm testing with latency * 2 and sounds good... but I want to know this to clarify my mind.

Thanks in advance.

Using Pd-Ext 0.43.4, on Ubuntu 12.04, using Jack 48khz, 256 frames, buffer 3, latency 5.3ms (yes, I know it is a lot, but I can't get less).

Yop,

I tried to use your patch, but couldn't understand why I get no sound out of it.
I see the input graphbar moving when I sing into my microphone, but when I follow your instructions I press "samp" button, the selected "bank" button turns red, I use the mic, and then turns back to green. And then...no output. Clicking the loop button doesn't help.

Anyway when doing nothing I get 40% cpu load.

Nau

Nau, I tried that version... and you are right. Don't know why. Anyway, I upload 0.91 version. As I upload it, it works (maybe overdub doesn't, because it is compiled for Linux 64bits).

http://puredata.hurleur.com/viewtopic.php?pid=38423#p38423

The patch is CPU burner. Doing nothing, in my machine, it is at 28% and it reachs 50% at full (with vocoder). Try it and tell me.

REMEMBER: the starting-in-advance playing feature (actually 38ms) is for my 30ms of latency. Try with 256 frames. If you want to use it with 128 frames, it will work... but with a little unsynch.

Thanks for the answers Katja. I did mean 'Block size', I was looking at the French translation of the interface.

Thanks MarioMey.

I tested the working version of the patch, it works with 128 samples without any xrun on my old 3gHz Pentium 4, 4gb ram, and m-audio fast track pro (usb card). 40% cpu with 8 banks playing and vocoder effect. Didn't tested latency-correction as I didn't see a fast way to automate such a test within your patch.

I only had to do a litlle usual "trick" to manually give Pd a higher rt priority : first get pid of pd-extended : "ps -e|grep pd", and then
"sudo chrt -f -p 70 the_pid_you_got_above".
This is for an ubuntu lucid TangoStudio distro.
If I don't do that I get clicks and pops in the audio, they vanish when rtprio is pushed up. (when I hear clicks jack doesn't report any xrun though. With time I learned that it is possible to get no click even if you get xruns ("freewheel" mode with jackdmp), but also hearing clicks when no xrun is reported (stranger, though).

Nice patch ! Congratulations.

Nau

Nau, what you told me to do, does no difference. The clicks are still there. I tried -nogui option... but I think Pd has a bug, because the noise is worse than with gui (I reported as a bug in pd-list).

With GUI, moving the mouse arround the patch makes a lot of noise, additionally.

My notebook is a (f*cking) HP dv6-3160us, with AMD Phenom II Quad-Core N950 for notebooks 2,10 Ghz. The problem of these processors, is that they are multi-core. It is not good for Pd, nor BlenderPlayer. I know that this is not the notebook for my needs.

I'll install Ubuntu Studio, to try lowlatency kernel, because I tried to install in this distro, and I have errors in installation (didn't find server).

The workaround is intended for rt systems only (they allow you to raise or lower of priority of applications), that's normal it gives no result on your system.

Katja, after several tests and re-organizing the patch, getting rid of a lot of send~/receive~ objects... I got very good improvements in latency.

Now, I'm a bit confused about different results, using your latency-tester.pd inside my patch. Sometimes, I've got 11.6 or 12.75 or 13.7. The Jack and Pd audio configuration are always the same.

I know that its 1 or 2ms... but I think that it should be always the same...

Why, Mr Anderson, why?

That's weird indeed Mario. Latency should be constant within a Pd session. From one session to another there may be differences, because Pd and JACK are not the only processes causing latency.

There's one case where I've seen latency fluctuating within Pd sessions: when two different soundcards are used, one for input and one for output. JACK (or CoreAudio on a Mac) has to compensate for clock drift in such a case.

Katja

Katja, I forgot to say that that difference in latency are not in the same session, but restarting Pd and Jack. And then, the latency, in one session, it is always the same (your patch works very good). Also, I'm using only one soundcard, for input and output.

Every sample looping bank, after recording, inmediatly, it starts playing advanced in time the result of latency-tester, plus 1-2 ms. Now, it is 14ms. This is for synch with what I was listening to. For esample, if I have a recorded sample bank playing a beatbox sequence, and then, I want to record another beatbox (obviously, synched), I need to put this 14ms. Otherwise, when it starts playing, it sound unsynched.

For 1-2 or 3ms of difference between sessions, there's no problem. But, if the difference was higher, this "corrector" wouldn't work.

I think this difference is about a lot of things in the computer... isn't it?