The No.1 Website for Pro Audio
 Search This Thread  Search This Forum  Search Reviews  Search Gear Database  Search Gear for sale  Search Gearslutz Go Advanced
Why is the latency for my Bricasti changing between sessions? Audio Interfaces
Old 23rd November 2016
  #1
Lives for gear
 

Why is the latency for my external FX changing between sessions?

I do everything ITB except for one Bricasti connected to my Windows 10 machine via AES through an RME HDSPe AIO. So, I'm a novice at hardware.

To synchronize the Bricasti, I'm setting Dry Gain to +1.0, Wet Gain to 0.0, and I phase invert the signal returned from the Bricasti, and I find it's delayed by 298 samples, so I accommodate for that in Reaper.

And then a few days later, I don't hear anything wrong, but I'm curious so I test again, and now the return from the Bricasti is delayed by 299 samples instead of 298. And it creeps back and forth. Hopefully not within a single session, but I'm not sure.

Why would it be creeping like this? Can I stop the creep, so I don't have to keep testing?
Old 23rd November 2016
  #2
Lives for gear
 

Generally the latency of digital hardware itself is typically fixed, however some some models can vary according to selected program/patch.. It doesn't seem to be this case though, 1 sample difference is at level of some error with offset detection, whereas program latency changes, which I've mentioned, are much more than that, because for example another module with some look-ahead, FIR filtering, oversampling is being added to the path.
Anyway, you can probably verify that with Bricasti, maybe also @ Casey can confirm that.

To avoid possible errors with detection, when you'd repeat offset test once again, then be sure to use right signal for that, the Insert>Click source from Reaper menu is a good one, IME. Uncheck the option "Use audio driver reported latency" at Preferences/Audio/Recording temporarily just for the test. Switch to sample units there and find the exact offset.
If you'll later be compensating this offset using ReaInsert, then just make sure to don't use "Automatic device latency adjustment" option. That way, it will be using just your measured offset without involvement by values reported by ASIO driver.

Also are you sure, you didn't any clocking arrangement changes in the setup, did some driver updates or don't use any effect which can possibly skew that figure by that one sample (like some plugin pre/post ReaInsert I/O).

Finally, 1 smpl. offset variation is really something significant and really looks like detection error, it's true if you blend two equal level dry signals and one will be delayed, it might form pretty nice lowpass filter, but it isn't really something you can perceive as a problem, when using outboard reverb as a send effect or as an insert with its own H/W blend control instead of ReaInsert.
Btw. when compensating some analog outboard effects, it's quite often some compromise value, not beacuse of drifting, but because of some inherent phase shifts in the chain, so final delay isn't sample aligned. Even with those case, it isn't necessarily problem.. For example I've used bus compressors in parallel fashion without any apparent problems.

Michal
Old 23rd November 2016
  #3
Lives for gear
 

Quote:
Originally Posted by msmucr View Post
Generally the latency of digital hardware itself is typically fixed, however some some models can vary according to selected program/patch.. It doesn't seem to be this case though, 1 sample difference is at level of some error with offset detection, whereas program latency changes, which I've mentioned, are much more than that, because for example another module with some look-ahead, FIR filtering, oversampling is being added to the path.
Anyway, you can probably verify that with Bricasti, maybe also @ Casey can confirm that.
I'm not assuming the M7 is what's causing the latency-changes, but I have PM'd Casey to ask him if he as ideas about this.

Quote:
Originally Posted by msmucr View Post
If you'll later be compensating this offset using ReaInsert, then just make sure to don't use "Automatic device latency adjustment" option. That way, it will be using just your measured offset without involvement by values reported by ASIO driver.
I already have been keeping ReaInsert's "Automatic device latency adjustment" option turned off. When I tried it on (long ago), it confused things even more, so now it's always off.

Quote:
Originally Posted by msmucr View Post
Also are you sure, you didn't any clocking arrangement changes in the setup, did some driver updates or don't use any effect which can possibly skew that figure by that one sample (like some plugin pre/post ReaInsert I/O).
That could be the culprit. Sometimes I add an instance of Melda Production MUtility after ReaInsert for gain adjustments. Sometimes I don't. I hadn't considered it might be adding its own latency, but I'll pay attention to that possibility now. I don't know why Reaper and MUtility wouldn't automatically compensate for that, though.

