Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Tim McCulloch]

See my post #17 in this thread - that's a picture from a Pro2 manual, you select what busses you need aligned and the latency / timing is adjusted so everything lines up. 

The trick with the dLive is the "deep" processing done at channel level inside the FPGA ... less than about 0.7ms at an output, this includes parallel compression. (see below parallel compression and  a LA2 comp on an Aux). Send something to an effect then the latency is increased on that send but provided that you don't add the dry signal back in there is no issue.

My recollection is that in the higher Pro series you didn't have to tell the console what buses needed the same time/path length but my Midas use is minimal so I may have that all wrong...

We'll be seeing more path compensation in lower end consoles as the user base begins using more sophisticated mixing techniques, I think.

[Andrew Broughton]

We'll be seeing more path compensation in lower end consoles as the user base begins using more sophisticated mixing techniques, I think.

I think it's already there.
Seems to me that's another difference between the M32 and X32, phase-coherent and time-compensated buses on the M series.

[Scott Bolt]

What we're talking about here with respect to fixed-point versus floating-point formats is generally called Finite Register Length Effects. Oppenheim and Schafer devote a chapter to it. While far from being an expert, I have done a bit of DSP programming using both fixed- and floating-point formats, as well as block floating-point, which is a hybrid well suited to computations such as FFTs and other fast (N log N) transforms.

I'll start by saying that neither is inherently better. Much like the debate concerning point sources versus line arrays, they're both tools in the box and each has its pluses and minuses.

Finite register length effects principally manifest themselves in two ways. One is adding quantization noise to the signal. To the extent that the total noise (quatization + other noise, such as analog noise or dither) is uncorrelated with the signal, it is just additive noise and, for most purposes, is no different than thermal or shot noise in an analog system. The other is parameter quantization, which imposes granularity on the possible parameter values of a process, such as the pole and zero locations of a linear filter. I believe the latter to be of little practical concern for audio. Generally, precision (word size for fixed or mantissa size for floating) matters most when a process requires the computation of a small difference between large numbers, such as numeric differentiation by first differences. Good design tries to avoid these situations.

The biggest advantage of floating-point is that we don't ever have to worry about overflow resulting from a computation such as addition or multiplication. This makes it great for rapid prototyping, off-line computation, and general ease of programming. (The R programming I do these days for audio signal and system analysis and representation is all in double-precision floating-point. I can sling code with the abandon and let the computer do the work.)

Fixed-point computation is more of a craft. Much like the gain structure in an analog system, we always have to be mindful of overflow and scaling so as not to clip or introduce excessive noise. The results can be every bit as good as floating-point, and, for a given total number of bits in the numeric representation (word size or mantissa + exponent), and certainly for a given total complexity, we can outperform floating-point. My reasoning is that the unnecessary bits in the exponent can be devoted to higher precision.

Fixed-point was more important in former times when dedicated floating-point processors were not common and fixed-point allowed greater speed with the available hardware. And while this is no longer the case with general purpose CPUs, apparently the folks at A&H decided the extra effort to work with fixed-point was worth it to allow them to pack more computation into their ASIC. My hat is off to them. As an aside, I have a Rane RPM26z system processor in my living room stereo, which uses fixed-point, and it sounds great to me.

This is a big subject and I've only hacked at it a little here and there. A good starting point for anyone wanting to learn more is chapter 9 in "Digital Signal Processing" by Oppenheim and Schafer, Prentice Hall, 1975 "The DSP Bible".

--Frank

Really good explanation Frank.

While it is true that if you start with a 24bit A/D, that this is as much information as you can ever keep, this is never what you end up with after you do a few stages of processing.

Simply multiplying by 2 eliminates 1 bit (assuming that the high bit is set to begin with).  Doing the very sophisticated processing in a digital mixer with fixed point (integer math) is very tricky simply due to the fact that it is REALLY easy to lose significance quickly.

By using floating point, it is much easier to create algorithms which do not lose significance as quickly.

Again, it isn't free.  Floating point calculations are MUCH slower than integer calculations.

