@MrKoggs1 Have you used the interface without Pure Data?
If you want low latency then asio will be the only way to work with windows.
Maybe the M-audio drivers will only work with asio?

If you select "ASIO (via PortAudio)" in the Pd "Media" tab then when you open the tab below for "audio settings..." to select the interface you will see that it now lists the "Asio" drivers.

If you want to use the built-in interface as well then it will be best to use Asio4All..... which can build an aggregate device for all of your sound interfaces (better than Pd can manage).
You will need to set up the asio driver (Asio4All or the M-Audio driver) to match Pd Audio settings...
64bit buffer.
44100 or 48000Hz
and set Pd to 2 or 3ms in the "Delay (mSecs)" box (more if it doesn't work).
Ticking the "use Callbacks" box is a good idea.

In Asio4All....
For Vista you will need to tick the "Allow Pull Mode (WaveRT)" box.
Set the "ASIO Buffer Size" to 64 samples.

Sometimes you will need to try (re-open) Pd a few times before everything talks properly.
I might have forgotten something!
David.

@dimagimburg You might find that there are adjustments possible for your computer soundcard.... and if so there will be some help with latency on Google.
The Pd audio settings will help if your soundcard is capable. Generally very low latency is only possible in windows with Asio. OSX has low latency built in.
A built in sound card might not be asio capable.
Leave the buffer (Block size) at 64 and reduce the Delay (msec) setting in Pd as low as possible. If you cannot save the setting, or Pd audio hangs then increase the delay again. Sometimes Pd gets permanently stuck. If that happens open this patch.....
fix.pd
save the audio settings, re-open Pd and try again with the best (lowest) setting you managed the last time.
Zero latency is impossible, but a few milliseconds will be inaudible.
David.

@whale-av
I'm using a RME Fireface uc with it's own Asio driver on Win7/10. On Purr Data or vanilla I can set latency to 2 ms as well, but the roundtrip latency tester gives me the same results for 2-5 ms (around 440 samples measured with cable). With a 48 sample buffer instead of 64 on my soundcard I receive even worse values.
But on pd-extended it just doesn't work. Don't know why, but as it's not updated anymore, I prefer working with vanilla and Purr Data.

Anyway - in the manner I'm trying to loop, latency doesn't really matter, but you have to know it's length. Even with a latency of 50 ms or more you won't notice any offset in the recorded loops as long as you know the exact length of the latency.
Tracks get recorded and shifted by the latency afterwards, so latency should be compensated.

You're right, latency won't add up in Pd. But I don't use an in ear system. So if you change your reference from a metronom to a recorded track and from that track to the next recorded one, you will add up latency when the latency isn't compensated.

Xaver

I changed my first post and uploaded a zip at the end.
Works with Purr Data or pd (plus zexy)

@whale-av
Thanks for your patch. I tested it with extended, but I get latency issues. When I record saying something like "tik" on the beat, the "tik" is heavily delayed to the metronom on playback. But on pd extended I can't set the latency lower than 24 msecs. So there might be some issues with extendend on my machine. (pd or Purr Data let me set the latency to 5 msecs without problems.)

You wrote: The biggest problem with (not noticing) an edit will be a difference of volume (power). Our ears are very sensitive to that.
The second biggest problem will be the quality.... timbre..... but as you say a crossfade could help. But the bigger the difference the longer the crossfade needs to be.
I thought about starting recording a little bit earlier and stop somewhat later, so I can crossfade between these extra samples. And maybe it's easier than I thought.

@LiamG
Thanks. How can I trigger between blocks? I thought messages are only send once during a block, aren't they?
About 3): I was wondering, if it is a problem, not to be able to set the exact metronom tempo

And here's a little screenshot to see what it looks like:

I would say, anything above 5 ms latency between the metronom and some voices starts to feel strange. And when you start to change your reference - say you start recording with the metronom, change to first recorded line as a reference, than to the second etc, - the latency will sum up and increase.
I wonder how latency is treated on hardware loop stations.
And I'm still asking myself how latency should be treated to get it right.

Regards,
Xaver

Hi,

I'm creating a loop station and I've got several questions about different issues.

1. Latency
2. Fading/Cutting recorded samples at start and end
3. Metronom settings

1) Latency
I'm using the latency tester from the repo.
http://www.pdpatchrepo.info/patches/patch/92

Latency might be calculated with different methods:
a ) Connecting the output of the soundcard directly to the input via cable. This way the lowest possible latency is received. (Around 440 samples in my case)
b ) Calculating via microphone and speakers. Latency will be higher compared to a ). Also the bigger the distance between mic and speakers, the higher the latency will be.