Quote:
Originally Posted by msmucr View Post
Finally, 1 smpl. offset variation is really something significant and really looks like detection error, it's true if you blend two equal level dry signals and one will be delayed, it might form pretty nice lowpass filter, but it isn't really something you can perceive as a problem, when using outboard reverb as a send effect or as an insert with its own H/W blend control instead of ReaInsert.
I understand 1 sample is a small deal when it affects only the reverb's wet return. But sometimes I set the Bricasti to return some dry signal, and I mix the return with other dry signal that hasn't been routed through the Bricasti; so 1 sample could throw things off in a bad way there. I wouldn't attempt this using analog gear, but it should be possible in an all-digital chain, I'd think.

Thanks very much for the good advice.
Old 23rd November 2016
  #4
Lives for gear
 
Casey's Avatar
 

Of course the easiest answer is don't use any dry return from the M7 and forget about it.

I have never trusted any DAW to consistently be reliable on a parallel path going out of the box. It's just one giant PIA that I decided to avoid 20 years ago. However, if you do want to diagnose the issue, I would first take the M7 out of the loop and just see what the straight wire does. I don't think that the M7 would be eating your sample, but anything is certainly possible, and I would want to know about it. So let us know!



-Casey
Old 23rd November 2016
  #5
Lives for gear
 

Quote:
Originally Posted by johnbruner View Post
That could be the culprit. Sometimes I add an instance of Melda Production MUtility after ReaInsert for gain adjustments. Sometimes I don't.
On second though, MUtility isn't what's causing the drift, because I've always taken MUtility offline during latency-testing.
Old 23rd November 2016
  #6
Lives for gear
 

Quote:
Originally Posted by Casey View Post
Of course the easiest answer is don't use any dry return from the M7 and forget about it.

I have never trusted any DAW to consistently be reliable on a parallel path going out of the box. It's just one giant PIA that I decided to avoid 20 years ago. However, if you do want to diagnose the issue, I would first take the M7 out of the loop and just see what the straight wire does. I don't think that the M7 would be eating your sample, but anything is certainly possible, and I would want to know about it. So let us know!



-Casey
Thanks for the advice. Taking M7 out of the loop is a good idea. I hadn't realized I could try that without short-circuiting everything, but yeah I guess I can.

I'm obsessed with this sample now and don't want to give up on diagnosing it. Plus, it's actually very useful for me to be able to mix dry-return from the M7 with unrouted dry. It's not necessary in theory, but in practice it streamlines my mixing workflow.
Old 25th November 2016
  #7
Gear Nut
Quote:
Originally Posted by johnbruner View Post
Plus, it's actually very useful for me to be able to mix dry-return from the M7 with unrouted dry. It's not necessary in theory, but in practice it streamlines my mixing workflow.
I am not familiar with Reaper but can't you bring (easily) the Bricasti back in on its own fader ?
Old 25th November 2016
  #8
Lives for gear
 

Quote:
Originally Posted by bulldozer1984 View Post
I am not familiar with Reaper but can't you bring (easily) the Bricasti back in on its own fader ?
I'm sorry, but I don't understand your question. Can you give more detail to what you have in mind?

I like to have a Dry / Wet mix returning from the M7, and I additionally like the ability to mix in additional dry signal to that. That way, my workflow is like mixing a room mic (capturing both direct signal and room-reflections from all instruments) and also close mics (capturing just individual direct signals). In other words, instead of adjusting sends to the M7 I'd rather have a simple way to adjust Dry for individual instruments, without altering the Wet.

I did just think of an easy way I could keep the Dry return from M7 at 0: By sending the dry signal right before the M7 to it's own bus in Reaper and then summing that bus with the all-wet output from the M7.

But I'm still curious where this latency drift is coming from. Mostly I'm curious whether it's user-error or Reaper error. It's the kind of thing Cockos would want to fix, if it's an error in their DAW. Or if it's something I can control myself, I'd like to learn how.
Old 26th November 2016
  #9