Lets take a simple example..... divide by 2.  In integer math, this is simply shifting the bits to the right.  It requires a single clock cycle to perform, and you can do a ton of them in parallel quite easily.

Using floating point, divide by 2 would potentially take 5 times as many cycles.  Floating point processors are many many times more expensive in the chip than integer units as well.

I love the information in this thread.  Very cool.

[Peter Morris]

Really good explanation Frank.

While it is true that if you start with a 24bit A/D, that this is as much information as you can ever keep, this is never what you end up with after you do a few stages of processing.

Simply multiplying by 2 eliminates 1 bit (assuming that the high bit is set to begin with).  Doing the very sophisticated processing in a digital mixer with fixed point (integer math) is very tricky simply due to the fact that it is REALLY easy to lose significance quickly.

By using floating point, it is much easier to create algorithms which do not lose significance as quickly.

Again, it isn't free.  Floating point calculations are MUCH slower than integer calculations.

Lets take a simple example..... divide by 2.  In integer math, this is simply shifting the bits to the right.  It requires a single clock cycle to perform, and you can do a ton of them in parallel quite easily.

Using floating point, divide by 2 would potentially take 5 times as many cycles.  Floating point processors are many many times more expensive in the chip than integer units as well.

I love the information in this thread.  Very cool.

Scott & Frank,

That’s exactly how I understand things.  Both methods have advantages; neither is necessarily better just different.

If done correctly according to the people I have spoken to, fixed point with sufficient/optimal bit depth can produce less truncation errors, and minimise processing time, but I believe that’s it’s not easy to do.

There are also issues using mathematical short cuts, for example bi-quad filter calculations may be arranged in different forms to make it more convenient for processing, but it can have an impact on sound quality.

To me it’s a combination of all of these things – the advantages 96kHz i.e. using anti-alias filters with lower slopes which will result in less phase distortion and smearing in the HF, good mathematics, and in A&H case single bit mathematics where they were able to choose the required bit depth within the FPGA to optimise its performance – precision and noise.
   
Obviously the proof is listening - and I have to say I have always felt that Midas and Digico desks sounded great, better than most, and now our new A&H is sounding just as good if not better.

...its not just the mic-pre's 

[Roland Clarke]

See my post #17 in this thread - that's a picture from a Pro2 manual, you select what busses you need aligned and the latency / timing is adjusted so everything lines up. 

The trick with the dLive is the "deep" processing done at channel level inside the FPGA ... less than about 0.7ms at an output, this includes parallel compression. (see below - parallel compression and  a LA2 comp on an Aux). Send something to an effect then the latency is increased on that send but provided that you don't add the dry signal back in there is no issue.

My information was based on a quote I saw in this months Audio Media where 5 top live engineers were asked about the state of live consoles and their future hopes.

One engineer quoted that the Avid was the only one with end to end delay compensation, I understand Tim’s comment that using busses you can have a problem even with the avid, but this has long been known about and there is a workaround.

The problem as I see it Peter, is that the small delays are often more the problem as they will introduce phase issues right where the ear is more sensitive too them.

Interestingly, from a cursory glance at the article featured in Audio Media, it seemed that all the participants were most universally in agreement about the new range of Yamaha consoles, this has been my experience, though I do think their price appears to be slightly high.  One other mentioned the S6l, though at the top end budget wise (though significantly less than the original XL8),  having seen the demo and having a little play, it’s the best I’ve seen in live consoles by a mile.

[Roland Clarke]

I think it's already there.
Seems to me that's another difference between the M32 and X32, phase-coherent and time-compensated buses on the M series.

I’m unaware that there is a huge amount of difference between the X32 and the M32.  As do many of us, I get to use more of these than I would choose, however, for all my dislike of the Behringer X32, it’s the best sub £2000 console out there and does have a degree of flexibility.  My observation seems to suggest that the software side is identical on both consoles.  The M32 layout is better and slightly better constructed, however, I haven’t been able to discern any audio quality advantage, at least not using it on a PA system, even quality ones.  The faders are supposed to be better, however, I have heard and know of people who have had several issues with the “better” faders of the M32, and few with X32 fader issues.  I certainly don’t think that is justifies its significantly higher price tag.  I could only suspect that if it is time adjusted end to end that is likely that all channels are running the same processing latency.  Is this then effected by using a rack plugin on a channel or busing a signal prior to the LR?

