ORIGINAL: jt

ORIGINAL: TwentyTimesSeven
I did the loopback test with S501PE, an Edirol UA1000 and WDM/KS selected. It appeared to experience a latency of just two (2) samples at 44.1Khz/24 bit.

TwentyTimesSeven, that's impressive! I don't know of anyone else achieving that low of a difference. Perhaps someone else that has the same unit can perform a loopback test to confirm your findings.

I would like that. Not having done the test before I'd assumed that I was doing the test wrong. I switched to the ASIO drivers and got a much higher result (IIRC ~8ms). I'd be glad to do the test again and provide screen shots of my settings if anyone is interested.

20x7

ps: The above word is A S S umed.

As I see it, this should be relatively easy to fix, too: Cakewalk simply needs to add a user-configurable box that says: "Cut off the first xx.xx ms of newly recorded audio and move it to the left by that length".

I think the root of this problem is there are so many sound cards out there where the implementation isn't the same.


On my Echo layla 3g, WDM only produces a small amount of offset <2.9ms, which I can't hear. I agree with you when you say 8 ms is unreasonable.

ASIO on my Layla produces a considerably larger and audible amount of offset (it actually plays the recorded track back early.).



And someone wondered a practical reason for going out of your d/a converter and back into your a/d converter.

Sometimes people want to run their softsynths through hardware (preamps, compressors, outboard digital stuff etc).

Also for doing a stereo recording where you are using a combination of software synths and hardware synths in Sonar.




I once had this offset problem (because Echo recommended using ASIO over WDM in Sonar). I definitely think more should be done about these issues. I guess the good thing is, it keeps me from wanting to spend my money on trying out other sound cards fearing I might have an offset problem.

And I don't think manually sliding every track you just recorded in place would be a good example of Sonar's great workflow. I can see if someone was trying to create an effect or correct a sloppy performance but for general recording that is not acceptable.


It sounds like you want a perfect solution though. I would think if they could just get the offset to a minimal point (under 3ms), most people would be fine and there would definitely be less complaining.


I think this problem also hits people who do a mixture of midi and live the hardest. I ran into this problem when a guitarist (who's been playing since he was little and had good timing) couldn't lay down his part properly to my sequence. He got really frustrated, but I knew what the problem was.

TwentyTimesSeven, Thanks could you try the test again in WDM mode?

Loopback Test Instructions

Here's another thread talking about the same issue

ORIGINAL: jt

TwentyTimesSeven, Thanks could you try the test again in WDM mode?

Loopback Test Instructions

Here's another thread talking about the same issue

Hi Jt,

"WDM" is not available to me.

I did the test again. "WDM/KS" selected. I used the provided .WAV, 44.1khz/24

I got the same result: Two samples.

For the "sanity check" I disconnected the patch cord and tested again. I recorded the expected flat-line.

I think I'm doing it right.

I'm using the version 2 UA1000 drivers (not the 64bit OS drivers). Also, contrary to Sonar documentation for AUD.INI:

Use24BitExtensible=0

It has been my experience that bad things happen if this is set to 1.

I'm curious as to why others are not reporting similar performance.

Stuff: SP2, UA-1000,Ver 2 drivers, S501PE.

20x7

If you know the delay you get in terms of samples (I believe blue's was 366?), then using presets and Voxengo Latency Delay will help you correct these errors quickly. I would insert this on all overdubs and Apply FX before doing any other mixing.
Peace,

ORIGINAL: tunekicker

If you know the delay you get in terms of samples (I believe blue's was 366?), then using presets and Voxengo Latency Delay will help you correct these errors quickly. I would insert this on all overdubs and Apply FX before doing any other mixing.
Peace,

Thanks TuneKicker.

But I think I'll pass and leave well enough alone.

Two samples is the "round-trip" time. It's not a configuration I require often.

20x7

ORIGINAL: tunekicker

If you know the delay you get in terms of samples (I believe blue's was 366?), then using presets and Voxengo Latency Delay will help you correct these errors quickly. I would insert this on all overdubs and Apply FX before doing any other mixing.
Peace,

Hi Tunekicker...I was just thinking about this and think it's the other way around. I could be wrong, but here goes:

The Voxengo Latency Delay reports a delay the PDC mechanism to advance audio for VSTs that don't report their inherent latency. Applying this to overdubs would actually double the error.
But putting it on the guide tracks during the overdub, then bypassing it afterwards should achieve what you're talking about.

Probably the easiest way to do this if you've got more than a few guide tracks would be to select all guide tracks, then bounce these to a new track before overdubbing.
On the new bounce track, apply the Voxengo Latency Delay to your necessary value and monitor only this while overdubbing.
After overdubbing, mute the bounce track, and return to monitoring the original guide tracks.

I'd think creating two busses, one Master, and one Overdub Guide with their Mute buttons latched in opposite states would further simplify the process.

Egads. This is way more convoluted than I'd hoped for

.

ORIGINAL: jlgrimes
And someone wondered a practical reason for going out of your d/a converter and back into your a/d converter.
Sometimes people want to run their softsynths through hardware (preamps, compressors, outboard digital stuff etc).

That is one explanation why that delay matters, but strictly speaking, the issue occurs even with you want to do plain and simple overdubs of audio tracks - the loopback test just proves that there is a problem.

It sounds like you want a perfect solution though. I would think if they could just get the offset to a minimal point (under 3ms), most people would be fine and there would definitely be less complaining.

Who wouldn't want a perfect solution. :) Surely a small enough latency along the lines of what you have described would be acceptable, but that can probably not be achieved by Cakewalk because it is largely up to audio drivers. What could be done, however, is introduce a compensation mechanism as described earlier (essentially an auto-nudge feature for all new tracks), which would at least help those who experience a constant delay.

I think this problem also hits people who do a mixture of midi and live the hardest.

Or for anyone who needs to do overdubs of any kind.

Regards

jg