Gear Nut
Quote:
Originally Posted by johnbruner View Post
I'm sorry, but I don't understand your question. Can you give more detail to what you have in mind?
What I mean is creating a bus that only has the Bricasti on it. Then you can blend the completely wet signal back into Reaper which will not cause any phase issues if you have a mis-alignment.

In Studio One, I simply create a bus that only has one element on it which is a send and return to the piece of outboard gear. Then you simply blend in the effect to taste via the bus' channel fader.

It is so much easier than trying to balance wet/dry on the actual piece of hardware.
Old 26th November 2016
  #10
Lives for gear
 

Quote:
Originally Posted by bulldozer1984 View Post
What I mean is creating a bus that only has the Bricasti on it. Then you can blend the completely wet signal back into Reaper which will not cause any phase issues if you have a mis-alignment.

In Studio One, I simply create a bus that only has one element on it which is a send and return to the piece of outboard gear. Then you simply blend in the effect to taste via the bus' channel fader.

It is so much easier than trying to balance wet/dry on the actual piece of hardware.
I won't be satisfied with randomly drifting latency, unless it's necessary for some reason. It is 2016. The number 298 should not magically turn into the number 299 in an all-digital chain. If there's a reason for the drift, it should be documented.
Old 26th November 2016
  #11
Gear Nut
Quote:
Originally Posted by johnbruner View Post
I won't be satisfied with randomly drifting latency, unless it's necessary for some reason. It is 2016. The number 298 should not magically turn into the number 299 in an all-digital chain. If there's a reason for the drift, it should be documented.
You need to stop mixing with your eyes. If it sounds good it is good. If it sounds **** it is not because your Bricasti is 1 sample off out of 300. It is because you need more mixing skills.

WOW
Old 26th November 2016
  #12
Lives for gear
 

Quote:
Originally Posted by johnbruner View Post
I won't be satisfied with randomly drifting latency, unless it's necessary for some reason. It is 2016. The number 298 should not magically turn into the number 299 in an all-digital chain. If there's a reason for the drift, it should be documented.
Hmm..

just for my curiosity I've tested AES/EBU digital loop at HDSPe AIO, which I have at home.
With no effects inserted (just plain in to out XLR patch) and internal clocks of the card I've had consistent 293 samples roundtrip delay. I had 128 samples ASIO buffer and the delay was the same for both 48 and 44.1k. I've tested that with Reaper 5.28, where it was detected by ReaInsert automatic pinging through I/O and verified also by recording click track and manual measurement using time selection. The same figure was detected also externally by Oblique RTL utility. All was perfectly aligned.
I've also tested TotalMix loopback, where audio is routed back directly at DSP mixer.. it was always 3 samples less than AES/EBU loop regardless of working sample rate.

It says the same no matter which project I was using or how taxed CPU was.. It's pretty lowly computer, but it was consistent also when I had 85% of CPU and couple of correctly latency compensated plugins before or after HW insert.

For the completeness, I'm using Windows 7 there and the latest unified 4.16 HDSPe driver.

I don't think, there is some specific technical reason why it should necessarily drift or that there is something necessary to document.. That's also why some measurement error was the first thing, which come to my mind. But maybe there's is also some other problem, which affects the setup.

Anyway, even if there will be possible one sample uncompensated offset, I really don't think, it would have so significant impact to the workflow. I generally use
most of outboard reverb effects 100% wet and its own return channel at DAW.
Reverb wet signal is being inherently delayed, so it likely won't be perceived as significant difference at overall mix of dry source and wet return.
Also possibility to enter the offset with one sample precision isn't completely standard feature among DAWs.. lot of other programs has adjustment for example to hundreds milliseconds, which is much rougher than samples and still it's being used for inserts like that.

Slight off topic.. reasoning with the years like - it's 2016 (2017, 2006 or so), so it should work some imaginary way.. seemed to me quite silly in similar discussions. Because it just steer from technical points and possible solutions of the issues and moves everything to some emotional/marketing feeling.

Michal
Old 26th November 2016
  #13
