Cue mix latency correction in P16 system

[JB Berg]

Hi,


I run the headphone mixes directly from the interface outputs to a Behringer Powerplay P16 system. It sends the channels to each P16M headphone mixer digitally over ethernet cable. 

I've noticed that it's really hard to exactly sync the click track from MB with the recorded signal. After all, the audio calibration in Audio/midi setup doesn't do the cue mix round trip.


What do you guys do to correct this?


cheers,

Janne

 
https://www.dropbox.com/s/jvx4jcm5zzb3yn...K.jpg?dl=0

[JamieLang]

You make the audio calibration (in audio midi set up) FROM the headphones as output....ADC as input. You have to plug the loopback cable in--you use the ADC as input and one of the analog headphone outs as output.

Much like I use my Burl ADC as input (it's more latent than my RME's ADC)...and the RME output (which is what feeds my analog cue)....

Should be just a matter of plugging the cable into the whole/right signal flow.

[JB Berg]

You make the audio calibration (in audio midi set up) FROM the headphones as output....ADC as input. You have to plug the loopback cable in--you use the ADC as input and one of the analog headphone outs as output.

Much like I use my Burl ADC as input (it's more latent than my RME's ADC)...and the RME output (which is what feeds my analog cue)....

Should be just a matter of plugging the cable into the whole/right signal flow.

Thanks Jamie.

I was hoping this is the answer as it's the simplest one, but when I try this I just get the inverted/bad wiring error.
It's probably something in my routing that I have to sort out.

I've gotten the best accuracy when typing in a guesstimation based on the normal calibration and recording the click track from the headphones.

[JB Berg]

You make the audio calibration (in audio midi set up) FROM the headphones as output....ADC as input. You have to plug the loopback cable in--you use the ADC as input and one of the analog headphone outs as output.

Much like I use my Burl ADC as input (it's more latent than my RME's ADC)...and the RME output (which is what feeds my analog cue)....

Should be just a matter of plugging the cable into the whole/right signal flow.

So, I've still not been able to resolve this issue. If I run the calibration from the headphone ouputs I get an inverted/bad wiring error (if I invert polarity it does not work either).

I've tracked a bit in Logic now because it can record a full session at 64 buffer size (great!) and I don't have to consider latency much. In mixbus I can realistically only do 512 before I get clicks and pops (buu). So calibrating correctly is crucial on overdubs, reamping etc. 

[madmaxmiller]

Just thinking, you play out the click track through the interface into the P16 - so your talents should be sync. Now, just use one of your inputs to record the click track together with the actual tracks through the interface and you should be locked. (make sure not to create a feedback loop in the click path though)
MMM

[JamieLang]

JB Berg

So, I've still not been able to resolve this issue. If I run the calibration from the headphone ouputs I get an inverted/bad wiring error (if I invert polarity it does not work either).

I've tracked a bit in Logic now because it can record a full session at 64 buffer size (great!) and I don't have to consider latency much. In mixbus I can realistically only do 512 before I get clicks and pops (buu). So calibrating correctly is crucial on overdubs, reamping etc. 

Sorry to hear it's not working, but as an FYI--you are NOT running a whole session at 64samples. You're running it at likely 2048. The chosen buffer size in Logic ONLY applies to the armed input and any DSP it uses via it's routing. I've long said this is a functional issue with Mixbus. Is what it is, but it's important to understand how different apps buffer so you can better get at the difference. It's not that Logic can run your whole session at 64samples...it's that it doesn't.   Cubase, Logic, and Studio One all have secondary buffers to achieve low latency on an input. They all implement them differently--so Logic at 64/LargeProcess has similar input latency to Cubase at 256 and ASIOGaurd ON....Studio One is the most transparent, allowing the user to specify BOTH settings: input and playback buffers. Regardless--Mixbus has none of the above, it's a single buffer system-like "most DAWs". Also--Logic is not properly compensating for the Berhinger...it will compensate for the audio interface latency only. Maybe the lower scale of error (64 samples vs 512) makes that less immediately apparent, but you DO need to find out how much the cue system adds and put that in as a manual additional offset.

Are you hearing the high pitched noise IN the headphone system when you press "test"? Is there metering on it you can see spiking? The only time I've had the bad wiring message is when it wasn't actually making it due to some routing on the interface. If you can't hear an ugly sound in the headphone unit...it's not making it there...I don't see what interface you're using...you say "over ethernet"...does that mean your audio interface has an AVB or Dante network on it for the Powerplay? I'd be looking at the interface mixer while you press "test"--make sure the sound leaves Mixbus and gets to the interface mixer--then check IT'S routing to make sure that is being sent to the Berhinger...then analog cable from Berhinger back to an input on the audio interface...and again check that mixer to make sure the return is making it back to the interface. It might be causing a feedback loop in there that might be why it's giving the bad signal message.

But, also, you can manually do the click thing...measure how much time the Berhinger adds...you might go ahead and do that because Logic doesn't HAVE a utility to test like Harrison does...so, you'll need to know what it's adding for Logic's engine.

[JB Berg]

