I finally did this test, with the phones-and-mic method: http://manual.audacityteam.org/man/Latency_Test
I am curious to see whether there is much difference between my debug and release builds.
But I wonder. You can set the latency correction to a positive number, and code is there to shift your recording right rather than left by inserting silence. But, why would you ever want this? Are there strange hardware setups that can really require it?
“Cover Your Butt” programming? “We can all stop what we’re doing and try to find some condition that requires this, or we can put it in Just In Case and keep going.” I bet including it wasn’t even a tiny development speedbump.
Koz
Another variation on that is the hazy memory of someone in Late Victorian London requiring this once, so we better include it.
Koz
My attention was draw to this because I am trying to implement a “punch and roll” recording feature. I’m too late with it for inclusion in 2.1.0 though.
I notice this: If you append-record one track while overdub plays another track, then the latency correction is done AFTER recording stops. You can see what you just recorded jump left (if the setting is negative).
That’s a little weird, and wouldn’t it be better to figure out the latency correction up front as the new samples are being laid down?
Well I know from my experiments how I could fix that now.
I know someone who uses positive latency correction as “automatic silence insertion” for language learning.
Latency correction is always done after recording stops.
I think what you notice is probably better than retaining the entire length of the append-recorded audio and pushing it (and any pre-existing audio before it) backwards.
You mean so there is always the correct latency adjustment automatically applied on Stop (as now), or that samples are moved to the correct position before being laid down?
I think the moving back on Stop is instructive if the latency adjustment should not be correct, but automatically calculating the correction would be a big win if reliable IMO, yes.
Gale
Users are inventive!
[quote=“Paul L”]
If you append-record one track while overdub plays another track, then the latency correction is done AFTER recording stops. You can see what you just recorded jump left (if the setting is negative).That’s a little weird
[/quote]Latency correction is always done after recording stops.
I think what you notice is probably better than retaining the entire length of the append-recorded audio and pushing it (and any pre-existing audio before it) backwards.
I do not understand that “better than.” You and I describe almost the same thing, do we not? Mic picks up audio in the latency period which you see as recording proceeds, then you stop and that portion is cut out. Try it with a very negative setting to make it more pronounced. Of couse nobody wants time shift of what precedes the new portion, that does not happen now and I do not suggest that.
[quote=“Paul L”]
wouldn’t it be better to figure out the latency correction up front as the new samples are being laid down?
[/quote]You mean so there is always the correct latency adjustment automatically applied on Stop (as now), or that samples are moved to the correct position before being laid down?
I think the moving back on Stop is instructive if the latency adjustment should not be correct, but automatically calculating the correction would be a big win if reliable IMO, yes.
Gale
As the code is now, the correction depends only on the Preferences. There seems to be something in the code to adapt the latency period based on information supplied by the port audio routines as recording proceeds, but it is commented out.
If that adaptiveness is reenabled, then we can’t see the future when recording starts and make the adjustment exactly. There would remain fine tuning after stop. At the risk of code complication, maybe we could make the fixed coarse adjustment at start so that the later adjustment, if only a few milliseconds, is less visible.
For punch and roll recording, the intent is a few seconds of play then a transition to append-recording. Capturing those seconds and then cutting them at stop would work but just look too strange. I had to figure out how to discard those input samples as they arrive. If those, then a fixed latency could as easily be discarded with them.
Similarly, why would you want to set latency correction to -60000 ms?
Very long cables?
I wasn’t sure you were suggesting it, but a few people have complained about losing the first few milliseconds of some irreplaceable recording by overdub-append recording, starting recording after time zero.
Remember that overdub is on by default and that when starting appended-recording after zero, Audacity deletes the latency-corrected audio even if there was no prior audio, because it replaces the prior white space with silence. I could see an argument in that case for Audacity pushing the entire recorded audio backwards and then padding with silence (if it needs to), not padding immediately recording starts.
Gale
You are suggesting that the first “n” ms of audio are sent down a black hole, then start writing the data to the track, rather than writing all of the audio to the track and then (on “Stop”) send the first “n” ms to the black hole?
That would seem to be a reasonable way to do it, but probably a case of “if it ain’t broke…”