Lives for gear
 
JayTee4303's Avatar
The computer is consistant. It doesn't add processing cycles to machine code manipulation, willy nilly, this time and not that. Even at Assembly level, an ADD or MOV is going to take this many clock cycles today, tomorrow, 100 years from now.

What isn't consistant, is the OS...the software... you, and the interaction between all this. How often does the OS poll the keyboard to see what you've typed recently? Mouse? Ram refresh? NIC?

How does this timing relate to and interact with your chosen sample rate?

(I am discussing this loosely, mixing simple and complex concepts, both accurately and symbolically, to make a point, don't take any but the overall concept to the bank.)

Do this.

Lose the M7. Pipe...vox...out the box. Bounce it out onto the internet...with IP, some will pipe thru your local ISP, some packets thru Guam and Borneo...until BOTH users in Borneo check Compuserve at once...

Now mix that in with your original vox track.

What's going to happen?

Realizing this...why would you EVER do this...unless you wanted precisely this random phase mess, as an interesting effect?

If you DID want it as an effect, why not just use multiple delay lines, so as to exercise control...if one monkey in Borneo climbing a power line after bananas brings down their grid, what happens to your production schedule? LFO the delays or code a random number gennie into the chain for kicks?

Well, because you want the ability to mix dry and wet, sure...good idea.

Keep the dry in the box.

Send the wet out for processing.

Keep a close eye on the dry, even corralled. The uncertainties outlined above aren't limited to external I/O busses in the PC.

If you HAVE to send out the dry, process it all, and lose the old, unprocessed dry. Nudge as needed.

The user doesn't have to wrestle with them as much as in the past, but...they are called "interrupts" for a reason.

:-)
Old 26th November 2016
  #14
Lives for gear
 

Quote:
Originally Posted by JayTee4303 View Post
Pipe...vox...out the box. Bounce it out onto the internet...with IP, some will pipe thru your local ISP, some packets thru Guam and Borneo...until BOTH users in Borneo check Compuserve at once...
Since that's your standard, remind me never to use gear you've developed.

Quote:
Originally Posted by JayTee4303 View Post
The user doesn't have to wrestle with them as much as in the past, but...they are called "interrupts" for a reason.
If you want to learn how to write sample-accurate code on systems with interrupts, there are people who can help you. If you want that, you'd have to ask the people, "please teach me how you did it", instead of lecturing them: "It can't be done."

Quote:
Originally Posted by msmucr View Post
Slight off topic.. reasoning with the years like - it's 2016 (2017, 2006 or so), so it should work some imaginary way.. seemed to me quite silly in similar discussions. Because it just steer from technical points and possible solutions of the issues and moves everything to some emotional/marketing feeling.
I meant it ironically. People who say "it's 2016" are annoying. Thanks for the stats about your RME card.

I'm going to figure out the source of the latency drift. There could be a million people on Gearslutz telling me not to figure it out, but I'm going to ignore all that and figure it out anyway; these are the people who protested when DAWs started providing plug-in delay compensation. I'm not asking, "is it okay for me to you use my gear differently than you use yours?" I don't care about anyone's answer to that. Signing off for now, looking forward to reading more complaints from gear-cops when I return.
Old 26th November 2016
  #15
Lives for gear
 

Quote:
Originally Posted by johnbruner View Post
I meant it ironically. People who say "it's 2016" are annoying. Thanks for the stats about your RME card.
Cool

Quote:
Originally Posted by johnbruner View Post
I'm going to figure out the source of the latency drift. There could be a million people on Gearslutz telling me not to figure it out, but I'm going to ignore all that and figure it out anyway; these are the people who protested when DAWs started providing plug-in delay compensation. I'm not asking, "is it okay for me to you use my gear differently than you use yours?" I don't care about anyone's answer to that.
I'm not saying you shouldn't try to discover the source of that.. I've mentioned that just, it isn't necessarily so important for the practical results.
Anyway, I'd try to do mentioned test without any outboard hardware, just for the test of audio interface and DAW environment.
I believe, consistent latency can be achieved and with high quality card like RME, proper clocking setup and all digital connections.
We have also similar setup with TC6K and HDSPe AES in secondary room.. I've done DAW setup there year ago or so.. older Samplitude 11 and also Reaper (some not so recent 5.x version), definitely it wasn't drifting, when I've done presets with outboard latency compensations.
Although we don't use dry/wet there.. it's meant for mastering, where the chain is more or less fixed and possible parallel blending is done directly at TC or at analogue chain via insert switcher with its own blend knob.

