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 never had to record under Pd taking this latency into account, as I only play with static data or make "RT" interaction, but let me say how I think (believe ?) it works. Consider it as a humble starting point, I'd be glad to see it corrected by other users.

The latency you mention is for one buffer, but you do have three of them, so the latency of jack+soundcard would be 16 ms. To this "material latency" a software latency could be added, but floss manual (http://en.flossmanuals.net/pure-data/getting-started/configuring/) says that the latency settings is overrided when Pd is used with jack. However I recently noticed that I get better "RT" results whith a "pd latency" lower than the "traditional" 50ms. Did I dream ?

Anyway I'd say that 16 ms is the total latency you should take into account when trying to resync audio. You already think that 2x 5.3 ms sounded better than 1x 5.3 ms, why don't you try 3x5.3=16 ms to see what happens ? And I suppose that you already tried a buffer size of 128 without good results ? If jack doesn't report "xruns" this config has half this latency. And use a musical-oriented distro to get lowlatency or rt-preemption.

Nau

It is best to just measure actual roundtrip latency, rather than interpreting buffer lengths as latency time. In practice, I've found that with Pd-ALSA, actual latency is mostly 1.5 times Pd's nominal delay, and with Jack it is about 2 times Jack's nominal latency. That is because Jack has two buffers, one for input and one for output, and if you use both, the latencies add up. Attached is a sample-precise tester for roundtrip latency.

Katja

http://www.pdpatchrepo.info/hurleur/latency-tester.pd

What a dreamer I was... I thought that I have 5.3ms latency. After using the latency-tester.pd, I realized that I have 30ms.

Nau: someday I thought that I could use 128 frames... but, now, with my patch, that is impossible. So much XRUNs and noises.

I have the habit to use Ubuntu 12.04 (this version because of the LTS, but, mainly, because of video drivers). Which Linux distro do you recommend? Or, better answered... Ubuntu Studio is a good distro to try to achieve low latency?

Hi Katja,

This may seem like a ridiculously n00b question, but is there a particular way I should connect my output to my input to use your latency-tester?
I mean, would it give wildly off results if I used my laptop speakers and mic just listening to each other "through air" ?

Also (question to everyone), just to be sure, changing the vector size on the Audio Config window in 0.43.4 doesn't change the default block size inside Pd, right?

Cheers in advance,
Guilherme

@Guilherme said:

would it give wildly off results if I used my laptop speakers and mic just listening to each other "through air" ?

If you hold the mic near to the speaker, roundtrip latency would only be a few samples more compared to a direct line-out to line-in loop. As a reference: the distance between your left and right ear is about twenty samples (with samplerate 44100).

@Guilherme said:

just to be sure, changing the vector size on the Audio Config window in 0.43.4 doesn't change the default block size inside Pd, right?

As far as I know, 'Block size' on the Audio Settings (is that what you mean?) does set the block size for all running patches, except those which are blocked differently with object [block~] or [switch~].

Katja

Yop,

Thank you katjav, I got a 18.4ms roundtrip latency which is consistent with your predictions (I used 3 blocks of 128 samples, that is a 8ms latency) .

MarioMey :

as you could see, I am among the dreamers too
Ubuntu 12.04 seems to use a generic kernel which is not very "dsp latency-efficient". To make sure of what kernel you use simply type "uname -r" into console. If you need to upgrade to lowlatency, consider searching for string "lowlatency" in Synaptic.

Realtime kernels do exist and should be more efficient than lowlatency ones, but are not always straightforward to install. Moreover my personal experience is that Nvidia drivers need patching when used together with a rt kernel (or patch the kernel itself ?), which is rarely straightforward, again. Consequences may be brutal : black screen and troubleshooting to resume your distro.

Disclaimer : I am not sure that lowlatency kernels are compatible with proprietary drivers such as Nvidia, but I'd believe they are. Sorry for frightening you with that drawback, but I got this black screen with a Nvidia card under debian wheeezy and it took me a bit to get back to the "nouveau" driver I were using previously, typing "apt-get autoremove --purge nvidia*" in safemode.

I use tangostudio (TS) distro, which is now based on a debian wheezy and lowlatency or rt kernels : http://tangostudio.tuxfamily.org/en/documentations/tango-debian
As a music-oriented distro it works fine, but lacks a Pd-extended in the repos... and usually wheezy users need to compile it. But I couldn't (because TS refuses to use "pulseaudio" sound server (considered as "non reliable enough" I think)). So I told it to the distro maintainer that answered the next day with a link to a PD-extended 0.43 ".deb" package he had tailored for me ! Sometimes I'm a dreamer, but dreamers sometimes win So here is Pd-extended on a rt system. Anyway, my Nvidia card isn't supported ("nouveau" driver).
I don't know how other distro behave, as I stopped using after Ubuntu hardy 8.10 to go towards TS.

Nau

Well, maybe I'm falling back again in my very f*cking video driver problems. I spent tens and tens of hours in that... and I don't want to use my time in something like that any more (*)

As I have a generic kernel (3.2.0-49-generic), I'll try different things:

• Installing lowlatency kernel.
• Installing Ubuntu Studio 12.04.
• Installing Ubuntu 13.10 and latest video drivers.... and look if someone of the f*cking ATI company took care about the ones who have the same problem as I (maybe I am the only one).

Anyway, based in what we talked here... I think it is really necessary to modify the sample bank playing start-point to synch with what I listen when I record. "More that sure" (an argentine expression) that I will finish using my 30ms latency... so, I should treat with that.

Nau: if I use 128 frames Jack config, I get 14.2ms of latency. Wow, better that you! Ups, sorry... but I can't use my patch with that config. Maybe you could try my patch and see what happen...? You can download here: http://puredata.hurleur.com/viewtopic.php?pid=37430 (the last version in the thread has no synch fix, but you can test the XRUNS).

Katja or Nau: I'll use this system for my spectacle "El Circo 3D", using BlenderPlayer and PureData (Jack in 1024 frames) to play my digital puppeters. I don't need (and I can't use) low latency for that. In the same show, I plan to close BlenderPlayer and restart Jack with 256 frames to use PureData with the looping-station patch. QUESTION: will I have problems if I use a lowlatency kernel and run BlenderPlayer and PureData at the same time? Because I know that lowlatency (and RT) is not for multitasking work... or am I wrong?

Thanks Katja, thanks Nau.

(*): I have a hybrid video card: ATI 4250 and ATI 5650. I work with realtime 3D graphics, using BlenderPlayer. So... I really need proprietary drivers. I NEVER COULD USE THE 5650 IN LINUX WITH PROPRIETARY'S. No, man, there's no way, it can't switch to discrete card. Once, I could boot with free drivers and that card... but, for 3D, it is so much slower than the 4250 with proprietary ones. So, I spent a lot of money buying this laptop... and I can't take advantage of it. And my economony (and my country's economy) is not for throwing away it and buy another one.

I modify the sample bank playing and added a 38ms playing-in-advance starting.

This is, I divide the sample lenght in miliseconds by 38 and send this to right inlet of phasor~ to start there. Now, every sample I record, it is synched. I use the subpatch "click" of the Katja latency-tester and, then, put the mic in the speaker. Finally, I use a graphic array to fix the unsynchrony visually.

But... I don't know why I get 30.0208ms in latency-tester.pd... and I have to use 38ms to synch my patch. The Jack config is the same and both patch are open when I do the test. Maybe, 8ms is the time that the patch takes before send the 38ms to phasor~ (some messages, some basic math, sending the lenght to phasor and some other messages stuff).

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?