ProSoundWeb Community
Sound Reinforcement - Forums for Live Sound Professionals - Your Displayed Name Must Be Your Real Full Name To Post In The Live Sound Forums => LAB Lounge => Topic started by: Mark Wilkinson on November 06, 2017, 10:11:23 AM
-
Reading the new A&H mixer thread has reminded me of a question I keep having...
...how does 96 kHz really matter?
I only know two small ways.
Reduced processing time....which I take to be the core processing time that is relatively small and fixed.
The SQ is touted as class leading at <.7ms. An x-32 at 48 kHz is a little over .8ms.
So doubling processing frequency doesn't scale into halving processing time, and anyway the difference here seems trivial...
The next way is pushing anti-aliasing freq up, which I read helps making anti-aliasing filters easier to implement.
But this too, is described as a minor benefit ....over 48kHz (or even 44.1)....anti-aliasing is supposedly no big deal anymore.
I've played with building FIR files at both 48 and 96 kHz to know that there is no increase in frequency resolution, if the goal of 96kHz is to reduce latency
Indeed there is a loss of frequency resolution at 96k, until filter latency becomes the same as at 48k.
Nyquist spreads the sampling at 48 kHz over 24,000 cycles, and sampling at 96kHz spreads over 48,000 cycles.
So if you use the same number of taps (samples) for building the same FIR filter at 96k vs one at 48k, you get one-half the frequency resolution (because the taps have to cover twice the number of cycles under Nyquist).
The 96 kHz build will have 1/2 the latency of the 48 kHz build, but if you want it to match the freq resolution of the 48, you have to double the taps and end up with the same latency, so what's the point of 96k?
Ok, that's about all i know about this stuff, but it does make me really question what is the benefit to higher processing / sampling rates?
Better summing, effects, or something?
-
It gives marketing something to talk about in literature.
-
Reading the new A&H mixer thread has reminded me of a question I keep having...
...how does 96 kHz really matter?
I only know two small ways.
Reduced processing time....which I take to be the core processing time that is relatively small and fixed.
The SQ is touted as class leading at <.7ms. An x-32 at 48 kHz is a little over .8ms.
So doubling processing frequency doesn't scale into halving processing time, and anyway the difference here seems trivial...
The next way is pushing anti-aliasing freq up, which I read helps making anti-aliasing filters easier to implement.
But this too, is described as a minor benefit ....over 48kHz (or even 44.1)....anti-aliasing is supposedly no big deal anymore.
I've played with building FIR files at both 48 and 96 kHz to know that there is no increase in frequency resolution, if the goal of 96kHz is to reduce latency
Indeed there is a loss of frequency resolution at 96k, until filter latency becomes the same as at 48k.
Nyquist spreads the sampling at 48 kHz over 24,000 cycles, and sampling at 96kHz spreads over 48,000 cycles.
So if you use the same number of taps (samples) for building the same FIR filter at 96k vs one at 48k, you get one-half the frequency resolution (because the taps have to cover twice the number of cycles under Nyquist).
The 96 kHz build will have 1/2 the latency of the 48 kHz build, but if you want it to match the freq resolution of the 48, you have to double the taps and end up with the same latency, so what's the point of 96k?
Ok, that's about all i know about this stuff, but it does make me really question what is the benefit to higher processing / sampling rates?
Better summing, effects, or something?
Confirmation bias is the leading factor in most discussions of sampling rates and processing.
There are a hand full of folks who genuinely possess the capabilities to recognize the incredibly small differences that *might* be audible today in audition of 48k v 96k v 192k, but the vast majority of professional users cannot correctly identify which rate is in use on a repeated basis... I think it was Yamaha that did a blind listening test regarding this, perhaps someone else has a link to post...
And "more is better, right?" To me this is kind of like pimping slew rates that go into RF territory or damping factor numbers that, at the end of the speaker cable, no longer exist. But the cachet of a higher sample rate and processing speed is marketable, much like slew rate was in the 1990s and damping factor was in the 1970s and 80s.
In the earlier days of digital audio there were some pretty big slices of time used in equipment that were fine in the studio or post production but made life difficult for performers using IEMs who were moving from analog mixers... contemporary designs, even at 48kHz, have dropped the processing latency considerably and are much closer to the fixed limits of the AD/DA conversions. In that respect does 96k mean "better"? Maybe. How does it sound?
-
Tim's point drives the nail home.
-
To be clear, and to your point, the processing delay of an ideal non-causal FIR filter that realizes a given (complex) frequency response is independent of the sampling rate. (Assuming the sampling rate is sufficient for the bandwidth of the band-limited signal.) You can't fool Mother Nature, nor Father Time.
A high sampling rate can only serve to reduce additional overhead "book keeping" time related to the physical embodiment of the filter.
--Frank
-
Thanks guys,
I sure can't hear or measure any difference, but of course that means nothing.......
Confirmation bias..., yeah :)
@Frank, thx for additional clarity....
My mantra is becoming 'It takes time, to fix time'
-
Reading the new A&H mixer thread has reminded me of a question I keep having...
...how does 96 kHz really matter?
I only know two small ways.
Reduced processing time....which I take to be the core processing time that is relatively small and fixed.
The SQ is touted as class leading at <.7ms. An x-32 at 48 kHz is a little over .8ms.
So doubling processing frequency doesn't scale into halving processing time, and anyway the difference here seems trivial...
The next way is pushing anti-aliasing freq up, which I read helps making anti-aliasing filters easier to implement.
But this too, is described as a minor benefit ....over 48kHz (or even 44.1)....anti-aliasing is supposedly no big deal anymore.
I've played with building FIR files at both 48 and 96 kHz to know that there is no increase in frequency resolution, if the goal of 96kHz is to reduce latency
Indeed there is a loss of frequency resolution at 96k, until filter latency becomes the same as at 48k.
Nyquist spreads the sampling at 48 kHz over 24,000 cycles, and sampling at 96kHz spreads over 48,000 cycles.
So if you use the same number of taps (samples) for building the same FIR filter at 96k vs one at 48k, you get one-half the frequency resolution (because the taps have to cover twice the number of cycles under Nyquist).
The 96 kHz build will have 1/2 the latency of the 48 kHz build, but if you want it to match the freq resolution of the 48, you have to double the taps and end up with the same latency, so what's the point of 96k?
Ok, that's about all i know about this stuff, but it does make me really question what is the benefit to higher processing / sampling rates?
Better summing, effects, or something?
This is not a bad article explaining why there is a very very slight improvement in sound quality.
https://www.soundonsound.com/sound-advice/q-should-i-use-high-sample-rates
I doubt if I could hear the difference between 48 and 96, however if you can find a number of these tiny improvements throughout the signal chain they can add up to something that people can hear and it does become worthwhile. Apply this logic to whole sound system and the improvement will very noticeable.
Recently I purchased a dLive and there is something special about the way it sounds. I can’t tell exactly what it is other than to say to say it sounds really nice, and everyone that uses it notices.
It’s 96 KHz but it also uses fixed point mathematics as apposed floating point that most manufactures use. The advantage of fixed point is sound quality, but you can easily run out of bits as you sum things. To solve this Allen & Heath have used a 72 bit signal path in combination 96 bit accumulator…
I think it’s the sum of these improvements, and probably a few other things that everyone notices with the dLive.
Similarly with latency, its the sum of all the latencies in you signal signal chain that will cause you problems with IEM's. If your digital radio mic had 2 ms, the mixing desk 2 ms etc ... you are starting to be a bit high for some applications ... halve these (more or less) by going to 96 KHz and your OK.
-
The advantage of fixed point is sound quality...
Can you elaborate on this statement?
-
While performing the SAME algorithm on 96Khz will result in half the latency as 48Khz, no one using a 96Khz processing scheme is going to use the SAME algorithm ....... they will use one that is more sophisticated..... and better.
I think we can all agree that having a latency < 1mSec is going to be fine in any situation. Halving that to < 0.5mSec isn't going to result in any appreciable sonic difference (assuming phase coherent processing).
Having the ability to have an algorithm that is two times as complex as another one should absolutely result in better sound.
I would be shocked if the new SQ does not sound better than the other desks out there today.
Now, I would say that the old tried and true 01V had 96Khz, but did not have the sound quality of the desks of today, so it isn't an absolute.
Anyway, just one man's opinion.
-
Can you elaborate on this statement?
DSP’s are not my thing … but here is my understanding…
The problem with floating point maths is that the rounding and truncation of numbers during signal processing produces quantization errors and increase the noise floor.
The things we do during the mixing process such as gain changes, EQ and compression etc. will produce these errors.
Floating point is in general easier to implement, but if you need to do something fast in real time fixed point is much faster and more memory efficient, and as I understand if you have enough bits to do the math more accurate.
Many papers suggest that you need floating point maths for high quality audio but that’s not how things are if you look closely.
It’s probably better explained here:
https://calrec.com/wp-content/themes/calrec/pdf/Myth-of-the-Floating-Point.pdf
When you start to look at this stuff in detail you will also realize that there is a lot more to the sound of a digital desk than the mic preamp’s. :)
-
When you start to look at this stuff in detail you will also realize that there is a lot more to the sound of a digital desk than the mic preamp’s. :)
There, fixed it for you... ;)
-
There, fixed it for you... ;)
thanks Tim ... 8)
-
I think we can all agree that having a latency < 1mSec is going to be fine in any situation.
The issue is that there are a lot of desks, even pro desks, that have a lot more than 1ms of latency.
A Profile system, running analog into an LM26 running a modest FIR preset, plus 60 feet from PA to FOH has enough latency that you can clearly hear it when talking through a VOG mic.
The same setup with a Digico desk running 96KHz, running into the AES inputs of the LM26, did not suffer the same problems, even when we switched over to analog it was still acceptable. Not because the Digico is better (not touching that argument), but because we were able to shed a significant amount of latency.
IMO, that is the real advantage of running higher sample rates.
-
A Profile system, running analog into an LM26 running a modest FIR preset, plus 60 feet from PA to FOH has enough latency that you can clearly hear it when talking through a VOG mic.
And that's almost entirely the 60' from the PA to FOH. Sound through the air is approx 1ms/ft, so 60'=60ms.
Mac
-
The issue is that there are a lot of desks, even pro desks, that have a lot more than 1ms of latency.
A Profile system, running analog into an LM26 running a modest FIR preset, plus 60 feet from PA to FOH has enough latency that you can clearly hear it when talking through a VOG mic.
The same setup with a Digico desk running 96KHz, running into the AES inputs of the LM26, did not suffer the same problems, even when we switched over to analog it was still acceptable. Not because the Digico is better (not touching that argument), but because we were able to shed a significant amount of latency.
IMO, that is the real advantage of running higher sample rates.
Latency can become an issue for some IEM applications above about 3ms, for FOH applications it’s usually not a problem. It’s generally acceptable to time align the arrival of loud stage instruments (back line) to FOH - that will give you at least 10 -15 ms to play with.
-
And that's almost entirely the 60' from the PA to FOH. Sound through the air is approx 1ms/ft, so 60'=60ms.
Mac
This was an A/B scenario. The difference between the Digico running AES versus the Profile running analog was the difference between acceptable and "oh my god, that sounds strange".
-
The issue is that there are a lot of desks, even pro desks, that have a lot more than 1ms of latency.
A Profile system, running analog into an LM26 running a modest FIR preset, plus 60 feet from PA to FOH has enough latency that you can clearly hear it when talking through a VOG mic.
The same setup with a Digico desk running 96KHz, running into the AES inputs of the LM26, did not suffer the same problems, even when we switched over to analog it was still acceptable. Not because the Digico is better (not touching that argument), but because we were able to shed a significant amount of latency.
IMO, that is the real advantage of running higher sample rates.
Ok, but I don't think that because different desks may have different latencies at 48k , that it helps sheds any light on whether 96k is better than 48k...
That just tells me some desks are better engineered than others...
I mean if the relatively low cost x-32s comes in at .8ms....well, why do other desks have more?
Referring to your other post about 96k using better algorithms....that's really what i was asking about in the opening post...
I feel pretty confident that 96k doesn't use anything different for AD/DA conversion (other than anti-aliasing, which Peter posted addition info about),
or for IIR xovers, parametrics, shelving, or any FIR, ........ (these I'm more confident about)
But I have no clue about FX, summing, etc.
Nor do i have a clue if 96k and fixed point vs floating, or bit depth, or other processing factors, couldn't be implemented with 48K...
Hard to isolate variables, huh?
-
Ok, but I don't think that because different desks may have different latencies at 48k , that it helps sheds any light on whether 96k is better than 48k...
That just tells me some desks are better engineered than others...
I mean if the relatively low cost x-32s comes in at .8ms....well, why do other desks have more?
Referring to your other post about 96k using better algorithms....that's really what i was asking about in the opening post...
I feel pretty confident that 96k doesn't use anything different for AD/DA conversion (other than anti-aliasing, which Peter posted addition info about),
or for IIR xovers, parametrics, shelving, or any FIR, ........ (these I'm more confident about)
But I have no clue about FX, summing, etc.
Nor do i have a clue if 96k and fixed point vs floating, or bit depth, or other processing factors, couldn't be implemented with 48K...
Hard to isolate variables, huh?
I don't know what Avid do, but Midas allows you to select what things you want aligned, when you line everything up on the Pro series the latency can be quite high ... 8 or more milliseconds even though its 96K
-
Higher sample rates will equate to higher latency. 8.49ms is a bit high, and right on the borderline where it can be noticeable.
-
Higher sample rates will equate to higher latency.
It sounds like you might have that backwards.
Sent from my iPhone using Tapatalk Pro
-
Floating point, given the same number of bits a an integer, contains more detailed information. If you were to start at the beginning of a design with the driving force being better processing, you would start with floating point.
Floating point processing is considerably more processing intensive than integer processing. This is the sole reason (that I can think of) that not every device uses it. Modern FPGA's and DSP's have the built in ability to handle floating point ..... which is why we now see even lower priced desks that use floating point.
Bad algorithms, slow processing, bad A/D or D/A and any number of other factors can make a desk sound "bad" regardless of its use of integer or floating point processing.
96Khz with the same algorithm will have half the latency as 48Khz.
-
Floating point, given the same number of bits a an integer, contains more detailed information. If you were to start at the beginning of a design with the driving force being better processing, you would start with floating point.
Floating point processing is considerably more processing intensive than integer processing. This is the sole reason (that I can think of) that not every device uses it. Modern FPGA's and DSP's have the built in ability to handle floating point ..... which is why we now see even lower priced desks that use floating point.
Bad algorithms, slow processing, bad A/D or D/A and any number of other factors can make a desk sound "bad" regardless of its use of integer or floating point processing.
96Khz with the same algorithm will have half the latency as 48Khz.
Not exactly – the common assumption is that because of the huge dynamic range that floating point mathematics will provide it is therefore better and affords more detail for audio applications.
We start with a fixed size of 24 bits at the first A/D, this is the best detail we have; when you start to scale this input with floating point mathematics you will end up with rounding and truncation errors which leads to a loss of detail, this doesn’t happen with fixed point so much, but you can run out of head room in the mixing process easily.
What Allen and Heath have done with the dLive is basically the best of both worlds – fix point mathematics with the practical head room of floating point. They have done this with a huge and variable bit depth of up to 96 bits.
I’m probably being too simplistic so here is the link to the first article I posted, plus a couple more.
https://calrec.com/wp-content/themes/calrec/pdf/Myth-of-the-Floating-Point.pdf
http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
http://www.rane.com/pdf/old/note153.pdf
-
We start with a fixed size of 24 bits at the first A/D, this is the best detail we have; when you start to scale this input with floating point mathematics you will end up with rounding and truncation errors which leads to a loss of detail, this doesn’t happen with fixed point so much, but you can run out of head room in the mixing process easily.
I’m probably being too simplistic so here is the link to the first article I posted, plus a couple more.
https://calrec.com/wp-content/themes/calrec/pdf/Myth-of-the-Floating-Point.pdf
http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
http://www.rane.com/pdf/old/note153.pdf
I haven't read the most recent links you posted, only the one from calrec.com (https://calrec.com/wp-content/themes/calrec/pdf/Myth-of-the-Floating-Point.pdf), but I think I'm beginning to understand a little. I'm not qualified to disagree with any of the conclusions but allow me a simplistic argument against the simplistic example laid out in that article and tell me if I’m wrong.
Imagine that you have adopted a 7-digit floating-point format with 4-digit mantissa and 3-digit exponent. You can represent the number one million by writing it as 1000 x 10^3. Now, add the number 999 to this. You should get 1,000999, but since you have only 4 digits available, the result you end up with is 1000 x 10^3 – the number you first started with! Adding 999 has had no effect on the result. The floating point system has failed because it lacked resolution!
What if we think about it in terms of significant digits. If A/D is 24-bit fixed and internal processing is 32-bit float (for example) with a 24 bit mantissa and an 8 bit exponent (ignoring the sign bit for this example), we still have 24 “significant bits”, never more, never less.
If you have a 4 digit fixed point number, 1000, and you add 0.999 to it, you still get 1000.
Real world systems never go from the same bit width in fixed point to the same in float. It’s always 24 bit fixed to 32 or 64 bit float or greater. The simple transition from (x) bits fixed to (x) bits float would lose resolution simply because of the reduced mantissa.
Edit, PS:
It seems to me like it's better to throw away the Least Significant Bit (when the float scales via the exponent) rather than the Most Significant Bit when the value reaches the top of a fixed point number.
Edit2: Thinking about it further, I guess clipping isn't really throwing away the MSB but rather throwing away all bits when the signal exceeds the max value whereas in floating point, only the LSB will be thrown away as the exponent changes. For a continuous signal, the exponent would change in stages.
-
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
-
This was an A/B scenario. The difference between the Digico running AES versus the Profile running analog was the difference between acceptable and "oh my god, that sounds strange".
In out with heavy processing on the Avid is likely sub 5ms, the foh distance is providing 60 and your digico is probably around 2-3ms as they use mostly FPGA’s (as I understand). So you are reckoning you can hear a difference of 2-3ms on a delay of 65ms?
Just to throw another log into the fire, it should be remembered that the Avid consoles are the only console that offers end to end time alighnment for all channels. To my knowledge, no other manufacturer does this, indeed, I read a thread recently where someone measured in/out from various channels on a desk that is gaining popularity and none matched only other. From a point of view of phase issues, this could be a problem.
-
I read a thread recently where someone measured in/out from various channels on a desk that is gaining popularity and none matched only other. From a point of view of phase issues, this could be a problem.
I might have been that person and the dLive might have been the desk ;) So I feel compelled to add that while there are time differences between the outputs they are really small and would only ever matter if the signals were combined electronically downstream. Acoustically the differences are centimeters. And who really goes adding an aux out to a main out, or headphone out to anything? All the things that matter internal to the desk, such as groups, work as they should. The significant thing, to my mind, is how small the overall latency is and how that puts to rest concerns for applications such as in-ear monitors. -F
-
Just to throw another log into the fire, it should be remembered that the Avid consoles are the only console that offers end to end time alighnment for all channels. To my knowledge, no other manufacturer does this
Where did you hear that? Most certainly the PM10 has this capability, and my understanding is that all MIDAS consoles do as well.
-
I might have been that person and the dLive might have been the desk ;) So I feel compelled to add that while there are time differences between the outputs they are really small and would only ever matter if the signals were combined electronically downstream. Acoustically the differences are centimeters. And who really goes adding an aux out to a main out, or headphone out to anything? All the things that matter internal to the desk, such as groups, work as they should. The significant thing, to my mind, is how small the overall latency is and how that puts to rest concerns for applications such as in-ear monitors. -F
Latency can vary through the console as well, for example if you use parallel compression with 2 buses, say a group bus and L/R. If latency is different for each path there *will* be combing when the bus signal is combined with L/R.
If nothing gets combined it doesn't matter. When it does, even outside the console (think AV team combines the signal sent for streaming (example) with the main L/R to get a big more of something...
My understanding is that Midas Pro3 and up and Yamaha's PM10 also correct for this. Digidesign/AVID was the first console to do so.
-
Latency can vary through the console as well, for example if you use parallel compression with 2 buses, say a group bus and L/R. If latency is different for each path there *will* be combing when the bus signal is combined with L/R.
If nothing gets combined it doesn't matter. When it does, even outside the console (think AV team combines the signal sent for streaming (example) with the main L/R to get a big more of something...
My understanding is that Midas Pro3 and up and Yamaha's PM10 also correct for this. Digidesign/AVID was the first console to do so.
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.
-
I might have been that person and the dLive might have been the desk ;) So I feel compelled to add that while there are time differences between the outputs they are really small and would only ever matter if the signals were combined electronically downstream. Acoustically the differences are centimeters. And who really goes adding an aux out to a main out, or headphone out to anything? All the things that matter internal to the desk, such as groups, work as they should. The significant thing, to my mind, is how small the overall latency is and how that puts to rest concerns for applications such as in-ear monitors. -F
I usually add delay to the headphones to align with the mains and the distance I am from them... :)
-
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.
-
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.
-
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.
-
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 :o
-
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.
-
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?
-
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
-
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?
-
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.
-
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.
-
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.
re The M32/X32, this was exactly what I thought might be happening, however, faster processing on another console is only going to change the frequency at which the comb filtering would occur. I was slightly alarmed to hear that another user was finding varying latency issues on a channel by channel basis with the A&H D-live.
-
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.
If true, then there's even MORE reason to question why there is both an X32-CORE and M32-C product at different price points. People buying the M32-C over the X32-CORE are probably the same people that pay extra for Oxygen-free Monster cables.
-
I haven't seen any tests, but the literature for the M32 claims:
"25 time-aligned and phase-coherent mix buses"
I've checked x-32 main, mix, and matrix buses against each other using Smaart, and against a loopback from soundcard.
Purpose was solely to see where I could pull Smaart reference feeds from, feeds that all read the same.......so nothing more than Smaart's pink noise as a signal source.
All buses read the same 0.81ms latency vs looback, and transfers between buses all flat-lined.
Pre post fader, or eq didn't matter. (Of course any x-over filters do matter on matrix or mains)
My guess is that this is all "25 time-aligned and phase-coherent mix buses" is referrring to...
-
re The M32/X32, this was exactly what I thought might be happening, however, faster processing on another console is only going to change the frequency at which the comb filtering would occur. I was slightly alarmed to hear that another user was finding varying latency issues on a channel by channel basis with the A&H D-live.
There is no problems with "varying latency" with the dLive (see the video below), or for that matter any of the other new high ends consoles like the S6L, PM10, Digico's, Midas etc ... or even the M32 or X32, they are all fine.
Sure if you insert a digital effect then the latency will change through that channel - just like it did with an analogue console. Theses effects are simulations of some of the old classic digital and analogue processors and as such they have some additional latency. Midas Pro series for example allows you to add latency to the whole signal chain to compensate for the internal effects (refer attached picture).
Some desks can compensate for the additional latency associated with the A/D and D/A converters used to send the signal in and out of the desk to some outboard gear, but in 2017 its all a bit moot - most things we will be sending to are digital and have unknown additional latency.
Its really just a matter of making sure you don't double up on the signal flow paths when you do things like this.
https://www.youtube.com/watch?v=TCW-GTjF8nM
-
If true, then there's even MORE reason to question why there is both an X32-CORE and M32-C product at different price points. People buying the M32-C over the X32-CORE are probably the same people that pay extra for Oxygen-free Monster cables.
I believe x32-core is discontinued.
Sent from my SM-G930V using Tapatalk
-
I have an instance where it is very clear that the insert latency causes phase issues.
IEM Mix setup: Main L/R = channel 1 on IEM mixer, Vocal = channel 2 on IEM Mixer.
Put an insert on the Main output (say a multiband compressor). The main output signal is now delayed by a few mSec from the unprocessed vocal.
When you mix them together in the IEM mixer, you get a phase misalignment by that few mSec. The bigger the difference, the more easily you can hear it.
Now, I don't do this myself. I only use the L/R bus 6 band PEQ which doesn't add channel latency on my mains.
As pointed out by Peter, all inserts and external efx on analog boards had this issue as well. This is simply inheritance in using this signal path combination. The big difference is that with some digital desks, you can actually account for it and make it go away (pretty cool really).
-
I've checked x-32 main, mix, and matrix buses against each other using Smaart, and against a loopback from soundcard.
Purpose was solely to see where I could pull Smaart reference feeds from, feeds that all read the same.......so nothing more than Smaart's pink noise as a signal source.
All buses read the same 0.81ms latency vs looback, and transfers between buses all flat-lined.
Pre post fader, or eq didn't matter. (Of course any x-over filters do matter on matrix or mains)
My guess is that this is all "25 time-aligned and phase-coherent mix buses" is referrring to...
I just checked my x-32 rack. Sent pink noise from Smaart into a channel, routed that channel to the main left right, and received 1.5ms latency. (0ms with wired loopback) I took that same channel added a send an aux bus, into a fairchild comp (simulating a drum smash) then out the FX return, into the mains. The Effects loop was 2.15ms, and of course when combined with the mains, created a nice comb.
So their definition "phase aligned busses" is clearly not the same as Avids.
-
I just checked my x-32 rack. Sent pink noise from Smaart into a channel, routed that channel to the main left right, and received 1.5ms latency. (0ms with wired loopback) I took that same channel added a send an aux bus, into a fairchild comp (simulating a drum smash) then out the FX return, into the mains. The Effects loop was 2.15ms, and of course when combined with the mains, created a nice comb.
So their definition "phase aligned busses" is clearly not the same as Avids.
I think we ...Peter, Scott, you, me....are all saying the same thing regarding a desk's ability to incorporate external processing into the overall bus latency scheme....doesn't happen unless something truly special is going on.
Does Avid actually account for external processing delay on a channel, and then adjust all buses?
Certainly doesn't happen with an x-32 :)
I have to say something sounds funny with the x-32 times you posted.
IME, if you split the soundcard's output to go to an x-32 channel input and also to the soundcard's input for a reference loopback, .......you should read .81ms.
Something doesn't sound right with 1.5ms. .....too much.
And your 0ms timing has me puzzled too...it sounds like you're pulling reference from an x-32 output????
-
The 0ms was a wired loopback to from soundcard out (reference) to CH1 sound card in. The actual reference was the same path just going back in CH2. So my 0ms was just a double check my testing setup and I would expect 0ms. I can double check my mixer setup again tomorrow, it's possible (and the more I think about it, highly likely) I had GEQ or buss comp on the overall left right. That wouldn't change the combing issue though, just overall latency.
I know Robert Scovill had a really good video explaining how the Venue consoles did latency compensation, and a few tricks to make it work in all scenarios. I can't seem to find it with a quick search from my pocket computer, but the idea allowed you to run parallel wet and dry audio paths within your desk... no truly external (to the desk) processing... and have those paths be latency compensated and summed properly.
Sent from my iPhone using Tapatalk Pro
-
Its possible for avid to compensate but I'm not sure if they do compensate in reality.
All plugins report latency to the desk do it is quite easy for them to compensate for it.
Remember all the processing goes through the TDM HD cards in the old avid consoles and in the HDx cards in the new ones. The desks processor doesn't handle audio at all, everything is done on the FPGA on the HD/HDx cards.
This could add significant delay to the entire desk tough depending on the specific plugin.
Sent from my 2014817 using Tapatalk
-
Here is an old post from the DUC (2005) explaining their delay compensation methods
The various delay compensation options come into play when a signal is routed to a destination via multiple paths - an input assigned to both Mains and a sub-group, and the sub-group is then assigned to Mains, for example. In this case the signals would normally cause combing (phasing) because the path through the group is a few samples longer than the direct path. D-Show's delay compensation takes care of this scenario as follows:
Off
No delay compensation is applied. This mode provides the least amount of latency on all signal paths for any routing scenario. Use this mode if signals are not being routed to outputs via multiple paths - when doing a basic mix of all channels straight to LR, for example.
Mix only
The system compensates for all internal routing delays excluding insert delays for output buses. Use this mode if you're not using any plug-ins, hardware inserts or graphics EQs on the output buses, but you are routing a signal to one or more outputs via mutliple paths.
Mix & Inserts
The system compensates for all internal routing delays plus all insert delays caused by hardware and software inserts on output buses, as well as graphic EQs.
An example of when to use Mix & Inserts mode:
Drums are being routed directly to Mains and also through a sub group routed to Mains, and a compressor plug-in is inserted on the sub-group for some additional "punch". Choose Mix & Inserts mode to ensure the direct signal and compressed bus signal combine properly and don't "phase out".
~Sheldon
Sent from my iPhone using Tapatalk Pro
-
As pointed out by Peter, all inserts and external efx on analog boards had this issue as well. This is simply inheritance in using this signal path combination. The big difference is that with some digital desks, you can actually account for it and make it go away (pretty cool really).
This isn’t strictly true. If you use an analogue console using analogue compressors, gates, tape delays, there is no latency issue. Of course if you inset a digital unit, say on a vocal, this also shouldn’t be a problem and reverbs, as long as they are on sends and you are returning only the wet effect signal also shouldn’t be an issue.
The problems I was talking about are parallel processing, the sort of thing you were mentioning with iem’s and latency introduce on one channel against another due to an inserted plugin.
The point I was making was that as far as I was aware only Avid has end to end compensation. It might well be that others are implementing this and they should, it’s probably the only real issue with digital workflows.
As another aside, I was talking to the other band engineer on the gig last night and he also mentioned that he’d had far more issues with M32’s regarding faders than X32’s. I would have little hesitation recommending an X32, though I’m not a great fan, it offers more at its price point than the competition, you want better, you need to up the budget, but not spend that on the M32, which I feel is seriously overpriced.
-
I think we ...Peter, Scott, you, me....are all saying the same thing regarding a desk's ability to incorporate external processing into the overall bus latency scheme....doesn't happen unless something truly special is going on.
Does Avid actually account for external processing delay on a channel, and then adjust all buses?
Certainly doesn't happen with an x-32 :)
I have to say something sounds funny with the x-32 times you posted.
IME, if you split the soundcard's output to go to an x-32 channel input and also to the soundcard's input for a reference loopback, .......you should read .81ms.
Something doesn't sound right with 1.5ms. .....too much.
And your 0ms timing has me puzzled too...it sounds like you're pulling reference from an x-32 output????
No, the Avid delay compensates only within the console. You could, arguably, add delay to other channels to compensate for either the ad/da conversion delay if using analogue kit or the digital latency if using something like waves server, HOWEVER, the whole deal with the Avid desk is that it is not just using a channel strip, it contains a whole load of plugins that can be used combined with or instead of its general channel eq/compressor/gate and this is automatically compensated for. It was true even a few years ago that most Avid users, just didn’t bother carrying additional outboard as it wasn’t necessary. If you really have that waves plug that you must use, you can route via AVB through a protools rig and in answer to a comment above, the latency on the plugins was even back in the profile days a question of 2-6 samples in most cases. I’m not sure what their end to end latency is on the new S6L, but this should be well within the realms of its competitors and is not going to be an issue for foh.
-
Floating point has no more resolution than integer based when you are talking equal bit depths. Most modern consoles use 24-bit, bit depths which gives 16,777,216 points of resolution within a single value. This is true regardless of whether or not you are using floating point representation or integer values.
-
The point I was making was that as far as I was aware only Avid has end to end compensation. It might well be that others are implementing this and they should, it’s probably the only real issue with digital workflows.
Looks like you can add the PM10 to the list as well.
https://youtu.be/WkoV7lMVmOg
Sent from my iPhone using Tapatalk Pro
-
Floating point has no more resolution than integer based when you are talking equal bit depths. Most modern consoles use 24-bit, bit depths which gives 16,777,216 points of resolution within a single value. This is true regardless of whether or not you are using floating point representation or integer values.
This statement is untrue.
The resolution of the floating point value depends on the mantissa or "value" part of the number. It requires more bits to implement the exponent. Ex: 32-bit float with a 24-bit mantissa and 8 bit exponent is equal in resolution to 24-bit fixed.
Most consoles use 24-bit A/D and D/A but internal processing is higher. The X32 is 40-bit float internally.
-
Looks like you can add the PM10 to the list as well.
As has been mentioned in this thread a few times.
Also all Midas consoles except the M series and also the A&H dLive (but done in a better way).
-
Following all the links and info that has been posted,
makes it appear that 96kHz is more about maintaining timing between coherent signals while minimizing latency,
.........than anything to do with single-signal sound quality. Or so it seems.....
The PM10 vid in one of David's posts, that uses sample counts to illustrate, makes it seem a lot clearer.
Thanks all.
-
This statement is untrue.
The resolution of the floating point value depends on the mantissa or "value" part of the number. It requires more bits to implement the exponent. Ex: 32-bit float with a 24-bit mantissa and 8 bit exponent is equal in resolution to 24-bit fixed.
Most consoles use 24-bit A/D and D/A but internal processing is higher. The X32 is 40-bit float internally.
Yep.
By increasing the internal processing bit depth to a 40 bit float, I suspect that one would maintain all the significant digits and create near infinite dynamic range.... arguably the best of both worlds computationally. Still, performing floating point calculations is more difficult and time intensive. Today's hardware is fast enough that it no longer matters so I suspect we have seen the end of the integer DSP in digital mixers.
-
I think of 96 kHz in sound as being similar to a higher mega-pixel (MP) count in photography (my day job): more usable information if your output can make use of it. A 4x6 at the corner drugstore can only use so many pixels to make the photograph while a 30" x 40" print from a pro lab will use, and show, everything that was captured initially. Along with high MP files comes the need for more processing power in the computer doing the image processing. I assume that a 96 kHz capture device (newish board) would have significantly more on-board processing power than and older 44/48 kHz-capable board would.
Could the more powerful chipset be the reason for the lower latency with a 96 kHz board?
-
It sounds like you might have that backwards.
Sent from my iPhone using Tapatalk Pro
I have become lisdexick with age.
-
Yep.
By increasing the internal processing bit depth to a 40 bit float, I suspect that one would maintain all the significant digits and create near infinite dynamic range.... arguably the best of both worlds computationally. Still, performing floating point calculations is more difficult and time intensive. Today's hardware is fast enough that it no longer matters so I suspect we have seen the end of the integer DSP in digital mixers.
We may have to agree to disagree :) but as i understand it’s not that simple – the resolution you have at the start is 24 bits, the problem occurs (this is overly simplistic) during your processing if you divide an odd number by 2 for example … 3/2 = 1 ½ but you can’t have a ½ in the digital world so you have to round it to 1 or 2 and in doing so you have loss an tiny bit of information.
Sure a 32 bit signal path with an 8 bit exponent (40 bit) gives you huge dynamic range, but it’s not dynamic range that’s the issue (unless you run out of it during your calculations), its accuracy and the less of these rounding errors the better. As I understand fixed point can produce less of these types of errors if done correctly.
This is what Patrick Warrington, Calrec Technical Director said in his paper - "DISPELLING THE MYTH OF THE FLOATING-POINT" that I posted earlier.
(Calrec make very serious Broadcast Consoles https://calrec.com/ they are part of the Audiotonix group which includes Digico, Calrec, Allen & Heath and DigiGrid http://audiotonix.com/ )
“It is an inescapable consequence of the format that as floating-point numbers whiz around the numerical firmament, they deposit little piles of arithmetic ejectamentain their wake. In the interest of balance, I would point out that the errors are, on the whole, quite small, and that for the majority of calculations, they are irrelevant, especially when compared to the more serious threats to quality along the route from microphone to living room. But if we choose to make numerical precision an aim (which we should) then we ought to do it properly and not let the want of a little analysis be a barrier to good science.”
i.e. done correctly there is a very small sound accuracy / quality advantage with fixed point, and similarly with 96kHz. With respect to the 96kHz its mostly about the being able to using anti-alias filters with lower slopes. This results in less phase distortion and smearing in the VHF, giving you a better a stereo image and being less fatiguing to listen to … but we are talking about very tiny differences.
This combination is also very fast and contributes to achieving very low latency - a must for some IEM applications.
-
Floating point has no more resolution than integer based when you are talking equal bit depths. Most modern consoles use 24-bit, bit depths which gives 16,777,216 points of resolution within a single value. This is true regardless of whether or not you are using floating point representation or integer values.
Scott, I don't understand what you are trying to say. You can represent the number of unique values is not the point of bit depth. Bid depth is dynamic range and sample rate drives frequency response.
-
There's always "bignums" AKA Arbitrary-Precision Arithmetic. It's an integer numeric format that expands as needed limited only by available storage. Fun stuff, but admittedly not very relevant to ordinary signal processing. :o -F
-
We may have to agree to disagree :) but as i understand it’s not that simple – the resolution you have at the start is 24 bits, the problem occurs (this is overly simplistic) during your processing if you divide an odd number by 2 for example … 3/2 = 1 ½ but you can’t have a ½ in the digital world so you have to round it to 1 or 2 and in doing so you have loss an tiny bit of information.
Sure a 32 bit signal path with an 8 bit exponent (40 bit) gives you huge dynamic range, but it’s not dynamic range that’s the issue (unless you run out of it during your calculations), its accuracy and the less of these rounding errors the better. As I understand fixed point can produce less of these types of errors if done correctly.
This is what Patrick Warrington, Calrec Technical Director said in his paper - "DISPELLING THE MYTH OF THE FLOATING-POINT" that I posted earlier.
“It is an inescapable consequence of the format that as floating-point numbers whiz around the numerical firmament, they deposit little piles of arithmetic ejectamentain their wake. In the interest of balance, I would point out that the errors are, on the whole, quite small, and that for the majority of calculations, they are irrelevant, especially when compared to the more serious threats to quality along the route from microphone to living room. But if we choose to make numerical precision an aim (which we should) then we ought to do it properly and not let the want of a little analysis be a barrier to good science.”
I just read through all 3 of the articles you listed here…
https://calrec.com/wp-content/themes/calrec/pdf/Myth-of-the-Floating-Point.pdf
http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
http://www.rane.com/pdf/old/note153.pdf
And realized that in each of these articles, they're discussing actual DSP implementations of floating point vs fixed and how the referenced DSP chips can "scale" fixed point using double precision when necessary whereas the floating point chips do not. So, they're saying that doubling the register size in fixed point is better than just using floating point’s built-in scaling.
In a way, this is comparing apples to oranges academically, but apples to apples practically.
My thoughts here were correct then:
What if we think about it in terms of significant digits. If A/D is 24-bit fixed and internal processing is 32-bit float (for example) with a 24 bit mantissa and an 8 bit exponent (ignoring the sign bit for this example), we still have 24 “significant bits”, never more, never less.
The Rane article does a better job of explaining this in an example of 32-bit float vs 24-bit double-precision (48-bit) capable DSPs.
What is required in a floating-point DSP to achieve superior
audio? Here are some pretty nasty “ifs” necessary for floating-point
to overtake fixed-point: if it is a 56-bit floating-point
processor (i.e., 48-bit mantissa plus 8-bit exponent) or 32-bit
with double-precision (requiring a large accumulator), if the
parts run at the same speed as the equivalent fixed-point part,
if they use the same power, and if they cost the same, then the
choice is made.
So my conclusion is this: Yes, floating point is better than fixed point given the float’s mantissa is the same bit width as the fixed point.
However, in practice, fixed point DSPs require less speed and power to achieve the same results by doubling the register width (bit width) used during calculations that need it. Apparently, floating-point DSPs can't as easily scale the bit width as easily.
For the end user of mixing consoles: As long as the console designers have been careful in their DSP design, neither inherently produces better audio quality.
-
Corey,
I agree.
I believe it is easier to write good floating point routines than it is good integer routines (I have done both). The big difference I have found is the computational work load is much higher for FP.
If the hardware can easily handle the work load, then FP will generally result in better routines since the programmer can spend more time making the routine do what they want it to do, and less time worrying about losing resolution by hitting the ceiling or floor.
As for the previous example of dividing an odd number by 2 .....
If you use an integer of 3 (represented as 0000 0000 0000 0011b) and divide it by 2 in integer math you get 1 (shifting the bits right is the same as dividing by 2).
If you do the same exercise in floating point, using the same number of bits, you get 1.5.
In integer math, the way that you typically avoid this problem is that you first multiply by a big number (and a power of 2 so you can use shift left which is very fast) prior to the divide. Of course, the shifting of bits to the left loses significance for big numbers.
As you can see, integer math is very tricky if you want to remain accurate and not lose significance.
-
Scott and Corey,
I agree with what you have said … and my 3 divided by 2 as I said was overly simplistic – for the reason Scott noted but I was just to try to find a simple way to explain how rounding errors can affect things. Both the Rane and Calrec’s papers have much better examples but they are complicated to explain at lounge level.
Cory quoted this from the Rane article:
“What is required in a floating-point DSP to achieve superior audio? Here are some pretty nasty “ifs” necessary for floating-point to overtake fixed-point: if it is a 56-bit floating-point processor (i.e., 48-bit mantissa plus 8-bit exponent) or 32-bit with double-precision (requiring a large accumulator), if the parts run at the same speed as the equivalent fixed-point part, if they use the same power, and if they cost the same, then the choice is made”
What I have been talking about is more or less 40 bit floating point Vs fixed point with a stupid and variable bit depth, more like 72 bit with a 96 bit accumulator and I have ignored cost. In practical terms the sound quality of my Midas Pro 2 Vs my dLive.
In the Rane acritical they noted -
“Floating-point evangelists like to use an example where the processor is set up for 60 dB attenuation on the input and 60 dB make-up gain on the output. Leaving aside the absurdity of this fabricated example, let’s use it to make our fixed-point-is-better point: add a second input to this example, with the gain set for unity, a 0 dBu signal coming in, and configure the processor to sum both these channels into the output and listen to the results — you will not like what you hear.”
In other words it depends on exactly what you are doing as to what attributes are the most important … we don’t do 60 dB of attenuation followed by 60dB of gain but we do add big and very small signals (floating point are not good at this).
The article then goes on to say –
“ Another revealing example is how you never hear floating point advocates talk about low-frequency/high-Q filter behavior. The next time you get the opportunity, set up a floating-point box parametric filter for use as a notch filter with a center frequency of 50 Hz and a Q of 20. First listen to the increase in output noise. Now run an input sweep from 20 Hz to 100 Hz and listen to all the unappetizing sounds that result. Audio filters below about 100 Hz require simultaneous processing of large numbers and small numbers — something fixed-point DSPs do much better than their floating-point cousins”
This example is also given in the Calrec paper and includes some measurements & graphs, but we tend not to do that many high Q notch LF filters, but there are some issues with LF EQ biquad implementations.
There are advantages and disadvantages to both approaches but it depends on what mathematical compromises have been taken as to what the resulting sound quality will be. Its really matters of finding the best overall compromise, latency, sound quality, cost, number of busses etc. On the matter of busses our Pro2 cannot do pre fadder, pre EQ Aux sends because of the limitations in the DSP architecture.
Calrec have implemented their fixed point mathematics using their “Bluefin2 DSP” technology. It uses a variable bit depth and I suspect the A&H being part of the same group have implement similar technology in the dLive which also has a variable bit depth.
The proof is of course - the resulting sound quality. I am aware that at least one company in the UK has done some extensive testing of various consoles measuring THD, noise floors etc. and found that the dLive was the best sounding console they have! My ears are telling the same.
What I love about this discussion is that it is highlighting some of the major things that contribute to the sound of a desk; it’s not just the pre-amps (so over that statement)! To appreciate / test the quality you must be doing a mix, summing inputs and adding EQ, compression, gates etc … listening to an MP3 file through two channels with no EQ will not tell you very much at all.
-
This statement is untrue.
The resolution of the floating point value depends on the mantissa or "value" part of the number. It requires more bits to implement the exponent. Ex: 32-bit float with a 24-bit mantissa and 8 bit exponent is equal in resolution to 24-bit fixed.
Most consoles use 24-bit A/D and D/A but internal processing is higher. The X32 is 40-bit float internally.
That's not what I said. If you are comparing 32 total bits (24+8 as per your example) to 24 total bits, then yes, 32 has more overall resolution. But if you have only 32 or 24 bits total in which to store (or transport) digital information, then they have the exact same number of possibilities with those specific SET amount of bits. As I said a 24-bit value only has 16.7M possible combinations. What values are represented by those bits are irrelevant.
-
Scott, I don't understand what you are trying to say. You can represent the number of unique values is not the point of bit depth. Bid depth is dynamic range and sample rate drives frequency response.
Exactly. Bit depth basically like a Y-axis and sampling rate an X-axis. I was talking about the number of representations with a single 24-bit sample are the same no matter what value is represented by the sample (floating or integer). Min could be 0 while Max could represent 1, and everything in between could be floating point values between zero and one, or they could be whole numbers from 0 to 16,777,215. Either way there are exactly the same number of possibilities given a set number of bits.
Also I understand that processing bits, and algos have nothing to do with transport/storage bits algos. I'm simply saying that a single PCM audio sample will always be limited to amplitude by the number of bits per sample used, and frequency by the number of samples per second used.
-
I think of 96 kHz in sound as being similar to a higher mega-pixel (MP) count in photography (my day job): more usable information if your output can make use of it. A 4x6 at the corner drugstore can only use so many pixels to make the photograph while a 30" x 40" print from a pro lab will use, and show, everything that was captured initially. Along with high MP files comes the need for more processing power in the computer doing the image processing. I assume that a 96 kHz capture device (newish board) would have significantly more on-board processing power than and older 44/48 kHz-capable board would.
Could the more powerful chipset be the reason for the lower latency with a 96 kHz board?
Not really. The lower latency on higher frequency samplerates is usually a function of buffer size on the AD/DA, basically twice the data of 48khz, half the buffer fill up time.
-
Not really. The lower latency on higher frequency samplerates is usually a function of buffer size on the AD/DA, basically twice the data of 48khz, half the buffer fill up time.
More than the buffer I think it is how many samples it takes to do the conversion. At 96k those samples go by in half the time.
Mac
-
More than the buffer I think it is how many samples it takes to do the conversion. At 96k those samples go by in half the time.
Mac
I think we are saying the same thing? Conversion is done in real time, but the chip buffers a fixed data amount, more data throughput, (twice the amount at 96 as opposed to 48) half the time. It’s easily seen when manufacturers produce gear that does multiple sample rates, speed generally halves.
-
My understanding (from my research about external clocks) is that the conversions aren't done at the clock speed, but a multiple of them. Like 4x or 8x oversampling, so even with a console running 48k, the A/D conversions are being done at 192k or 384k, so I don't know that a console that is designed to run at 48k has higher latency JUST because of it's lower clock speed. I don't know for sure, but I think it has more to do with other processing inside the console, not the A/D.
-
My understanding (from my research about external clocks) is that the conversions aren't done at the clock speed, but a multiple of them. Like 4x or 8x oversampling, so even with a console running 48k, the A/D conversions are being done at 192k or 384k, so I don't know that a console that is designed to run at 48k has higher latency JUST because of it's lower clock speed. I don't know for sure, but I think it has more to do with other processing inside the console, not the A/D.
It depends. Some consoles are using fpga’s these process at machine code level and are extremely fast, but programming is far more complex and more so for complex processing. Avid use a pc board (or at least did on Profile), this would be slower. That aside consoles/interfaces that offer multiple sample rates working allow you too see what effect the AD/DA conversion is having on latency. The fact that their published latency figures are close to halved by doubling sampling frequency shows that this is due to buffer speed. Physical processing for audio, although it can be intense with complex algorithms, appears to be much lighter with eq, compression, gating. Waves quote many of their processing plugs in the 3 sample range, next to nothing.