[David Sturzenbecher]

I’m unaware that there is a huge amount of difference between the X32 and the M32.  As do many of us, I get to use more of these than I would choose, however, for all my dislike of the Behringer X32, it’s the best sub £2000 console out there and does have a degree of flexibility.  My observation seems to suggest that the software side is identical on both consoles.  The M32 layout is better and slightly better constructed, however, I haven’t been able to discern any audio quality advantage, at least not using it on a PA system, even quality ones.  The faders are supposed to be better, however, I have heard and know of people who have had several issues with the “better” faders of the M32, and few with X32 fader issues.  I certainly don’t think that is justifies its significantly higher price tag.  I could only suspect that if it is time adjusted end to end that is likely that all channels are running the same processing latency.  Is this then effected by using a rack plugin on a channel or busing a signal prior to the LR?

If it is running the same software, it's definitely not end to end compensated.  I would be eager to see proof of this because I am currently not buying it.


Sent from my iPad using Tapatalk Pro

[Andrew Broughton]

I’m unaware that there is a huge amount of difference between the X32 and the M32.  As do many of us, I get to use more of these than I would choose, however, for all my dislike of the Behringer X32, it’s the best sub £2000 console out there and does have a degree of flexibility.  My observation seems to suggest that the software side is identical on both consoles.  The M32 layout is better and slightly better constructed, however, I haven’t been able to discern any audio quality advantage, at least not using it on a PA system, even quality ones.  The faders are supposed to be better, however, I have heard and know of people who have had several issues with the “better” faders of the M32, and few with X32 fader issues.  I certainly don’t think that is justifies its significantly higher price tag.  I could only suspect that if it is time adjusted end to end that is likely that all channels are running the same processing latency.  Is this then effected by using a rack plugin on a channel or busing a signal prior to the LR?

If it is running the same software, it's definitely not end to end compensated.  I would be eager to see proof of this because I am currently not buying it.

I haven't seen any tests, but the literature for the M32 claims:
"25 time-aligned and phase-coherent mix buses"

The X32 does not include that description. My thought was that means the M32 had latency compensation while the X32 does not. Until someone tests it, though, who knows for sure?

[Scott Bolt]

Both the M32 and X32 have time/phase aligned mix busses and utilize the same exact firmware with the exception of the graphic on startup.

Using an EFX rack item in the insert of a channel introduces additional latency.  This latency is NOT accounted for among the other channels ..... however ...

Unless you mix the same channel together with the raw and "insert processed" signal, you will not hear any difference or have any change in sound quality.

Adding the signals together (using mix groups or matrix groups for instance) will cause the sound of that channel to sound like you put a chorus effect on it

Most of the time, for the vast majority of people this is not a problem.

The SQ will sound better IMO because it has faster processing which allows better processing.  The better processing directly turns into better sound quality.

... and I completely agree... in this day and age, the difference between one preamp and another isn't enough to shake a stick at.  The difference is in the processing engine.

I am really looking forward to hearing the SQ desk.  I Think it is going to sound amazing.

[Roland Clarke]

I haven't seen any tests, but the literature for the M32 claims:
"25 time-aligned and phase-coherent mix buses"

The X32 does not include that description. My thought was that means the M32 had latency compensation while the X32 does not. Until someone tests it, though, who knows for sure?

You may we’ll be right.  My only observations are that as it doesn’t run plugins on channels as such, perhaps the latency per channel is fixed.  I do suspect that the software is exactly the same as no attempy has been made to differentiate it to add “perceived value”, and that would have been the easiest part to do by just changing some graphics look, particularly if money was spent on software developement improvements.

[ProSoundWeb Community]