Apogee Symphony Users... 1.6 ms of latency? Hype, or the real deal?

davidmesiha wrote:
Sorry man, but the buffer size directly affects Latency and although Latency is a combination of that plus other aspect such as AD/DA converters and Drivers, at the beginning the formula

Latency = ( (IO_Buffer Size/Sample rate) * 2 ) + All other latencies introduced by drivers, AD/DA, etc..

You're not disagreeing with me. Buffer size does affect latency, but since you are adding other latencies, which could be small ones or could be huge ones, you have no idea what the total latency is at 32 sample buffer. It could be 1.6, it could be 20 ms.

iSchwartz wrote:
Of course it does! Figure 32 in, 32 out. That's 64 samples. At a sampling rate of 48K that's 1.3 milliseconds. At 44.1K it's slightly more delayed. No, that doesn't include additional A/D and D/A latency. But that small # of milliseconds is a quantifiable amount of time and it made a difference. That was the moral of my story from my previous post. In short, YES, I did the test.

You contradict yourself. First you say that you can know from the buffer size, then you turn around and say that it doesn't include other latencies (which also include drivers and firewire if that's what you're using). Which is it?

You're not saying that all boxes have the same latency at the same buffer, are you? That driver/ADA/firewire latency is the same for every box? We all know that's not true at all.

And you did what test? You tried tracking/monitoring on a system
with 1.6 ms total latency, or you tried tracking/monitoring on a system at 32 sample buffer and assumed it was 1.6 ms (which it may not have been, what audio hardware was it)?

Tests are all good and well, but have you tried tracking while monitoring through a system with 1.6 ms of latency?

Why are you asking this question? I already posted that I've had this experience, and the results.

So that's a yes? I'm asking it because I haven't seen an answer, just different examples of where you could tell small delays.