Michal
Old 26th November 2016
  #16
Lives for gear
 

Quote:
Originally Posted by msmucr View Post
Anyway, I'd try to do mentioned test without any outboard hardware, just for the test of audio interface and DAW environment.
It's in progress. The latency-creep is sporadic, so it will take days to test; unless I detect latency-creep sooner. Initial latency without the M7 is 293, like you get, but I'm using Win 10.
Old 4th December 2016
  #17
Lives for gear
 

With the M7 out of the loop, I tested at least 20 times over 4 days, and the latency stayed fixed at 293. It's still possible M7 isn't the cause, but it seems likely to me now.

If the latency drift was caused by Reaper or RME, I'd strongly hope they'd fix it. (If it was Microsoft, I'd give up altogether).

If it's the M7, I'll leave it to Bricasti to decide what's worth their time to investigate. I'm holding onto this M7 in any case, all things considered.

For the normal case, where M7 returns wet signal only, I understand that 1-sample drift isn't perceptible in the time-domain -- unless it happens in the middle of playback or rendering, in which case it could cause an audible click. (I haven't noticed any such clicks in practice.)

Still I wonder whether the frequency-domain consequences of 1-sample drift could be perceptible. A prominent early reflection summed with the dry signal causes a comb filter (a desired effect in the case of reverb). A 1-sample change in the time between the dry and early reflection will change the spacing of the comb's teeth, maybe perceptibly.
Old 4th December 2016
  #18
Lives for gear
 

it has to be your daw or interface. my M7 has no latency.
Old 4th December 2016
  #19
Lives for gear
 

Quote:
Originally Posted by johnbruner View Post
With the M7 out of the loop, I tested at least 20 times over 4 days, and the latency stayed fixed at 293. It's still possible M7 isn't the cause, but it seems likely to me now.

If the latency drift was caused by Reaper or RME, I'd strongly hope they'd fix it. (If it was Microsoft, I'd give up altogether).

If it's the M7, I'll leave it to Bricasti to decide what's worth their time to investigate. I'm holding onto this M7 in any case, all things considered.

For the normal case, where M7 returns wet signal only, I understand that 1-sample drift isn't perceptible in the time-domain -- unless it happens in the middle of playback or rendering, in which case it could cause an audible click. (I haven't noticed any such clicks in practice.)

Still I wonder whether the frequency-domain consequences of 1-sample drift could be perceptible. A prominent early reflection summed with the dry signal causes a comb filter (a desired effect in the case of reverb). A 1-sample change in the time between the dry and early reflection will change the spacing of the comb's teeth, maybe perceptibly.
Hmm.. hard to say, why did you experienced those small discrepancies in previous RTL measurements.
Frankly I'm bit skeptical, Cockos guys or anyone could address the issue, which isn't possible to replicate.. At least I've failed with that at my both setups with RME HDSPe cards, it's constant no matter what I do (I'd say fortunately, it's working as expected ).
I have rather extensive experience with different audio interfaces and DAWs from all price levels and apparent drifting (typically bit more than 1 smpl.) is usually issue of some cheaper USB/FW external interfaces. And also the reason, why I prefer to use those well regarded and proven RME or Lynx devices for more critical use.

With regards to perceptibility of blending with the signal, which is one sample off.. it can be really subjective and material dependent. As I wrote, equal blend of dry signal with the delayed one by 1 sample will form low pass filter.

Although I wouldn't guess, it will be so dramatic with real-world use of reverb. It will be much more critical for some parallel dynamic processing or so IMO/IME.
You can certainly try it for yourself either by the manual entry of "off values" to Reainsert or by playing with Delay/time_adjustment effect in Reaper, where you can enter both positive and negative (handled by DAW latency compensation) sample offset to any track.