Which calculation should be used?
(To me it seemes to be logical, to use the latency calculated by b ), as that is the method which reflects the real circumstances. But I'm not shure and it's very hard to tell by what I hear.)

2) Fading/Cutting recorded samples at start and end

When the recorded sample contains a phrase which is completly finished before the next 1, doing a fade with [vline~] sounds OK. But when you record a continuous sound (like a string pad) you will always hear that fade of [vline~].
Compared to Reaper: Cutting a sound and looping it, will result in a continuous sound. To me it seemes like some kind of crossfade between the beginning and the end of the sample is done.

Does someone know more about this? How should it be done correctly?

Crossfading seemes to be a quite difficult task in my eyes, as a lot of calculation has to be done. (Recording has to start a bit earlier and to stop later, sync has to start earlier, and so on)

3) Metronom settings

This loop station depends on a metronom and works similar to Ableton Live. As pd uses blocks of 64 samples, the tempo is corrected to a tempo which corresponds to an array with a size multiple of 64. So playing can easily be kept in sync.

I'm not shure about this. Is it a good idea to do it like this?
But changing this to a manner, where the tempo might be chosen freely, will result in much more complicated calculations. Is it worth it?

Thanks for any comments in advance,
Xaver

My patch is still in development and can be found here:
https://github.com/XRoemer/puredata/tree/master/loop-machine
(downloading from github: go up one folder and use the download/clone button
https://github.com/XRoemer/puredata/tree/master)

loop-machine2.zip

@Wolf-Breath Hello there......
The symptoms that you describe are those of Pd struggling because of incorrect audio settings. It is not your fault, they are not easy to set up initially.
The quickest way to get it working (and you would have the advantage of using the computers other audio connections at the same time, or even multiple asio soundcards) would be to use Asio4all......... http://www.asio4all.com/
I am assuming that you are using windows (FL and reaper)?

(FROM HERE TO........... "END" BELOW SHOULD HELP WITH YOUR CURRENT DRIVER AS WELL!)
Make sure you select ASIO in the Media window first.
Then in your Media/Audiosettings window choose Asio4all (or your asio driver for your Focusrite if you don't want to use Asio4all) as your soundcard and set the channels (number of channels) that you want to use (total including your computer soundcard). Don't worry if you set too many, as Pd will just drop any that don't actually exist.

Set Pd something like this.......
If you have problems then set the samplerate to match your soundcard, the delay higher (try 30 or more for example and then gradually decrease it to reduce the latency) and try a higher block size although that should not be necessary. Ticking the callbacks box allows Pd to communicate better with the soundcard. Then go back to choosing your soundcard again. The setup you see above gives 2ms latency which is excellent. (END)

Now you should have a little green icon for the asio4all driver in your taskbar (if it is red then there are settings to be changed to make it work).
Click that to open asio4all settings and you should see something like this........ If not then click the "spanner"at the bottom right corner.

Choose which inputs and outputs you want to use, and count down the list of active ins and outs making a note of their order in the list (ins and outs separately). They will be numbered [dac~ 1] etc. in the same order in Pd.

Good luck, and come back here if you are still struggling....
You might find that Pd is still struggling because of your old settings. If so then start Pd with no audio from a batch file using the -noaudio flag, before you do the above........ see below.....
David.
If you don't know how to use a batch file then try this before you start setting up your soundcard. It will reset the sound settings so that Pd responds properly again!! http://forum.pdpatchrepo.info/topic/9250/pd-will-not-start
Or make your own like this.....
It will open Pd and load the directory in which the patch Minx_Run.pd can be found, load the readsf~ directory and then turn off audio, turn on asio, turn off midi and load the patch Minx_Run.pd......

Later, when all of your settings are correct you can have different setups depending upon which soundcards you have connected, like this...........

Hi all, I'm struggling a bit on audio latency in pd (windows), so I wanted to have a clearer picture.
Apparently other applications seems to perform quite well (Reaktor), but in pd I'm experiencing serious problems.
I did a simple test, the result is here:

• pd .042.5 extended
• pd patch: 7.stuff/tools/latency.pd, measurement quite precise (Miller says ~1.5 ms)
• audio board: Cakewalk Sonar VS-100 (roland), USB 2.
• ASIO4ALL driver (portaudio)
• line out (1) cable jack connected to line in 1 (mic)
• windows 7 (64 bits)

Pretty instructive, at least for myself. I put a Scope~ object to visually see the output pulse fed back into input of the audio board:
the "sharp" pulse is the one generated by the patch, the "blurred" one that follows is the one fed back into the audio board.
The distance between the two is the "latency" of the system.

In summary, these are the major results I found:

• lowest true (measured) usable latency ~ 30 ms, corresponding to "delay (msec)" set to ~ 8 ms
• lowest true (unusable) latency ~ 20 ms, audio "destructed" "delay (msec)" set to ~ 3 ms
• Original HW driver is totally unuseful, only ASIO4ALL seems working ok (why? anyone has an idea?)
• I probably used very bad cables (see the bad pulse shape following the one created by the latency patch)
• changing the ASIO4ALL buffer size didn't change anything in terms of latency (why?)

Note: the only way I was able to lower down the "delay (msec)" values to few msec was using ASIO4ALL driver.

I'd like to hear your experience (I read about Domien playing "delayed") and if anyone was able to succeed to lower
the latency in win to unnoticeable values (~10 ms or even less).

Alberto

You can assign discreet inputs and outputs but not multiple outputs across different audio devices. Sound software has to access sound hardware through it's drivers and it can't handle 2 sets of calls to two different drivers (if someone has the proper tech jargon, please step in).

There are ways of cheating but they all stink in some way:

On windows: VAC/audio repeater combo
You can use 'Virtual Audio cables' to create virtual devices that you can use for input and output between software. You can piggy-back that audio to different hardware devices by using the audiorepeater utility. So you can set up VAC to make 2 cables (VAC1 and VAC2). PD will use VAC1 and VAC2 as outputs. (Since VAC1 or VAC2 aren't hooked up to real hardware, you don't hear anything.) Then you run 2 instances of audiorepeater. One instance routes VAC1 to 'Onboard speaker out' and the other instance will route VAC2 to 'USB audio device out'.

Downside: Latency, Latency, Latency
The sound is delayed through each step in the chain, and the audio repeater latency can only go but so low before you get scratchy static and dropouts.

On Linux: ALSA virtual device
You can make a virtual soundcard using ALSA that can combine the outputs of two audio cards into one
'virtual' one and then set JACK to output to that device (the setup of which is too complex to explain here).

Downside: Latency/Timing
Each soundcard has it's own timing, and there's no way to keep them in synch, so you can control the latency and you'll have clicks, pops, dropouts, and tons of underruns.

On Mac OSX:
I haven't tried it, but I believe you can also make an aggregate device
There is also a VAC/audiorepeater type program you can use called Soundflower, but like VAC it's really only for routing sound between apps, not between hardware.

Long story short, between the latency introduced by the software and the clock timing differences between soundcards, you can really get anything usable.

For each program that is using the ASIO drivers, an ASIO control panel will pop up in the system tray (you might need to adjust your system tray preferences). Each panel controls an instance of the ASIO drivers for that program. You can open that panel and set the inputs and outputs you want to use for that instance.

I said in the above post that ASIO can connect to one program at a time....but that isn't the full explanation. Each ASIO instance can connect 1 program to the same hardware inputs and outputs at a time.

So if you had a soundcard that had 4 outputs, you can setup 2 programs to use the ASIO drivers, one instance goes to output1 and output2, and the other instance can go to output3 and output4.

Getting your sound program running through ASIO (that's by default connected to all inputs and outputs) and getting sound from the browser (Firefox? Chrome? IE?)
is tricky. The browser doesn't use ASIO, it's using the default windows sound driver to access the soundcard. Try loading the browser first then load PD with ASIO or vica versa.

I've only been able to get a consistent working setup by having multiple (2 or more) soundcards. Windows controls one (browser sound, programs that don't use ASIO) and ASIO drivers control the other (PD, tracktor, cubase, FLstudio, etc). Route the sound output from both cards into an external mixer, and the mixer controls the main speakers (or monitors)

hey hey!

probably my problems with pd's audio latency are easy to explain and eliminate, but by now i didn't make it by myself.

basically i am trying to create a looping-module for some simple live overdubbing. i already supposed that i have to factor in the latency for precise timing, but the presetted 50ms doesn't bring correct results. so i measured the latency with this latency.pd patch, using jack to create the feedback, it shows me a latency of about 24.6ms. is this latency constant? and what does the 50ms-preset mean?

and by the way, what are the first steps to optimize (minimize) the latency?

i am using ubuntu studio, pd-extended and right now the built-in sound card of my ibm think pad t41.

thank you!