Now, to my test... If you would please perform my simple test (which I'd encourage others to do as well) and report back what you hear, then we could all speak from a place of experience instead of (potentially) coming across as a bunch of arm-chair scholars.

I did your test, and I did hear phasing at 1.6 ms. But it has no relevance to the situation of time delays between instrument and headphones, it's a completely different situation.

I AM talking about speaking from experience. In this case the experience is monitoring through a system with 1.6 ms of latency. That's why I'm asking if you have done it.

No, they're not different things. Delay is delay is delay.

They sure sound like different things to me, and I perceive the two vastly differently.

Listen to a recording superimposed on itself with a 1.6 ms delay. Then listen to playing an instrument or singing through a digital system with 1.6 ms of latency. You're honestly telling me that the two sound the same to you?

Actually do the comparison, then tell me if you still think they are the same. I just did, and the two were nothing alike.

Rohan Stevenson1 wrote:
the whole point of monitoring through software is to use software plug-ins. very likely a touch of reverb.

No need to monitor through software just to hear reverb. I monitor my direct signal via an analog mixer, and I route a software reverb plug-in into the analog mixer when I need it. Easy enough to do--I'm happy to explain more if this isn't clear.

My reason for liking software monitoring is different: convenience pure and simple. Software monitoring requires no patching, and you get instant recall on levels if you come back to something later.

Believe me, I'll be a happy guy if software monitoring ever starts sounding as good to me as analog monitoring... analog monitoring is a hassle I could certainly do without.

James

Mike,

Glad you did the test. You hear phasing. That means that something's off with the timing. It's a textbook case for just one of the anomalies that can be caused when a player can't hear themselves in time. And to the rest of the implications of the introduction of this delay, I'm NOT going to spell them out. They are self-evident. You're an intelligent guy, you think about the digital signal flow and you'll figure it out.

You've analyzed my story for flaws but at the same time totally missed the point of it, asking me "is that a yes?" in response to your question. If you can't figure that one out, well, what can I say.

Well, I've said about all I have to say, tried to present my argument based on experience and not on conjecture and armchair knowledge. I've told stories, done the math, tried to have a laugh in the midst of it all, and now I'm all typed out. So remember, kiddies, when you grow up and become an Olympic runner, where you train for years to try and beat your competitors by factors of 10,000ths of a second, don't come to me as a musician and tell me that a few milliseconds here and there don't matter.

Byeeee!

iSchwartz wrote:
Mike,

Glad you did the test. You hear phasing.

Read my post again. Listening through the headphones, I did NOT hear phasing from latency at 1.6 ms or even a ways higher than that. I did hear phasing on the track delayed within the box. They are two unrelated situations, which is obvious if you actually listen to both and hear that the two sound completely different.

Did you actually listen to both, or just the one and assume the other is the same? I did the test, why won't you do the same?

You've analyzed my story for flaws but at the same time totally missed the point of it, asking me "is that a yes?" in response to your question. If you can't figure that one out, well, what can I say.

I'm analyzing your response for an answer to the question. I asked if you have monitored/tracked at 1.6 ms, and your response was that you monitored with a buffer at 32 ms. That's not an answer to the question.

From that response, you certainly give the impression that you THINK you monitored at 1.6 ms but you actually didn't. I've tried to give you the opportunity to clear that up by telling how you knew you were monitoring at 1.6 ms, but since you won't, it just makes it look more like you probably don't understand the difference and probably made a wrong assumption about the latency you heard.

Well, I've said about all I have to say, tried to present my argument based on experience and not on conjecture and armchair knowledge. I've told stories, done the math, tried to have a laugh in the midst of it all, and now I'm all typed out.

I'd love to hear actual experience. But your delay test WAS conjecture and armchair knowledge, you listened to something completely different and made an assumption based on your conjecture. You didn't listen and compare the two to see that they are different. And you never have come out and said that you tracked/monitored at 1.6 ms latency.

It's a simple question, I don't see why you don't just answer it.

"Yes, I tracked/monitored through a system with 1.6 ms latency. I know that because the specs said so/I measured it/etc."

Mike Connelly wrote:
Read my post again. Listening through the headphones, I did NOT hear phasing from latency at 1.6 ms or even a ways higher than that.

Hey, Mike,

Did you compare monitoring your own vocal through 1.6ms of latency versus analog ?

At 1.6ms, latency doesn't sound like a phaser stomp box or anything like that, but I find that the subtle phasing makes my voice in the headphones sound quieter and duller. Without analog as a reference point, I agree that no one would likely complain about 1.6ms of latency. Did you compare with analog ?

James

hi iS,

not sure if you are reading this still...but...

first, the 'velvet ears' thing on re-reading might have sounded sarcastic, but actually it was not...i genuinely very sensitive, you can tell that in the detail of your work. plus they very likely are made of velvet which brings to mind a purple cushion with tassles. you don't wear ear-rings by any chance do you... 🙂

my point was that while your test will show that there is timing difference, a phasing, it won't tell you which sound is first and which is second - you won't be able to tell them apart. next, my point continues that the infinitesimally small increments we are talking about, you won't be able to tell that difference between air and wire (headphones and live sound). next my point continues that actually that small amount of latency may actually correct the 'aheadness' of the monitored signal against the live sound, so that they are MORE in sync than with analogue monitoring - and in most cases that will be true.

finally, somewhere you made the point that round trip will mean that the signal is recorded late by that amount, but actually that is not (supposed) to be the case (although i have my doubts sometimes). logic corrects for this by the amount of latency that is reported to it by the audio driver - at least it will with software monitoring, but not with hardware monitoring.

my suspicion is, your experiences with monitoring this way are similar to jims, in that you have attempted it when the latency was big enough for it to not be directly noticeable, but enough to affect performance. in this situation, going back to analogue monitoring makes sense. i think though, if you were blind tested monitoring A/B you would only hear a difference in sound quality, but not actually be able to say which is which.

it really boils down to whether or not we think monitoring with 1.6ms latency makes a difference to record with. i would suggest not at all - but arguing about it has been extremely fun and educational.

i have always previously monitored through my desk or through my delta (hardware monitoring), but recently just not bothered to and done it quick and dirty through logic....and it was fine. i would be dealing with greater latency than we have been occasionally discussing. so my experience why not?

however, it comes down to how it sounds - then that is a different discussion altogether.

my suspicion is, your experiences with monitoring this way are similar to jims, in that you have attempted it when the latency was big enough for it to not be directly noticeable, but enough to affect performance. in this situation, going back to analogue monitoring makes sense. i think though, if you were blind tested monitoring A/B you would only hear a difference in sound quality, but not actually be able to say which is which.

sorry an important correction: blind test symphony or PT HD against analogue.

Believe me, I'll be a happy guy if software monitoring ever starts sounding as good to me as analog monitoring... analog monitoring is a hassle I could certainly do without.

i don't think it is the monitoring that is the issue. i have been debating on the significance of the latency and i contend that at the latancies that PT HD and symphony report, it is so small as to be irrelevant.

sound - now that is a different matter. currently i still mix OTB because i cannot quite get as a good a sound ITB as i can OTB. there a number of factors that contribute to this. and monitoring OTB is effectively giving you that analogue sound that just won't go away. so you may just simply feel better about what you are hearing and responding to that and making you play better etc etc...and if that's the case - more power to your elbow says i. i could easily agree.

i just doubtful that the culprit is latency.

its relative. latency - a difference between one sound and another. which sound is early? which one is late? there is latency from the point the sound is made to the point the sound is heard through the air. you are not going to eliminate that.

Hi Rohan,

Not to gloss over your reply, but just wanted to mention one thing (it's 6AM here and I have to get some sleep). But real quick, regarding looped-back recordings that you referred to...

Unlike Cubase (which is fairly magical in the following aspect), Logic doesn't have any provision for detecting hardware latency (A/D time + driver delay) and automatically compensating for it. This is very easy to prove too:

Set your recording delay setting to zero and do a simple loopback test: patch a pair of stereo outputs to a pair of stereo inputs on your interface with patch cables. Play back a stereo track from those outputs and record them right back into Logic on another track (turn software monitoring off when you do this).

Then play back both tracks. There is a 99 out of 100 chance that your original track and your looped back track will be out of sync (late) by some amount. It could be 1 sample, it could be 10's, dozens, or 100's of samples out of sync. It all depends on your gear. The 1% chance that it won't be out of sync will likely only occur if you're using Apogee gear, because it seems to somehow communicate with Logic and adjust the incoming audio so that it is placed properly in a track.

The only way to compensate for it is to measure the timing difference. I have written about this extensively on Logic Pro Help and am at the tail end of writing up an FAQ on this and a consolidated procedure for determining the delay and compensating for it yourself. It's a really simple procedure too. Would take about 5 minutes.

Some RME systems also seem to try to compensate for hardware+driver delay and in the process they overdo it. That's why many people report that their tracks actually play back early!

Anyway, I'm dyin' over here, have to sleep. Will reply more in kind tomorrow.

...just want to add something:

Fireface 800 and Multiface record perfectly on time within Logic. I´ve tested it since V5, BUT only if you record using analog inputs, because RME´s driver know the time it takes for AD conversion and reports that to Logic. When you record a digital loopback the audio is early because the driver corrects the position using the same numbers that it uses when recording analog, but since there´s no converters delay the audio ends early in Logic. I also have a Rosetta800 which ATM I use via ADAT. If I send the same signal to both Fireface and Rosetta I hear flanging... I understand why and I use them for different instruments and never use both for something like drums. Still it´s weird to have to work like this. I´m about to use Symphony in a few weeks, but don´t expect things to be different...just expect the Rosetta sound better. RME Totalmix is excellent, but I monitor thrua console most of the time... feels better and it´s easier.

Set your recording delay setting to zero and do a simple loopback test: patch a pair of stereo outputs to a pair of stereo inputs on your interface with patch cables. Play back a stereo track from those outputs and record them right back into Logic on another track (turn software monitoring off when you do this).

software monitoring has to be on for logic to compensate for latency.

but you are right - there was no automatic correction - it only corrects for its own latency, you have to set the correction for your gear which is what the recording delay feature is for.

mine is -158 samples.

well you learn something every day...actually -162 samples. monitoring with through hardware results in it being bang on.

from the manual:

Recording Delay
This parameter allows you to delay the recording of audio by a certain fixed value,

helping you to compensate for any information delays that are caused by the audio
driver.

Note: You should not normally need to touch this parameter.

hmm but i did. presumably the info logic gets from the audio driver is incorrect. so i have no touched this parameter.

well, at least i have some sympathy for you saying that software monitoring is a crock, but not because of the inherent latency within the system for monitoring, i still maintain that for systems like PT HD and symphony it is utterly negligible, but at least from the point of view it is not transparent from the user and if you are not on it you are going to have problems.

Real quick once again (running out the door this time):

@ gpiccolini -- it's possible that your system exhibits behavior that lets you set your recording delay at zero. But this isn't true of all systems that use RME interfaces. I'm basing this statement on reports by many people who I've discussed this with in various forums. So many times a loopback test reveals that RME-recorded audio ends up early in Logic (in which case the recording delay parameter needs to be set to a positive value). Others report, like you, that they can leave it at zero.

@ Rohan -- the Logic manual has been saying that "normally you should leave this at zero" since Logic 4. And that information is misleading and basically incorrect. So the only way to tell if it should be set to a non-zero value is to do a loopback test. That will confirm if you should leave it alone or set it to compensate.

• in my brief reply above I didn't go into the details, but I recommend that when you do the test you start with a wholly blank song, PDC set to off, software monitoring off, and loop back a simple stereo recording. Then you figure out how many samples off the looped-back recording is from the original. That number is a reflection of the hardware+driver delay for your particular interface. But I'm curious as to why you think software monitoring should be set to ON for this test.

Gotta fly. Will write more when I get back.

Message was edited by: iSchwartz

... If you record a loopback via digital outs with RME hardware it shows up early, if you record that via analog it is recorded more or less 1ms late which IMO is the DA conversion time. I´ve had 2 multifaces in 3 machines with different OS and Fireface800 also in 3 machines and always get the same results. The difference is because the driver "corrects" the time it takes for the AD, but as there´s no conversion delay in a digital loopback the audio ends up early. it´s possible that other people have different results, but I´ve tested myself several times in several machines.