I did an experiment on a tour. I was using an M32 with a DL32. I use all the 32 input for this show. The venue had an analog split snake so I ran the input on the local input and DL32 at the same time. During soundcheck I switched between the two using a snippet to do it in one click. I know theoretically the frequency response should be the same, but I found there was a lot more details running the Local preamp. It was really noticeable in the keyboard sound. Also, the main PA was patched locally and the In-Ears on the DL32. The band on stage also prefers when the input where Local. To be fair it was not night and day difference but still I use an analog snake when I am able to.
Being a musician and a recording engineer, at some point I wanted a definitive answer to the question “how much latency is ok?” Finding out what amount we have is simple addition, with DAWs, mixers providing the numbers. But what amount is ‘invisible’ to us as players? I record live within a Pro Tools session and provide foldback from that session as a regular part of my workflow, so I needed a number; a reference I could relate to as a player. Here’s how I got there. First, some known quantities. 1. Sound travels a foot in a ms (millisecond). Umm… close enough. 2. A sixty-fourth note at 120BPM = 31ms. 3. A band of any kind - string ensemble to power trio - while rehearsing and writing together, commonly tolerates distances of 10ft and sometimes much, much more between instruments while absolutely nailing a groove. So they see and adjust to latencies of 10ms+, when they must. Some real life MINIMUM numbers: When a drummer hits the snare with the most perfect accuracy they can muster, its sound takes roughly 2ms to reach their ears. If I mic that snare a couple inches away and return that signal to the drummer’s IEMs with zero latency, it is actually going to be EARLY! This blew my mind and helped me establish that 2ms must surely be an indistinguishably short system latency. Besting that 2ms might be legitimately claimed as folly. For the kick it’s more like 4ms but I’m sticking with the worst case snare. The note value I mentioned in #2 applies to any instrument and assumes that extremely fast cadences that hardly anyone can play with accuracy represent a resolution of about 15 times that snare-to-ear delay. That seems likewise to be quite reasonable as a delay that would never intrude on a player’s meter. Trust me, even the most insane fret-tapping fiend is not going to feel 2ms. Even the 1st Violin parts in Vivaldi’s Four Seasons would be safe. For anything more legato, the tolerable latency would of course be larger. 3ms is not easy to achieve but is entirely doable with a DSP system like my Pro Tools HD, which measured 2.72ms with hundreds of plug-ins and layers of submixes necessary to record a 10 piece band and return 16 foldback mixes during a live session. This was a paid gig, so I couldn’t experiment. It was a one-time with a crowd, don’t mess it up, test and it passed with flying colors. Many will spot that real life delays are much longer and that we players adjust, which is true. But I wanted to know how much ARTIFICIAL latency I could introduce without problems. The eye-ear-brain connection is a marvel and a player will adapt to anything they can compute. What they can’t see becomes un-computable. 2ms if I can, 3ms worst case - will cause no issue.
I've seen other demonstrations say that if there's a latency of less than 7ms for in-ear monitors it's imperceivably to the performer. Anything there at 7-10 is perceivable and in the 12-15+ range it's almost unusable because of how disorienting it is. Also keep in mind everything adds latency. A wireless microphone, into a mixing console, down a run of AES50, processed, back down the AES50 run, out the stage box, then fed into a wireless in-ear monitor pack, for example, is around 5ms or something like that. It's totally fine. But everything DOES add latency. So here's a real-world example: I use a wireless guitar pack, wireless in-ear pack, and all that digital routing, and it's totally fine, BUT, I also occasionally use a drop-tune pedal for my guitar so we can play in other tuning at the press of a button instead of having to changed to an Eb tuned guitar, but that DOES add enough latency, that it is noticeable. Not to anyone who is not the person playing the guitar, but playing through the pedal, WITH all those other latency things is perceivable. Whereas the pedal by itself is not, and the wireless stuff all also by itself is not, but adding them together, it is noticeable. Not enough to cause us to not use it because the convenience is just too awesome, but it is worth knowing.
I read an observation from a monitor engineer some years back who related a story about a well known female vocalist he was working with who complained about the latency of a speaker/amp combination for her stage wedge. The engineer switched to an amp with a less powerful DSP and thus a less complex speaker preset, and the artist was happy. The more complex DSP preset utilized FIR filters and had a latency of ~7.3ms. The simpler amp had a preset latency of ~0.6ms with only PEQ filters. Both amps were from the same manufacturer and the presets were provided by the loudspeaker manufacturer.
@@johnschalk1271 7ms is ridiculous latency for a power amp to have! Any single monitor device’s one way latency should be sub 1ms. Who would design an amplifier, which would almost inevitably be part of a monitoring chain, with such delay? DSP doesn’t even deserve the name if it takes 6ms to emulate an equalizer. Extremely complex equalizers emulations within Pro Tools HDX come with about 1ms delay. Run of the mill EQs take 100us or less.
@@johnschalk1271 Your post made me look up my Crown amplifiers spec sheets. All the DSP processes are clearly explained. Latency? Crickets….. Shame, and no excuse.
Aes50 has a fixed delay of 3 samples per node and one connection is two nodes. This also means that the delay differs slightly depending on if the console is running at 44k or 48k. The tiny delay between the x32 and m32 is due to different a/d/a converters.
@@dreamhamsterproductions9196 Important to point out the obvious. The two have to use the same clock to sync, so one at 44.1 and the other at 48 will never happen.
I just found your channel a week ago and I've already watched hours worth of content. I'd love to see some experimentation using the X32 board and a Midas stage box over AES50. Theoretically, you would get all of the audible benefits of the M32? Of course, field testing reveals things that theory doesn't.
The tests I did use the m32 as the stage box for the x32, Wich should be the same as using the Midas stage box with the x32. The differences I am finding are with the analog conversions, analog circuits, build quality, faders and ergonomics. I have not found differences in the digital processing, so sound wise, the stagebox should be the determining factor. Reliability, durability and use-ability of the surface differences are seperate.
@@DaveRat thank you for clearing that up! And thank you for being a badass punk sound geek. I don't think there are analytics to measure for audio-nerdiness, but I'd bet you're crushing that stat.
AES50 has admirably low delay, interestingly it is nearly identical at 0.15mS to Dante’s performance. That could be deliberate or perhaps there is a technical reason they are so close to exact parity. The 10uS difference between the consoles is not trivial. I wouldn’t say it is highly unlikely to run into that using two consoles to accommodate a large-count show. It’s way more likely than we might initially think, and as most of us know, a 10uS ‘clash’ is a huge deal sonically. That is a very interesting result, Dave. Great catch.
Thank you, I believe the offset in latency is due to the d to a converters so it would only show up if you merged the outputs of an x32 with an m32 both reproducing an identical signal that has been re summed with itself. That said, I am guessing that the added latency due to the different d to a processor is not the only difference between the cheaper x32 and more expensive m32 d to a converters. So it is more of an indicator that there are probably more differences that I did not notice or require differing setups to hear or measure.
@@DaveRat You are very likely exactly right about the source of this delay. There are circumstances when using digital IO, rather than analog, is a workaround. It’s ironic that what was once the most expensive part of any digital audio product - the converters - is no longer. I haven’t looked into the current crop of ADDA devices for delay but certainly there are differences. That would be a wonderful thing for the industry to focus on and standardize. There is no inherent reason for that delay to be different for any converter. All devices’ delay is some whole number of samples and it would be simple to design for a fixed whole number.
@@artysanmobile Peter, the delay is in the actual A/D device used. The audio is sampled and held, then the held sample is converted. Some A/D chips take more clock cycles to complete this task as it is often successive approximation. Not sure if it is true as it was on the internet, but to reduce this latency in the M32, I heard the A/D is clocked at 92 KHZ instead of 48 KHZ even though the data rate in the system is 48KHZ. This is done to decrease the amount of time to complete the A/D step of the conversion. This may be why the true Midas A/D is faster than the Midas Designed A/D in the X32. The double sample clock rate in the input can also be used to average 2 samples to reduce noise in the front end, so this conversion rate has 2 advantages. Faster conversion to the bus and lower noise due to double samples in the same time averaging out noise. This is a bit technical. I'll have to see if I can find the info on the Midas pro A/D conversion again.
Hi Dave! Interesting to see the minute latency introduced on the X32. I'm guessing the M32 produced a similar result? In regards to copper vs. AES50, I ran a street fest gig with both this summer. M32 at FOH with a 24 channel copper snake plus a Dl16. Had the DL16 at the back for drums and instruments and copper for vocals and extras. Didn't notice any latency, but I am aware that there's supposed to be a 1.1+ ms difference, between the two and had great results the whole weekend. Thanks again for the vids!
The aes50 latency is the same for both but I did measure the x32 with 20 microseconds more latency, I am told that is due to a different digital to analog converter chip.
I've watched a vid of Metalica's FOH engineer Mic Hughs and he really likes the console he works with (Midas Digital) but it rings clear that cables makes a difference. This bodes the question of delays used for driver alignment at stage vs. delays used for field drivers used in big venues such as Rock AMRING in Germany. If latenancy is a big issue in cable types , how do we mathmatically compute delay settings for field drivers at such events?
Hmmm, the time it takes to convert from analog to digital and back to analog can induce some latency of say .8ms to 2.5ms or so, equating to the equivalent of about 8 inches to 30 inches of how far sound would travel in air over the same time period. Setting time for a delay cluster would involve delaying the sound to compensate for the distance differential between the main system and delay cluster from the listener perspective, so say a delay cluster is 115 feet away from the main pa, and sound travels about 1150 feet per second, the the sound would need to be delayed about .1 seconds or 100 ms. As far as the latency induced by cables, sound in wires or fiber optics travels at about 2/3 the speed of light or faster so maybe somewhere above 600 billion feet per second so the added latency would be maybe .00017ms for delay cluster 115 feet away. Or looked at the other way, a cable a MILE long would add a delay of less than .008ms or less than a 1/100th of an inch, which would be irrelevant. So all in all, time travels slow in air, about a millisecond per foot, and very very fast in wires, about a millisecond for 125 miles and converting from analog to digital and digital to analog adds a small delay of about 4" to 15" each time you convert.
@@DaveRat Wow, that shows an engineer level of answer that is correct. Love the answers from an engineer vs an audiophile. For a real world example, communicate with someone a couple blocks away by phone and yelling. Sound through air is way slower even considering the obvious delay in digital of a cell phone when standing next to each other. Then remember the sell signal goes from a phone, to a tower, to a central switch, back to the tower and then to the other phone, and this trip can be miles long and still beat the analog voice in air over the distance of a couple blocks. Sound in air is really slow in comparison to sound in a wire.
@@DaveRat Delays concerning distance for field setups weren't really my problem. (Speed of sound @ sea level and relative humidity )but the latency of the conected electronics and the conduit on which the signal travels. Thanks Dave for breaking that down. Love technology but you need to know what you're dealing with. Top knotch Dave.
again very nice one! If i have an internal plugin inserted at the master section, and use subgroups set up via Bus to make my mixes , once i cant insert plugins in a bus, latency is significative
Nice! Always wondered how much latency was added by the AES50 Link. Would like to see this compared with Dante with and without a few network switches. Looks like the delay is about the same as an analog cable between the consoles with the A/D and D/A pair on the consoles. Any chance of comparing the AES to an analog cable from a send to a return on the other console? I suspect the link is about the same through the D/A and A/D on the send return pair as the buffers for serial multiplexed transmission over AES50. Would be interesting to see the differences.
latency is something to really keep in mind, ive seen it catch out some engineers. the plugin effects that you ca insert on channels all habe small amounts of atency. the 1176 is nice as parralel comp for drums, seen engineers do that with drums still going to mains ad not notice the phasing issues. i got round it by using 2 stereo subgroups both with the 1176 with 1 having no gain reduction or just tickling and the 2nd with agressive settings. good to purposely cause phase issues and learn what is sounds like,
Interesting. Definitely want to compare and make sure that when re summing multiple paths, there is not detriments. Mirroring the processing is a good mitigation
@@DaveRat its just we using a isert via the fc slots. theress slightly diffferet latency dependig on what fc is used. think it rages from 0.9ms to 1.3ms. someone measured it some years back.
@@artysanmobile sq series when using deep processing has wet and dry level controls to allow paralell paths. not sure about inserts. midas pro series does latency compensation.
I’m going from a x32 rack to a m32C both used with the DL32 midas stage box for inputs and outputs. will there be any difference in quality since they both used the same Stagebox and pre’s?
The stage box should determine the sound quality of noise on the input side. Same with the outputs, if you use a Midas stage box you'll have quiet or inputs but if you use the X32 analog outputs they'll be noisier.
This would be very interesting noted that dave found the sync issue what many people have. having a scope of cable testing with shielding or not shielding cat 5 or higher make the difference or not having a good sync. Some people swore that you need this protocol of cable otherwise you will have issue. i myself use shielded cable created by myself but have never issues with syncing.
I think it may also matter how long of a run. I know once you get up to 300-350ft Cat5e doesn't cut it anymore. Perhaps it's a combination of things that cause that sync issue. I've never experienced it myself, but we have always only used 100ft or 150ft Cat5e Shielded Ethercon (What the manufacturer reccommends). And have never had a problem. I've had other problems with people stepping on the cat 5e and causing a sort of short white-noise burst pop sound, which we have since concluded was a release of static electricity after the gear had been powered on for some time, AND had been stepped on squarely by some drunk guy. But I digress, lol.
Hi Dave Thanks for your good and informed posts. All network transmissions introduce latency, as does a DA/AD conversion. What really puzzles me is, is it better to run a stage box with 32 inputs or is it the same if I run 2 pieces of DL16 for example? Does the simultaneous operation of 2 stage boxes already introduce time differences to the FOH console?
Maybe it would be an option to run one stage box on AES50A and one on AES50B. The signal path from the stage to the FOH console would then (perhaps) be identical.
Good question and I don't know but... As long as you do t have identical signals running into both stageboxes and the are re summing those identical signals, a bit of latency offset is not an issue. A latency offset of . 5 Ms is about the same as having a mic 6" further than another mic. And if those two mics are not on the same instrument pointing at the same part of the instrument, the 6" differential is not an issue. We have much bigger issues like drums bleeding into vocal mics that are 15 feet away creating dual signals that are 15ms offset.
@@DaveRat So true, the thing with the drum crosstalk. I wonder what that looks like with jazz or orchestral? Al Smith always mentioned the importance of the off-axis response in this music. The microphones are often further away and the crosstalk and off-axis response is very high at the microphones. Is latency a form of distortion? Many of my colleagues think so, which of course would have to be investigated in depth. In a DAW, 0.1 ms shifts of the same signal are serious. On stage it doesn't exist like that (almost not ...) . Thanks Dave, your articles are very interesting.
The difference in latency between the two consoles is due to the x32 using a less expensive and slower d to a converter, I am told. As far as clocking, when you use analog inputs and analog outputs, you are comparing latency of the units. Clocking does not alter latency. Clocking time aligns and syncs the sampling, That said, if you clocked them together and then raised the clock frequency, or if they are not clocked and the independent clock frequencies were raise, then the latency could possibly be reduced. Latency of 96k products tends to be lower than 48k units. If the independent clocks are drifting so drastically that they were altering the latency, we would see the waveforms shifting all over the place on the scope when comparing the two
@@DaveRat Don't forget, there is only one device as the master clock. They are running on the same clock. AES50 will not run asynchronously on two different clocks. Attempts to do so kills the green sync light.
Correct except if the latency is too long or there are multiple latencies from multiple pieces of gear, like a digital wireless mic plus digital console plus digital processor in an amp that all add up to too long. Too long is when the latency becomes audible like latencies over 3ms in vocal mics into floor monitors
I thought one of the "selling features" of the M32 over the X32 was the"25 time-aligned and phase-coherent mix buses" which was supposed to be an "M32 only" feature. Have you just proved that BOTH consoles have phase-coherent mix buses?
It is possible the m32 does not have any time offset from channel to channel while the x32 does. I will see if I can give that a measure when I put the consoles back together
I own a m32, but I’ve never heard that the x32 does not have the phase coherent mix busses. I think they are identical in this, due to the firmware is fixing this and this is absolutely the same.
I was told the x32 has a slight time offset between higher and lower channel pairs. But not sure if the m32 does as well. I have tested neither for this.
@@DaveRat Wow, I would be absolutely curious if that’s the case. Because I am working with the waves Soundgrid in live environment and want to use it with lowest delta bcs of avoiding comb filtering. It was not an easy step away from my analogue Midas console. If you could make little chapter about this, it would be awesome. Thx in advance. Plus a little scribble fade in of your signal path. Dave, you’re an inspiration. Whenever you’re in Berlin, let me know… Peace and love
Love your videos so much Dave. Made it my routine to watch one with my morning coffee and do some study, go down the rabbit hole. I've just started mixing on an m32 in a small club (300 capacity) and have noticed its midi i/o. any practical ways i can make use of this? thanks mate big love from australia :)
Super cool Timothy! I dont know much about the Midi. I know it can be used to trigger external effects changes as well as bands that dont have an engineer can use the Midi in to trigger scene/preset changes. But personally I have not used it on any console
The aes50 latency is so so small, just a few inches in physical distance when converted that it is irrelevant unless summing two signals electronically with differing latencies
@@DaveRat interesting. Trying to figure out why there’s no delay on the bus to main vs channel direct to main. To compensate for the processing, they must’ve delayed the inputs straight to main a couple samples to even those out versus through a bus to mains, right?
Hmmm, the analog concept of travelling from here to over there taking some time vs travelling from here to somewhere else then to over there taking more time, does not really apply. In digital, the signal is a created numerical stream, then has various maths applied to it, then ends up as a numerical stream. The maths applied like add these numerical streams together or multiple, divide or some other math equation takes some time to. So best I understand, a console can have a fixed latency time, within which, all possible maths that the console is capable of, can be applied regardless of whether the signal is controlled by one or many knobs or faders or altered along the way. So, similar to what you describe but routing to a subgroup, adding EQ, compressors, gate, or whatever, all are just maths, the time sum of which, are included in the fixed latency, whether or not they are used. That said, I have not tested the whether there are internal patchable efx that alter a the signal latency. Also, there does seem to be a very slight latency offset between pairs of channels such that if an identical signal is inputted into channel 1 and 3, there is a a time offset of 1 sample or 1/48000th of a second or about 1/4" I will look at measuring and confirming,. If this is true, then an input on channel 1 or 2 compared channel 31 or 32 would be offset 4" or .37ms
I hate the proprietary Cat 5 etc Ethernet connections that charge $1,000 for their version of a network switch. AES50 may need a deacent cable but that is all it needs.
Network switches are a store and forward device with absolutely no regards for a system clock. To use a "Normal" network switch, you lose low latency as some bits are delayed longer than others as the switch stores and forwards packets. The real world analog is your snail mail. It is delivered between noon and 2 PM, but not always at the same time everyday and always after being received, stored, routed, then delivered. That special switch is like overnight express. Everything in by midnight is delivered by 2PM the following day. No missed letters and delayed mail in a time critical delivery system. Runs by a master clock. This is the difference. Without it, overnight delivery turns into long latency of delivery of sometime within 28 days. You may send packages one a day, but they get delivered some the next day and some days get 4 days worth of packages.
You need to have the same amount of processing to not have that issue. You have 2 options - 1) use stock compressor not a plug-in type 2) if you want to use plug-in make 2 busses and process both of them with the same plug-in.
RAT SOUNDS is a hell of an empire sales rentals manufacturing and touring with the likes of the peppers should ensure some Spare jinglys left in the back pocket. But the wisdom He passes on is pricesless
Doing the work helps Dave and all of us get better at what we do, hopefully helps with success in the practical sense. There is a lot of voodoo out there. Repeatable, understandable information is valuable IMO. Appreciation to Dave.
Everything comes back into fashion. Vinyl outsold CD last year so my old outdated copy of TOOL AENIMA went up from $19.95 I paid for it to over $1000 now if mankinis come back into vouge I’ll be set. ha ha ha lol.
Hmmm, well these tests were inspired by bands coming through with M32 consoles and having issues with 100 meter runs for the AES50 of the festival shows we provide sound for. So I got the consoles to do some tests and share what I found. Perhaps you can share some valuable info about this outdated gear from your position of knowledge and experience? Sometimes the most judgemental people are the least informed and sharing info so we know your depth of useful knowledge would be appreciated.
Thank you for taking the time for this unnecessary and meaningless comment... and Dave everything you do supplies super information crossing my mind that nobody has actual real life answers, you know even the biggest companies sometimes gives false documentation with the product, having test result with one sine wave instead of pink noise and manipulating the information... thank you so much man 👊
The majority of small to midsized clubs in the cities in my area of the world have these two mixers. As much as "big time" engineers turn up their nose at them, it is to our benefit to learn as much as we can about them in order to do our job better, regardless of whether we like them or if they are "old" . The information Dave gives is current for real world situations. If your looking for a GAS channel, in order to buy your next $20,000 mixer (just to say you have the shiny new mixer) Dave ain't it.
I did an experiment on a tour. I was using an M32 with a DL32. I use all the 32 input for this show. The venue had an analog split snake so I ran the input on the local input and DL32 at the same time. During soundcheck I switched between the two using a snippet to do it in one click. I know theoretically the frequency response should be the same, but I found there was a lot more details running the Local preamp. It was really noticeable in the keyboard sound. Also, the main PA was patched locally and the In-Ears on the DL32. The band on stage also prefers when the input where Local. To be fair it was not night and day difference but still I use an analog snake when I am able to.
That's interesting, not sure the cause but variable do occur. Seems it should be the opposite but that said, it's all about testing vs assuming.
Being a musician and a recording engineer, at some point I wanted a definitive answer to the question “how much latency is ok?” Finding out what amount we have is simple addition, with DAWs, mixers providing the numbers. But what amount is ‘invisible’ to us as players? I record live within a Pro Tools session and provide foldback from that session as a regular part of my workflow, so I needed a number; a reference I could relate to as a player. Here’s how I got there.
First, some known quantities.
1. Sound travels a foot in a ms (millisecond). Umm… close enough.
2. A sixty-fourth note at 120BPM = 31ms.
3. A band of any kind - string ensemble to power trio - while rehearsing and writing together, commonly tolerates distances of 10ft and sometimes much, much more between instruments while absolutely nailing a groove. So they see and adjust to latencies of 10ms+, when they must.
Some real life MINIMUM numbers: When a drummer hits the snare with the most perfect accuracy they can muster, its sound takes roughly 2ms to reach their ears. If I mic that snare a couple inches away and return that signal to the drummer’s IEMs with zero latency, it is actually going to be EARLY! This blew my mind and helped me establish that 2ms must surely be an indistinguishably short system latency. Besting that 2ms might be legitimately claimed as folly. For the kick it’s more like 4ms but I’m sticking with the worst case snare. The note value I mentioned in #2 applies to any instrument and assumes that extremely fast cadences that hardly anyone can play with accuracy represent a resolution of about 15 times that snare-to-ear delay. That seems likewise to be quite reasonable as a delay that would never intrude on a player’s meter. Trust me, even the most insane fret-tapping fiend is not going to feel 2ms. Even the 1st Violin parts in Vivaldi’s Four Seasons would be safe. For anything more legato, the tolerable latency would of course be larger.
3ms is not easy to achieve but is entirely doable with a DSP system like my Pro Tools HD, which measured 2.72ms with hundreds of plug-ins and layers of submixes necessary to record a 10 piece band and return 16 foldback mixes during a live session. This was a paid gig, so I couldn’t experiment. It was a one-time with a crowd, don’t mess it up, test and it passed with flying colors. Many will spot that real life delays are much longer and that we players adjust, which is true. But I wanted to know how much ARTIFICIAL latency I could introduce without problems. The eye-ear-brain connection is a marvel and a player will adapt to anything they can compute. What they can’t see becomes un-computable. 2ms if I can, 3ms worst case - will cause no issue.
I've seen other demonstrations say that if there's a latency of less than 7ms for in-ear monitors it's imperceivably to the performer. Anything there at 7-10 is perceivable and in the 12-15+ range it's almost unusable because of how disorienting it is. Also keep in mind everything adds latency. A wireless microphone, into a mixing console, down a run of AES50, processed, back down the AES50 run, out the stage box, then fed into a wireless in-ear monitor pack, for example, is around 5ms or something like that. It's totally fine. But everything DOES add latency. So here's a real-world example: I use a wireless guitar pack, wireless in-ear pack, and all that digital routing, and it's totally fine, BUT, I also occasionally use a drop-tune pedal for my guitar so we can play in other tuning at the press of a button instead of having to changed to an Eb tuned guitar, but that DOES add enough latency, that it is noticeable. Not to anyone who is not the person playing the guitar, but playing through the pedal, WITH all those other latency things is perceivable. Whereas the pedal by itself is not, and the wireless stuff all also by itself is not, but adding them together, it is noticeable. Not enough to cause us to not use it because the convenience is just too awesome, but it is worth knowing.
👍
I read an observation from a monitor engineer some years back who related a story about a well known female vocalist he was working with who complained about the latency of a speaker/amp combination for her stage wedge. The engineer switched to an amp with a less powerful DSP and thus a less complex speaker preset, and the artist was happy. The more complex DSP preset utilized FIR filters and had a latency of ~7.3ms. The simpler amp had a preset latency of ~0.6ms with only PEQ filters. Both amps were from the same manufacturer and the presets were provided by the loudspeaker manufacturer.
@@johnschalk1271 7ms is ridiculous latency for a power amp to have! Any single monitor device’s one way latency should be sub 1ms. Who would design an amplifier, which would almost inevitably be part of a monitoring chain, with such delay? DSP doesn’t even deserve the name if it takes 6ms to emulate an equalizer. Extremely complex equalizers emulations within Pro Tools HDX come with about 1ms delay. Run of the mill EQs take 100us or less.
@@johnschalk1271 Your post made me look up my Crown amplifiers spec sheets. All the DSP processes are clearly explained. Latency? Crickets….. Shame, and no excuse.
Legend again! Thanks! I wish you a nice holiday with cool people
Happy holidays and thank you!
That’s very impressive. From what I remember, the datasheets specify
Aes50 has a fixed delay of 3 samples per node and one connection is two nodes. This also means that the delay differs slightly depending on if the console is running at 44k or 48k.
The tiny delay between the x32 and m32 is due to different a/d/a converters.
👍👍
@@dreamhamsterproductions9196 Important to point out the obvious. The two have to use the same clock to sync, so one at 44.1 and the other at 48 will never happen.
I just found your channel a week ago and I've already watched hours worth of content. I'd love to see some experimentation using the X32 board and a Midas stage box over AES50. Theoretically, you would get all of the audible benefits of the M32? Of course, field testing reveals things that theory doesn't.
We're using this exact setup at a venue I work at. Would love to see this.
The tests I did use the m32 as the stage box for the x32, Wich should be the same as using the Midas stage box with the x32.
The differences I am finding are with the analog conversions, analog circuits, build quality, faders and ergonomics.
I have not found differences in the digital processing, so sound wise, the stagebox should be the determining factor.
Reliability, durability and use-ability of the surface differences are seperate.
@@DaveRat thank you for clearing that up! And thank you for being a badass punk sound geek. I don't think there are analytics to measure for audio-nerdiness, but I'd bet you're crushing that stat.
Awesome!
AES50 has admirably low delay, interestingly it is nearly identical at 0.15mS to Dante’s performance. That could be deliberate or perhaps there is a technical reason they are so close to exact parity.
The 10uS difference between the consoles is not trivial. I wouldn’t say it is highly unlikely to run into that using two consoles to accommodate a large-count show. It’s way more likely than we might initially think, and as most of us know, a 10uS ‘clash’ is a huge deal sonically. That is a very interesting result, Dave. Great catch.
Thank you, I believe the offset in latency is due to the d to a converters so it would only show up if you merged the outputs of an x32 with an m32 both reproducing an identical signal that has been re summed with itself.
That said, I am guessing that the added latency due to the different d to a processor is not the only difference between the cheaper x32 and more expensive m32 d to a converters. So it is more of an indicator that there are probably more differences that I did not notice or require differing setups to hear or measure.
@@DaveRat You are very likely exactly right about the source of this delay. There are circumstances when using digital IO, rather than analog, is a workaround.
It’s ironic that what was once the most expensive part of any digital audio product - the converters - is no longer. I haven’t looked into the current crop of ADDA devices for delay but certainly there are differences. That would be a wonderful thing for the industry to focus on and standardize. There is no inherent reason for that delay to be different for any converter. All devices’ delay is some whole number of samples and it would be simple to design for a fixed whole number.
👍👍
@@artysanmobile Peter, the delay is in the actual A/D device used. The audio is sampled and held, then the held sample is converted. Some A/D chips take more clock cycles to complete this task as it is often successive approximation. Not sure if it is true as it was on the internet, but to reduce this latency in the M32, I heard the A/D is clocked at 92 KHZ instead of 48 KHZ even though the data rate in the system is 48KHZ. This is done to decrease the amount of time to complete the A/D step of the conversion. This may be why the true Midas A/D is faster than the Midas Designed A/D in the X32. The double sample clock rate in the input can also be used to average 2 samples to reduce noise in the front end, so this conversion rate has 2 advantages. Faster conversion to the bus and lower noise due to double samples in the same time averaging out noise.
This is a bit technical. I'll have to see if I can find the info on the Midas pro A/D conversion again.
Hi Dave! Interesting to see the minute latency introduced on the X32. I'm guessing the M32 produced a similar result? In regards to copper vs. AES50, I ran a street fest gig with both this summer. M32 at FOH with a 24 channel copper snake plus a Dl16. Had the DL16 at the back for drums and instruments and copper for vocals and extras. Didn't notice any latency, but I am aware that there's supposed to be a 1.1+ ms difference, between the two and had great results the whole weekend. Thanks again for the vids!
The aes50 latency is the same for both but I did measure the x32 with 20 microseconds more latency, I am told that is due to a different digital to analog converter chip.
x32 rack owner here, interesting vid thanks!
👍👍
I've watched a vid of Metalica's FOH engineer Mic Hughs and he really likes the console he works with (Midas Digital) but it rings clear that cables makes a difference. This bodes the question of delays used for driver alignment at stage vs. delays used for field drivers used in big venues such as Rock AMRING in Germany. If latenancy is a big issue in cable types , how do we mathmatically compute delay settings for field drivers at such events?
Hmmm, the time it takes to convert from analog to digital and back to analog can induce some latency of say .8ms to 2.5ms or so, equating to the equivalent of about 8 inches to 30 inches of how far sound would travel in air over the same time period.
Setting time for a delay cluster would involve delaying the sound to compensate for the distance differential between the main system and delay cluster from the listener perspective, so say a delay cluster is 115 feet away from the main pa, and sound travels about 1150 feet per second, the the sound would need to be delayed about .1 seconds or 100 ms.
As far as the latency induced by cables, sound in wires or fiber optics travels at about 2/3 the speed of light or faster so maybe somewhere above 600 billion feet per second so the added latency would be maybe .00017ms for delay cluster 115 feet away.
Or looked at the other way, a cable a MILE long would add a delay of less than .008ms or less than a 1/100th of an inch, which would be irrelevant.
So all in all, time travels slow in air, about a millisecond per foot, and very very fast in wires, about a millisecond for 125 miles and converting from analog to digital and digital to analog adds a small delay of about 4" to 15" each time you convert.
@@DaveRat Wow, that shows an engineer level of answer that is correct. Love the answers from an engineer vs an audiophile. For a real world example, communicate with someone a couple blocks away by phone and yelling. Sound through air is way slower even considering the obvious delay in digital of a cell phone when standing next to each other. Then remember the sell signal goes from a phone, to a tower, to a central switch, back to the tower and then to the other phone, and this trip can be miles long and still beat the analog voice in air over the distance of a couple blocks. Sound in air is really slow in comparison to sound in a wire.
👍👍👍
@@DaveRat Delays concerning distance for field setups weren't really my problem. (Speed of sound @ sea level and relative humidity )but the latency of the conected electronics and the conduit on which the signal travels. Thanks Dave for breaking that down. Love technology but you need to know what you're dealing with. Top knotch Dave.
🤙🤙🤙
again very nice one! If i have an internal plugin inserted at the master section, and use subgroups set up via Bus to make my mixes , once i cant insert plugins in a bus, latency is significative
I could see that as an issue to be careful with
Nice! Always wondered how much latency was added by the AES50 Link. Would like to see this compared with Dante with and without a few network switches. Looks like the delay is about the same as an analog cable between the consoles with the A/D and D/A pair on the consoles. Any chance of comparing the AES to an analog cable from a send to a return on the other console? I suspect the link is about the same through the D/A and A/D on the send return pair as the buffers for serial multiplexed transmission over AES50. Would be interesting to see the differences.
I don't currently have additional AES50 units other than the X32 but maybe at some point
latency is something to really keep in mind, ive seen it catch out some engineers. the plugin effects that you ca insert on channels all habe small amounts of atency.
the 1176 is nice as parralel comp for drums, seen engineers do that with drums still going to mains ad not notice the phasing issues.
i got round it by using 2 stereo subgroups both with the 1176 with 1 having no gain reduction or just tickling and the 2nd with agressive settings.
good to purposely cause phase issues and learn what is sounds like,
Interesting. Definitely want to compare and make sure that when re summing multiple paths, there is not detriments. Mirroring the processing is a good mitigation
Does anyone know which live console manufacturers offer automatic delay compensation? I thought this was becoming common. Maybe not?
@@DaveRat its just we using a isert via the fc slots. theress slightly diffferet latency dependig on what fc is used. think it rages from 0.9ms to 1.3ms. someone measured it some years back.
@@artysanmobile sq series when using deep processing has wet and dry level controls to allow paralell paths. not sure about inserts.
midas pro series does latency compensation.
I’m going from a x32 rack to a m32C both used with the DL32 midas stage box for inputs and outputs. will there be any difference in quality since they both used the same Stagebox and pre’s?
The stage box should determine the sound quality of noise on the input side. Same with the outputs, if you use a Midas stage box you'll have quiet or inputs but if you use the X32 analog outputs they'll be noisier.
@@DaveRat thanks Dave!
This would be very interesting noted that dave found the sync issue what many people have. having a scope of cable testing with shielding or not shielding cat 5 or higher make the difference or not having a good sync. Some people swore that you need this protocol of cable otherwise you will have issue. i myself use shielded cable created by myself but have never issues with syncing.
👍
I think it may also matter how long of a run. I know once you get up to 300-350ft Cat5e doesn't cut it anymore. Perhaps it's a combination of things that cause that sync issue. I've never experienced it myself, but we have always only used 100ft or 150ft Cat5e Shielded Ethercon (What the manufacturer reccommends). And have never had a problem. I've had other problems with people stepping on the cat 5e and causing a sort of short white-noise burst pop sound, which we have since concluded was a release of static electricity after the gear had been powered on for some time, AND had been stepped on squarely by some drunk guy. But I digress, lol.
Has that LFO always been in your outro? Just noticing today cause I usually watch on my phone lol
Also, great video as usual. Thanks for all you do!
It has been for a while and thank you!
Mesmerizing t-shirt print I'm good im good keep going not looking back
Reminds me of record head man in the back of the KACL radio studio from the sitcoms Frasier
Can't remember where I got it but the back says "John Doe"
Hi Dave
Thanks for your good and informed posts. All network transmissions introduce latency, as does a DA/AD conversion. What really puzzles me is, is it better to run a stage box with 32 inputs or is it the same if I run 2 pieces of DL16 for example? Does the simultaneous operation of 2 stage boxes already introduce time differences to the FOH console?
Maybe it would be an option to run one stage box on AES50A and one on AES50B. The signal path from the stage to the FOH console would then (perhaps) be identical.
Good question and I don't know but...
As long as you do t have identical signals running into both stageboxes and the are re summing those identical signals, a bit of latency offset is not an issue. A latency offset of . 5 Ms is about the same as having a mic 6" further than another mic.
And if those two mics are not on the same instrument pointing at the same part of the instrument, the 6" differential is not an issue.
We have much bigger issues like drums bleeding into vocal mics that are 15 feet away creating dual signals that are 15ms offset.
@@DaveRat So true, the thing with the drum crosstalk.
I wonder what that looks like with jazz or orchestral? Al Smith always mentioned the importance of the off-axis response in this music. The microphones are often further away and the crosstalk and off-axis response is very high at the microphones. Is latency a form of distortion? Many of my colleagues think so, which of course would have to be investigated in depth. In a DAW, 0.1 ms shifts of the same signal are serious. On stage it doesn't exist like that (almost not ...) . Thanks Dave, your articles are very interesting.
👍👍👍
Is it different between the AES50 port vs the Ultranet port on the XR18?
Can we use the XR18 with the Midas DL16 stage box?
Thanks!
Hopefully someone out there will answer those questions because I don't know
Did you clock the two consoles from the same source? Might explain that 10 microsecond offset between the consoles.
The difference in latency between the two consoles is due to the x32 using a less expensive and slower d to a converter, I am told.
As far as clocking, when you use analog inputs and analog outputs, you are comparing latency of the units. Clocking does not alter latency. Clocking time aligns and syncs the sampling,
That said, if you clocked them together and then raised the clock frequency, or if they are not clocked and the independent clock frequencies were raise, then the latency could possibly be reduced.
Latency of 96k products tends to be lower than 48k units.
If the independent clocks are drifting so drastically that they were altering the latency, we would see the waveforms shifting all over the place on the scope when comparing the two
@@DaveRat Don't forget, there is only one device as the master clock. They are running on the same clock. AES50 will not run asynchronously on two different clocks. Attempts to do so kills the green sync light.
Latency wont matter when all the sources (mic inputs) go in and are all late at the same time, is that correct
Correct except if the latency is too long or there are multiple latencies from multiple pieces of gear, like a digital wireless mic plus digital console plus digital processor in an amp that all add up to too long.
Too long is when the latency becomes audible like latencies over 3ms in vocal mics into floor monitors
@@DaveRat i get it,
Awesome!!
I thought one of the "selling features" of the M32 over the X32 was the"25 time-aligned and phase-coherent mix buses" which was supposed to be an "M32 only" feature. Have you just proved that BOTH consoles have phase-coherent mix buses?
It is possible the m32 does not have any time offset from channel to channel while the x32 does. I will see if I can give that a measure when I put the consoles back together
I own a m32, but I’ve never heard that the x32 does not have the phase coherent mix busses. I think they are identical in this, due to the firmware is fixing this and this is absolutely the same.
I was told the x32 has a slight time offset between higher and lower channel pairs. But not sure if the m32 does as well. I have tested neither for this.
@@DaveRat
Wow, I would be absolutely curious if that’s the case. Because I am working with the waves Soundgrid in live environment and want to use it with lowest delta bcs of avoiding comb filtering. It was not an easy step away from my analogue Midas console.
If you could make little chapter about this, it would be awesome. Thx in advance.
Plus a little scribble fade in of your signal path.
Dave, you’re an inspiration. Whenever you’re in Berlin, let me know…
Peace and love
The best mixcher x32 or M32 ko sa hai
Love your videos so much Dave. Made it my routine to watch one with my morning coffee and do some study, go down the rabbit hole.
I've just started mixing on an m32 in a small club (300 capacity) and have noticed its midi i/o. any practical ways i can make use of this?
thanks mate big love from australia :)
Super cool Timothy! I dont know much about the Midi. I know it can be used to trigger external effects changes as well as bands that dont have an engineer can use the Midi in to trigger scene/preset changes. But personally I have not used it on any console
what about daisy chaining few stageboxes? does edge stagebox have higher latency than middle one?
Easy aes50 hop should add the same additional latency.
@@DaveRat is is worth than to add some delay onto channel coming from middle stagebox?
The aes50 latency is so so small, just a few inches in physical distance when converted that it is irrelevant unless summing two signals electronically with differing latencies
Interesting topic, I’m curious how processing impacts the latency. In other words, does engaging the compressor/eq add latency?
The EQ and comp do not add latency
@@DaveRat interesting. Trying to figure out why there’s no delay on the bus to main vs channel direct to main. To compensate for the processing, they must’ve delayed the inputs straight to main a couple samples to even those out versus through a bus to mains, right?
Hmmm, the analog concept of travelling from here to over there taking some time vs travelling from here to somewhere else then to over there taking more time, does not really apply.
In digital, the signal is a created numerical stream, then has various maths applied to it, then ends up as a numerical stream.
The maths applied like add these numerical streams together or multiple, divide or some other math equation takes some time to.
So best I understand, a console can have a fixed latency time, within which, all possible maths that the console is capable of, can be applied regardless of whether the signal is controlled by one or many knobs or faders or altered along the way.
So, similar to what you describe but routing to a subgroup, adding EQ, compressors, gate, or whatever, all are just maths, the time sum of which, are included in the fixed latency, whether or not they are used.
That said, I have not tested the whether there are internal patchable efx that alter a the signal latency.
Also, there does seem to be a very slight latency offset between pairs of channels such that if an identical signal is inputted into channel 1 and 3, there is a a time offset of 1 sample or 1/48000th of a second or about 1/4"
I will look at measuring and confirming,. If this is true, then an input on channel 1 or 2 compared channel 31 or 32 would be offset 4" or .37ms
@@DaveRat the patchable FX can add latency. I read the multiband or "combinator"? definitely does add latency.
That would make sense as a limit on the maths and time the maths can take for efx would limit the limit the number and type of efx.
I hate the proprietary Cat 5 etc Ethernet connections that charge $1,000 for their version of a network switch. AES50 may need a deacent cable but that is all it needs.
Network switches are a store and forward device with absolutely no regards for a system clock. To use a "Normal" network switch, you lose low latency as some bits are delayed longer than others as the switch stores and forwards packets. The real world analog is your snail mail. It is delivered between noon and 2 PM, but not always at the same time everyday and always after being received, stored, routed, then delivered. That special switch is like overnight express. Everything in by midnight is delivered by 2PM the following day. No missed letters and delayed mail in a time critical delivery system. Runs by a master clock. This is the difference. Without it, overnight delivery turns into long latency of delivery of sometime within 28 days. You may send packages one a day, but they get delivered some the next day and some days get 4 days worth of packages.
I have found a lot of latency issues when inserting a processor on a bus or channel
That makes sense.
You need to have the same amount of processing to not have that issue. You have 2 options - 1) use stock compressor not a plug-in type 2) if you want to use plug-in make 2 busses and process both of them with the same plug-in.
👍
How does Dr Rat find the time and $$$ for all the research tinkering? Amazing. Super impressed TBH.
RAT SOUNDS is a hell of an empire sales rentals manufacturing and touring with the likes of the peppers should ensure some
Spare jinglys left in the back pocket. But the wisdom
He passes on is pricesless
Doing the work helps Dave and all of us get better at what we do, hopefully helps with success in the practical sense. There is a lot of voodoo out there. Repeatable, understandable information is valuable IMO. Appreciation to Dave.
Thank you!
💖💖💖
👍
Cat 6 is the new.
Cat6a is probably the one that will perform best, its bulky and tends to be stiff and limited flexibility though.
Dave, everything you do ....is outdated
Everything comes back into fashion. Vinyl outsold CD last year so my old outdated copy of TOOL AENIMA went up from $19.95 I paid for it to over $1000 now if mankinis come back into vouge I’ll be set. ha ha ha lol.
Hmmm, well these tests were inspired by bands coming through with M32 consoles and having issues with 100 meter runs for the AES50 of the festival shows we provide sound for.
So I got the consoles to do some tests and share what I found.
Perhaps you can share some valuable info about this outdated gear from your position of knowledge and experience?
Sometimes the most judgemental people are the least informed and sharing info so we know your depth of useful knowledge would be appreciated.
Thank you for taking the time for this unnecessary and meaningless comment... and Dave everything you do supplies super information crossing my mind that nobody has actual real life answers, you know even the biggest companies sometimes gives false documentation with the product, having test result with one sine wave instead of pink noise and manipulating the information... thank you so much man 👊
Thank you Mert.
Appreciated.
The majority of small to midsized clubs in the cities in my area of the world have these two mixers. As much as "big time" engineers turn up their nose at them, it is to our benefit to learn as much as we can about them in order to do our job better, regardless of whether we like them or if they are "old" . The information Dave gives is current for real world situations. If your looking for a GAS channel, in order to buy your next $20,000 mixer (just to say you have the shiny new mixer) Dave ain't it.