Just thinking, you play out the click track through the interface into the P16 - so your talents should be sync. Now, just use one of your inputs to record the click track together with the actual tracks through the interface and you should be locked. (make sure not to create a feedback loop in the click path though)
MMM

Thanks for the input madmaxmiller.
I'm a little dim, I know, but how would I set this up in practice?

If I track say a drummer and a guitarist, without a click, and then want to track a bass player and a second guitarist. How do I make sure the recording is perfectly in sync with the original tracks playing through the headphones?

What I've done is I've recorded the click by miking a set of headphones and adjusted latency so that the recorded click aligns with the click playback.

[JB Berg]

Sorry to hear it's not working, but as an FYI--you are NOT running a whole session at 64samples. You're running it at likely 2048. The chosen buffer size in Logic ONLY applies to the armed input and any DSP it uses via it's routing. I've long said this is a functional issue with Mixbus. Is what it is, but it's important to understand how different apps buffer so you can better get at the difference. It's not that Logic can run your whole session at 64samples...it's that it doesn't.   Cubase, Logic, and Studio One all have secondary buffers to achieve low latency on an input. They all implement them differently--so Logic at 64/LargeProcess has similar input latency to Cubase at 256 and ASIOGaurd ON....Studio One is the most transparent, allowing the user to specify BOTH settings: input and playback buffers. Regardless--Mixbus has none of the above, it's a single buffer system-like "most DAWs". Also--Logic is not properly compensating for the Berhinger...it will compensate for the audio interface latency only. Maybe the lower scale of error (64 samples vs 512) makes that less immediately apparent, but you DO need to find out how much the cue system adds and put that in as a manual additional offset.

Are you hearing the high pitched noise IN the headphone system when you press "test"? Is there metering on it you can see spiking? The only time I've had the bad wiring message is when it wasn't actually making it due to some routing on the interface. If you can't hear an ugly sound in the headphone unit...it's not making it there...I don't see what interface you're using...you say "over ethernet"...does that mean your audio interface has an AVB or Dante network on it for the Powerplay? I'd be looking at the interface mixer while you press "test"--make sure the sound leaves Mixbus and gets to the interface mixer--then check IT'S routing to make sure that is being sent to the Berhinger...then analog cable from Berhinger back to an input on the audio interface...and again check that mixer to make sure the return is making it back to the interface. It might be causing a feedback loop in there that might be why it's giving the bad signal message.

But, also, you can manually do the click thing...measure how much time the Berhinger adds...you might go ahead and do that because Logic doesn't HAVE a utility to test like Harrison does...so, you'll need to know what it's adding for Logic's engine.

Ok, thanks for clearing that up. I didn't know exactly how Logic does this.
In practice though for me at least, there really isn't much latency while tracking and overdubbing in Logic. And if I've started mixing, there is Low Latency Mode which bypasses the slow plugins. You're right that I would still need to know exactly how much latency the cue system adds, if there is some issue that I need to sort out quickly.

Regarding the calibration, if I calibrate from an input to an output on my interface there is no problem, I get a reading. If I route the test signal from an output on my interface into a channel on the P16 system and back from a line out on a headphone mixer, I get the ugly noise inside the headphone system and the Mixbus error.

The interface is a Clarett 8PreX. The P16 splitter is being fed 8 analog channels from an OctoPre unit connected to the 8PreX by ADAT. Inside the P16 splitter the signal is converted to digital, sent by cat5 cables to the headphone mixers where it is converted back to analog for the headphones.

Cheers,
Janne

[Dingo]

how would I set this up in practice?

What I've done is I've recorded the click by miking a set of headphones and adjusted latency so that the recorded click aligns with the click playback.

Create a new mono audio track, open Window / Audio Connections.
From the Source List (LHS) select Mixbus(32C) Misc / Click Out.
From Destinations select Mixbus Tracks / patch Click Out to the input of your newly created audio track.
From Destinations select Hardware and un-patch the Click Out.
Record the Click for the range you require. I then cut to the first mod of the first click and align that to the grid with the amount of count in I want.
Deassign the click channel from all Busses and the Master, (unless you want to hear it in the control room) you can route to the Foldback Busses which you then feed to cans for artists.

https://rsrc.harrisonconsoles.com/mixbus...ons-window

[JB Berg]

Create a new mono audio track,  open Window / Audio Connections.
From the Source List (LHS) select Mixbus(32C) Misc / Click Out.
From Destinations select Mixbus Tracks / patch Click Out to the input of your newly created audio track.
From Destinations select Hardware and un-patch the Click Out.
Record the Click for the range you require. I then cut to the first mod of the first click and align that to the grid with the amount of count in I want.
Deassign the click channel from all Busses and the Master, (unless you want to hear it in the control room) you can route to the Foldback Busses which you then feed to cans for artists.

https://rsrc.harrisonconsoles.com/mixbus...ons-window

Thanks Dingo,
This is a great way to get the recorded click track into the headphones for sure. It will be the same as previously recorded material

My question was how I can make sure the new recording is in sync with the existing one, regardless if I actually use a click track in tracking (I usually don't) or just playback. Meaning, is the playback in the cans aligned with the signal being recorded in the DAW at the same time.