Print

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

[Scott Bolt]

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.

[Peter Morris]

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

[Corey Scogin]

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, 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.

[Frank Koenig]

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

[Roland Clarke]

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.

[Frank Koenig]

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

[Andrew Broughton]

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.

[Tim McCulloch]

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.

[Peter Morris]

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.

[Peter Morris]

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...

[ProSoundWeb Community]