If you really would like to avoid that under any circumstances, then using M7 as an bus insert effect and blending at hardware, will put any possible roundtrip delay drifting out of equation.
Of course, the dry/wet blending at DAW will give you another options for the automation etc.
I don't have a M7, but it can be somewhat improved by the external MIDI control of the unit from a plugin by Exponential Audio.. that's might be also great addon as you can have full recall of the setup from DAW project.

Aside from that plugin, M7 doesn't have typical MIDI CCs mapped to dry wet gain parameters AFAIK (or I haven't found that). I'm guessing it's likely done by SYSEX messages..
If Casey could share some details about those individual messages, it would be also pretty easy to write rather simple Reaper JS plugin, which will have one automatable slider, spitting out those constructed MIDI messages for the blend control.

Quote:
Originally Posted by trevon View Post
it has to be your daw or interface. my M7 has no latency.
That's wrong.
It has to have some latency.. albeit it can be very small.. like couple of samples, at the end it's a box with DSP processor, digital audio receiver and transmitter.. all that just take some time for passing of the samples through, even if you don't want to do any particular effects there (dry signal).
If analogue connections will be used, then an additional delay for the conversion (say 1ms for both directions depending on used chips) has to be counted as well.
In this particular case with digital I/O, it's 6 samples.. straight loopback delay with AES at RME card is 293 samples and reported M7 loopback is 299 samples in total.

But that wasn't really the point, we talked about possible drifting and relative change of that total delay.

Michal
Old 4th December 2016
  #20
Lives for gear
 

Quote:
Originally Posted by msmucr View Post
At least I've failed with that at my both setups with RME HDSPe cards, it's constant no matter what I do (I'd say fortunately, it's working as expected ).
For your loopback tests, have you used ReaInsert configured like this?



Quote:
Originally Posted by msmucr View Post
equal blend of dry signal with the delayed one by 1 sample will form low pass filter.
I understand that; and more generally, if I run M7 at Dry 0, Wet 100%, my non-processed dry signal summed with an early reflection from the M7 Wet will form a comb-filter. This comb is by design (real rooms do it too), but if the time-offset between dry and early-reflection drifts, the comb-spectrum will change.

Quote:
Originally Posted by msmucr View Post
You can certainly try it for yourself either by the manual entry of "off values" to Reainsert or by playing with Delay/time_adjustment effect in Reaper, where you can enter both positive and negative (handled by DAW latency compensation) sample offset to any track.
Good idea.

Quote:
Originally Posted by msmucr View Post
If you really would like to avoid that under any circumstances, then using M7 as an bus insert effect and blending at hardware, will put any possible roundtrip delay drifting out of equation.
I understand; but a fixed dry/wet ratio for all tracks isn't how I'm doing things.
Old 4th December 2016
  #21
Lives for gear
 

Quote:
Originally Posted by johnbruner View Post
For your loopback tests, have you used ReaInsert configured like this?
Yep. That's how I set that after I've found the offset.. then I've recorded output of that track and checked its alignment to the source.
The same value, which I've found manually (recording with globally disabled audio interface latency compensation), is being detected by automatic pinging in ReaInsert.. or at Oblique RTL utility. Samplitude 11 always uses the reported value from ASIO driver (which is off for AES loop, because it can report only single value, which applies to analog I/Os in this case), so there is necessary to enter relative value, otherwise in total it's also 293.
Then I've tried that with Reaper and different projects (heavy load, light load, VIs, additional insert effects in front or before ReaInsert.. etc.).


Quote:
I understand that; and more generally, if I run M7 at Dry 0, Wet 100%, my non-processed dry signal summed with an early reflection from the M7 Wet will form a comb-filter. This comb is by design (real rooms do it too), but if the time-offset between dry and early-reflection drifts, the comb-spectrum will change.
I also understand that, but further expanding about your perceived difference with particular reverb patches and the particular mix is different story.
It's already quite academic discussion Just try that, I'd bet it won't be anything critical in this case. YMMV

