ORIGINAL: xackley

How on earth can you judge any real life input at a time level of 10ms or less. No one could accurately hit a cymbal or a drum within 10ms of accuracy. If you can supply a picture of 10 bars of human input that is always exactly 5 ms late I might believe it.
Then I would want to see the picture of them play back to the track create, to see if that track was an additional 5ms late. Then I would wonder if it was them waiting for the original to trigger the hit.

We need an atomic clock synced to Sonar and a sound generator to know if sonar is correcting for INPUT latency.
Don

10ms is noticable if input monitoring is enabled. It's percieved as a lack of responsiveness, or even by some a touch late. And, on his system, each consequitive track is coming in 300 samples later. That becomes a big deal if you're laying down many tracks sequentially.

Is this input latency, or is output latency though?

Let's not start saying that 640kb is enough for anybody now... some of us have a valid need for low latency and accurate clocks.

Well,

I am among the people who complained about this state of fact. As I began recording in 1981 (on analog machines needless to say), I saw the arrival of digital audio recording ( since the ADATs) as the end of big corporate studios supremacy and a democratization of the studio creative process... I made my musical and artistic living out of the big cities, enjoying raising my family in a peacefull environnment (I am not a new-ager... don't worry !).

This problem just started to be really frustrating since Sonar... All ryhtmic figures, polyrythms etc. were hopelessly trashed in a sea of imprecision randomly generated. I had to compensate by ear, most of the time. Believe me : it comes to a point where you don't know what to trust and the feel of the moment can be perceived as wrong the next time you listen to the same project...

As I cannot see any solution in the DAW realm for the moment, I remain surprised to hear NO LAG when I make use of my old ADAT 32 track system... They make use of AD/DA conversion as well, you know ? Not very different of the card based systems many of us are using... I am dealing with the idea of getting back to hardware recording system with some basic éditing capabilities... and then... make use of the DAW for finishing... That would be more reliable on long term projects.

The daw-only usage would be restricted to short productions like Jingles etc...

I suppose that we have reached the limits of this process for the moment. When some has to rely on turnarounds to pass over an issue THIS BIG, and that companies cannot address the problem, this is because we have reached the technical limits of current technology.

My two cents, anyway.

Hello Jan !

No Hammer at home ? (Jan Hammer...)

Well... the routine you are suggesting seems to be the obvious solution or inspiration for a solution. This said, my own measurements evidenced a fact that could be problematic... Some users claim to have a predictable amount of samples to offset (366 for some Motu users...) Those are happy guys (and gals), indeed.

In the few threads I've been in for that matter, the results were inconsistants, to say the least. My own results may vary impressively for the same tests (the loopback test), depending of... I don't know. I've been in the computer music since the Apple ll... I remember that the Roland U and D synths lines were doomed with 25ms of delay from the keyboard triggerring and the effective audio output rendition. In sequencer playback situations, these machines could not produce an 8 notes chords vertically. It was always a very fast succession of notes, one after one.

That was the state of the art at this time.

For example :
The setup at the studio make use of my 4 Adats as the converters. Thus, no AD/DA process occurs inside the computer. Do you agree ? Everything is routed to the DAW via Lightpipes (at lightspeed...) to a Dakota/Montana pair of cards where no audio is processed : only bits of digital data. So, I am dubious about the AD/DA lag controversy as the ADATS themselves are immune to this behavior. My guess is more that the PROGRAM has to make an interpretation of the data and to timestamp it's audio. That is this process that could be more robust. Also, I have migrated from Win98 to Win XP at the end of 2004... No WDM, etc under Win98se... but no delay ? I just noticed this behavior in SONAR 2 once I had ported everything under Win XP. Never before have I suspected this behavior and I work with these machines 7 days a week. This has been consistently repeated for other Sonar incarnations since then.

I must also add that I have a very long experience in beta testing for software companies... and that I have been implied heavily into the AcXel Resynthesizer development and... failure, from 1988 to 1992. I've seen limitations in all these areas. These were not bugs but physical limits induced by technology.

Finally, you are right about the fanatics of bit depht and sampling frequencies... As a record producer, no one has ever refused to play or buy my products based on the fact that it was recorded in 16 or 24 bits at whatever sampling frequencies... but many computer musicians seem to be ignorant of that basically unbearable musical constraint : the inherent lagging of DAWS.

Wild...

Jean-Pierre Pineau
Québec Canada

With Kernel Streaming (WDM/KS) and a quality sound card and S501PE is this even an issue?

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.

20x7

ORIGINAL: TwentyTimesSeven
With Kernel Streaming (WDM/KS) and a quality sound card and S501PE is this even an issue?

I must admit that I haven't tried a loopback test with Sonar 5.0.1 yet but when I tried it in 4.0.4 with my current USB-audio interface (BCA2000), the delay was about 9ms, which is not exactly negligable. This was with ASIO drivers - interestingly, WDM/KS was worse.

@Jean-Pierre: Seeing you have reported varying results, finding a universal solution may not be as easy as I thought it might be. Sorry to hear that.

For those of us who experience a constant delay, though, a quick fix according to what I suggested earlier, would be very welcome.

Jan

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.

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

Loopback Test Instructions

Here's another thread talking about the same issue

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,

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

.