Quote:
I understand; but a fixed dry/wet ratio for all tracks isn't how I'm doing things.
Neither me. This would be just another option, if you really want the exact same blend for a single track or bus (like all vocals) without any possible dry/wet offset.
Couple times (It's not common), I've used reverb for whole 2 track mix, when some material was delivered or recorded live to stereo, I haven't access to
individual tracks, so global reverb was the only options.
I wouldn't do that during normal mixing, because for outboard reverbs I usually use just AUX tracks. In many cases I don't bother with RTL compensation at all (eg. just sending output from that AUX outside and returning it back), it works there just as fixed pre-delay.. Maybe it's just leftover from previous DAWs or mixing consoles.. So send something in, fiddling with knobs, until I like that and move on

Michal
Old 4th December 2016
  #22
Tui
Gear Guru
 
Tui's Avatar
Quote:
Originally Posted by msmucr View Post
I believe, consistent latency can be achieved and with high quality card like RME, proper clocking setup and all digital connections.
I use a RME Digiface/PCIe. I've tested latencies with my TC M3000 and also Eventide Eclipse. I hardly ever got the same latency figures for different sessions, the numbers were similar but ultimately unpredictable. That's with Logic X.

I don't know what is causing this.
Old 4th December 2016
  #23
Lives for gear
 
Casey's Avatar
 

Quote:
Originally Posted by johnbruner View Post
Still I wonder whether the frequency-domain consequences of 1-sample drift could be perceptible. A prominent early reflection summed with the dry signal causes a comb filter (a desired effect in the case of reverb). A 1-sample change in the time between the dry and early reflection will change the spacing of the comb's teeth, maybe perceptibly.
Its a good question because all other reverbs will create the comb filtering you are talking about.

But one of the things that sets the M7 apart, is that it does Not create comb filtering when Early Reflections are mixed with the Dry signal. It just does not happen, so no worries in that regard.



-Casey
Old 4th December 2016
  #24
Lives for gear
 
JayTee4303's Avatar
Quote:
Originally Posted by Casey View Post
Its a good question because all other reverbs will create the comb filtering you are talking about.

But one of the things that sets the M7 apart, is that it does Not create comb filtering when Early Reflections are mixed with the Dry signal. It just does not happen, so no worries in that regard.





-Casey
!!
Old 4th December 2016
  #25
Lives for gear
 
JayTee4303's Avatar
Quote:
Originally Posted by johnbruner View Post
Since that's your standard, remind me never to use gear you've developed.


If you want to learn how to write sample-accurate code on systems with interrupts, there are people who can help you. If you want that, you'd have to ask the people, "please teach me how you did it", instead of lecturing them: "It can't be done."


I meant it ironically. People who say "it's 2016" are annoying. Thanks for the stats about your RME card.

I'm going to figure out the source of the latency drift. There could be a million people on Gearslutz telling me not to figure it out, but I'm going to ignore all that and figure it out anyway; these are the people who protested when DAWs started providing plug-in delay compensation. I'm not asking, "is it okay for me to you use my gear differently than you use yours?" I don't care about anyone's answer to that. Signing off for now, looking forward to reading more complaints from gear-cops when I return.
Not telling you what can or can't be done. Or designing gear. Or asking anything.

I'm telling a self professed "hardware novice" how to A: avoid an audio issue, and B: where NOT to look...in 2016.

And C...possibly...where TO look, by extension.

Your data set as published here is by no means conclusive, but it does suggest possibilities, to wit...straight wire not drifting, yet...M7 plus or minus 1 sample, infrequently.

What seemed to be rejected as "hardware police" activity from my earlier post is that the drift is not at the register level, pushing it up from there, past assembly, at least to interupt or even OS level.

I admit leaving room for interpretation , and stated as much, for the benefit of a "novice". As you point out, sample accuracy is possible, which further restricts the realm of possible solution.

I'd pull back out, and get a solid feel for PLL mechanics, and some background in chase sync, if you haven't already.

With that in hand, and additional data from your straight wire accumulated by then, I've got a feel for what you'll arrive at eventually.

When (if) so...I expect you might be stunned to re-read certain notable contributions to this thread...both for what is...not...stated...and then later, for what IS.

As am I.
Old 4th December 2016
  #26
Lives for gear
 
Casey's Avatar
 

Hi John, I think you are on to something. A straight cable vs M7 does not lie. The computer can't know an M7 is there vs pure copper!

So when you do this the M7 is always 100% dry with 0% wet I believe right?

You are right, if it were moving a sample during play, you would hear a click as long as it wasn't masked. You could try some pure tones from a keyboard to make sure though.

Are you absolutely sure that your hardware and driver is not placing any sample rate conversion in the path. I have seen this many times but I think you would have eliminated that possibility at this point.

If you never hear any clicks and it does not change during actual use, then it sounds like its something in the measurement itself that the M7 is throwing off. Of course in steady state there is always audio running through the loop so I am not sure what start up condition might cause it, as there really isn't a start up condition at the hardware or driver level. You got me on this one. I have never seen it over the years, and the hardware has no variability in steady state.

But given how you want to use the device it sounds like a real problem. I'm sorry there is not an answer for it from me though.



-Casey
Old 4th December 2016
  #27
Lives for gear
 

@ Casey

I have almost exactly the same setup like John.. with Reaper DAW and RME HDSPe AIO. Also our latency figures with straight AES loopback are the same. I've also tried that result consistent with different programs.
There's definitely no rate conversion or any sample mangling, which would alter PCM data or cause some variable delays in the path. (both was tested before, because this HDSPe AIO is at my development/testing rig and second HDSPe AES is being used at mastering room).

Michal
Old 5th December 2016
  #28
Lives for gear
 

Quote:
Originally Posted by Tui View Post
I use a RME Digiface/PCIe. I've tested latencies with my TC M3000 and also Eventide Eclipse. I hardly ever got the same latency figures for different sessions, the numbers were similar but ultimately unpredictable. That's with Logic X.

I don't know what is causing this.
Interesting. Thanks.
Old 5th December 2016
  #29
Lives for gear
 

Quote:
Originally Posted by Casey View Post
Hi John, I think you are on to something. A straight cable vs M7 does not lie. The computer can't know an M7 is there vs pure copper!
Maybe there's inconsistency during the hand-shaking phase when I'm powering up M7 and/or my PC? I don't understand AES protocol enough to know if that's a possibility.

Quote:
Originally Posted by Casey View Post
So when you do this the M7 is always 100% dry with 0% wet I believe right?
Yes. To synchronize, I set M7 100% dry, 0 wet. I ask ReaInsert (a feature in Reaper) to ping and suggest what the latency is. When my audio interface and Reaper are running at 48K, ReaInsert makes the best suggestion (298 or 299, depending on some unknown factor). At higher sample rates, ReaInsert sometimes guesses wrong, but gets me in the ballpark.

Once ReaInsert has made its suggestion, I null-test the source signal against the return from the M7, manually adjusting latency +/- a few samples. I always find one particular latency at which they null down to -132 Db, and that's how I measure the latency. (I find the -132 Db noise is present also when M7 is out of the loop.)

Quote:
Originally Posted by Casey View Post
Are you absolutely sure that your hardware and driver is not placing any sample rate conversion in the path. I have seen this many times but I think you would have eliminated that possibility at this point.
I have tried to eliminate that possibility. Maybe not succeeded, but tried.

Quote:
Originally Posted by Casey View Post
If you never hear any clicks and it does not change during actual use, then it sounds like its something in the measurement itself that the M7 is throwing off. Of course in steady state there is always audio running through the loop so I am not sure what start up condition might cause it, as there really isn't a start up condition at the hardware or driver level. You got me on this one. I have never seen it over the years, and the hardware has no variability in steady state.
I'm going to try a new test. I'll measure the latency when I start my DAW, and I'll re-measure it before I shut down the DAW. If the latency stays consistent within each DAW-session for a week, I'll have gotten the control I want over the latency, and I'll just have to make it a practice to re-measure latency each time I start my DAW. That would eliminate all the practical problems I'm looking at.
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Forum Jump
Forum Jump