32 Bit Float Explained

[AnalogSteph]

A 32-bit DAC does actually make sense in a digital signal generator. If you do a linearity test running straight undithered 24 bit data into a DAC with a sufficiently narrow filter bandwidth, you will see a telltale ca. -0.6 dB deviation at -120 dBFS that is indicative of 24-bit truncation.

Topping E30 II Lite DAC review and measurements

Here is a review and measurements of the recent Topping E30 II Lite DAC Here you see it on top of the gorgeous Topping A70 Pro, to give an idea of its size. Yes, it's a very small DAC. I purchased it new from Audiophonics for around 100€. This is one of the cheapest DACs with SPDIF inputs...

www.audiosciencereview.com

And so all modern DACs (since about 2013 at the latest) are 32 bit, shifting the problem down by about another 48 dB.

That being said, nobody actually needs more than 24 bits in an audio ADC chip. You can combine all 8 channels in the best ones we've got and you'll still barely make it to 130 dB(A), more than 2 bits worth of good ol' analog noise that'll dither a 24-bit ADC just fine.

 

[earlevel]

A 32-bit DAC does actually make sense in a digital signal generator. If you do a linearity test running straight undithered 24 bit data into a DAC with a sufficiently narrow filter bandwidth, you will see a telltale ca. -0.6 dB deviation at -120 dBFS that is indicative of 24-bit truncation.

Topping E30 II Lite DAC review and measurements

Here is a review and measurements of the recent Topping E30 II Lite DAC Here you see it on top of the gorgeous Topping A70 Pro, to give an idea of its size. Yes, it's a very small DAC. I purchased it new from Audiophonics for around 100€. This is one of the cheapest DACs with SPDIF inputs...

www.audiosciencereview.com

And so all modern DACs (since about 2013 at the latest) are 32 bit, shifting the problem down by about another 48 dB.

That being said, nobody actually needs more than 24 bits in an audio ADC chip. You can combine all 8 channels in the best ones we've got and you'll still barely make it to 130 dB(A), more than 2 bits worth of good ol' analog noise that'll dither a 24-bit ADC just fine.

There is a huge difference between the reality of a 32-bit converter and a DAC that has 32-bit math. Obviously, there is some level of semantics involved, but my point was that ESS claims 32-bit filters and 32-bit attenuation for their converter. At no place I have seen do they claim they are 32-bit converters. The implementer, SSL, claims they are using 32-bit converters.

Again, we could argue semantics on what "32-bit converter" means, but if you have one of these "32-bit" ADCs, they do not supply 32-bit data, so that definition doesn't jibe with how we've historically referred to 8/12/16 bit converters. And if they did supply 32-bit data, you'd have to spec the accuracy as something like "±10 lsb".

At minimum, there is a problem when people buy one of these 32-bit converters and are disappointed that their streaming service only supplies 24-bit music. At best, these are 24-bit converters that—like all state of the art designs—maximize internal operations to ensure they get as close to true 24-bit results as possible. Next, will someone use double precision floating point math, and claim a 64-bit floating point converter?

Anyway, I fault marketing, not engineering. ESS doesn't misrepresent their claims 32-bit, and it's useful for them to say it—it lets an audio component manufacturer know what lengths the chip maker went to, to ensure the best specs. But here the manufacturer using the chip tells the consumer something that is an exaggeration. To be clear, SSL does present their interfaces using these chips as 32-bit, and make it clear that it's a leap from old 24-bit converters. I even asked if they meant 32-bit filters and math, they responded flatly that these are 32-bit converts, eight more bits than 24-bit.

 

[maxotics]

@maxotics: I agree with you that the marketing around 32bit float devices is deceptive and that 24bit is enough to record audio at full quality without clipping (except in some extreme cases).

But I think it's difficult to convey this with somewhat abstract concepts (math/programming). Especially when people observe, in practice, that 24bit recording results in clipping with loud signals, while 32bit float doesn't. This seems to happen with at least some Zoom devices and I think it's just due to the way they are configured by the manufacturer. It boils down to the calibration of the 0dBFS level, which I kinda mentioned before, but I'll try to describe it again.

To simplify it, let's say a recording device can take an analog input of 8V max and that's a hard physical limit for that device. The manufacturer can make it so that, after all the internal processing, 8V input=0dBFS output. That maximizes the SNR for recording with integer bit depths.
Or... he can make it so that 1V=0dBFS, for example. Why? Because that makes quiet signals easier to see and work with, since they have a higher dBFS value. But in that case (1V=0dBFS) you should obviously not use integer bit depths, otherwise the signals above 1V will end up in digital clipping. While with 32bit float, as you know, clipping doesn't happen at 0dBFS, so you can cross 1V with no worries.

I found some other multi-ADC/gain-ranging devices (Stagetec TrueMatch), which seem to record at integer bit depth and therefore have very low digital signal levels. At least this post hints at that:


So 32bit float recording coupled with a lower 0dBFS point just makes this a bit more convenient, that's all. No advantage for audio fidelity, but a potential advantage for usability.
And maybe those devices work at 32bit float internally, so they might save some resources by not converting to 24bit (although I can't imagine that being significant). Or they have some future plans (more DSP? higher dynamic ranges?) and they want to familiarize us with the format.

Anyway, I believe that's kinda how it works, but people are welcome to correct me if I'm wrong.

My math stuff is to explain what I see through testing. What people observe in practice is like a placebo. When I listen to audio with a clipped waveform it sounds more distorted than one with a normal waveform. When you do a honest test, there is no difference. I don't know how to respond to your examples of "1V=0dBFS and ... integer bits". Bits are bits, the difference between 24-bit fixed and 32-bit float is 32-bit float is a calculation of values using a 24-bit (mantissa) and 8 bit exponent (which creates a wider range). The tradeoff is imprecision. If you re-scale to maintain perfect fidelity you're back to the 24-bits. The extra 8-bits add NO extra memory, just scale. So Stagetec TrueMatch cannot argue 32-bit float has a higher integer bit depth UNLESS they use 32-bit fixed! NOT FLOAT. Agree with you, 32-bit float has potential advantages in post, but NOT recording.

Keep in mind my focus in the question of recording microphones in 32-bit float. I just don't see in the real world how they generate more data than 16-bit, let alone 24-bit. And 32-bit float prevents clipping? One can make up all kinds of theories about how it is done, could be done, etc. None of them survive the daylight of real world analog converters and how computers work.

Microphone voltages end up as values NOT mantissa/exponent value pairs. Internally, any recorder saving in 32-bit float CONVERTS from a 24-bit ADC (or something linear, whatever bit depth) to 32-bit float (or anything float), NOT the other way around. I hope I don't sound like I know everything. I don't. It just pisses me off a billion dollar company, Rode, is essentially perpetrating a scientific fraud.

 

[AnalogSteph]

There is a huge difference between the reality of a 32-bit converter and a DAC that has 32-bit math. Obviously, there is some level of semantics involved, but my point was that ESS claims 32-bit filters and 32-bit attenuation for their converter. At no place I have seen do they claim they are 32-bit converters.

Eh? Consider me daft, but I mean it's delta-sigma. You can basically have as many bits as you want. As far as I can tell, 32-bit data goes into the DACs and 32-bit data comes out of the ADCs. Good enough for me!

Their documentation of data formats is quite lacking, but e.g. the AKM AK555x/7x datasheets clearly state 24/32-bit output right on the first page.

Again, we could argue semantics on what "32-bit converter" means, but if you have one of these "32-bit" ADCs, they do not supply 32-bit data, so that definition doesn't jibe with how we've historically referred to 8/12/16 bit converters. And if they did supply 32-bit data, you'd have to spec the accuracy as something like "±10 lsb".

I mean, there's plenty of low-power 24-bit audio ADCs that performance-wise barely even crack 16 bits, sometimes not even that. (Have you seen the USB 24/192 codecs that tend to crop up in fairly inexpensive USB mics, ALC4030 and the like? Something like 90 dB on the ADC side. At least it's a few dBs better than the 16-bit jobs...)

So how would you even determine what is or isn't a "real" 32-bit ADC? Checking for monotonicity might be really slow (even if the highpass filter can actually be disabled), but checking for missing codes seems quite feasible with a sine of an odd frequency not related to fs. It may also be a question of whether you mean 32-bit precision or 32-bit accuracy. The former seems quite attainable, the latter rather not without a super-duper-duper low noise / high stability voltage reference.

 

[earlevel]

Eh? Consider me daft, but I mean it's delta-sigma. You can basically have as many bits as you want. As far as I can tell, 32-bit data goes into the DACs and 32-bit data comes out of the ADCs. Good enough for me!
View attachment 310911
Their documentation of data formats is quite lacking, but e.g. the AKM AK555x/7x datasheets clearly state 24/32-bit output right on the first page.
View attachment 310910
View attachment 310909


I mean, there's plenty of low-power 24-bit audio ADCs that performance-wise barely even crack 16 bits, sometimes not even that. (Have you seen the USB 24/192 codecs that tend to crop up in fairly inexpensive USB mics, ALC4030 and the like? Something like 90 dB on the ADC side. At least it's a few dBs better than the 16-bit jobs...)

So how would you even determine what is or isn't a "real" 32-bit ADC? Checking for monotonicity might be really slow (even if the highpass filter can actually be disabled), but checking for missing codes seems quite feasible with a sine of an odd frequency not related to fs. It may also be a question of whether you mean 32-bit precision or 32-bit accuracy. The former seems quite attainable, the latter rather not without a super-duper-duper low noise / high stability voltage reference.

OK, I had a feeling delta-sigma would be launched back at me by someone

First, even SSL is neither sending (to the host computer from ADC) nor receiving (from the computer to the DAC) 32 significant bits. They aren't 32-bit converters. And as far as I know, neither is ESS processing to 32-bit resolution—I don't think I'm going out on a limb here, despite not taking time to read the spec.

But, you're basically saying, "OK, but a delta sigma chip could be used for 32-bit conversion". That goes beyond what I'm frustrated with—I'm frustrated with the actual claims versus the actual implementation with SSL. But for grins, I'd say it would be in name only. You couldn't resolve 32 bits coming in (DAC), not possible. And you couldn't resolve 32 bits going out (ADC), also not possible. For a bunch of reasons. you'd not only be ay under the Johnson-Nyquist noise, but you'd be into shot noise—I'd be temped to estimate electrons flowing per unit time at the 32-bit extreme if...er, I lost my sanity and thought it was a fun idea.

Let me put it this way: One of the old ways of doing an ADC was successive approximation (laugh, but if we had all the time in the world, a low sample rate, it can be quite accurate, yet you still could achieve 32-bit accuracy even at a 1 Hz sample rate). That is, submitting a guess with DAC, using a comparator to check high or low, and doing a binary search or better till you go it within say a half lsb. Well, do that with a 32-bit DAC, and the low bits would be meaningless, because once you got to about 22 bits, the next 10 bits would be under the noise of the system and it wouldn't matter what you did with them.

So, if you're saying you can go through the motions of implementing 32-bit converters*, again, you'd want to *footnote that the accuracy is within ± 10 bits.

But, I want to stress my post was about marketing. The SSL doesn't do 32-bit conversion in any manner, and relies on converter chips that don't claim to do 32-bit conversion, yet they claim to use "32-bit / 192 kHz AD/DA Converters".

 

[voodooless]

All (or most) 24-bit DACs don’t resolve to 24 bits either.. so 24-bit DACs also don’t exist

 

[BeerBear]

The extra 8-bits add NO extra memory, just scale.

But that scale is important, if you're dealing with the digital signal at around/over 0dBFS.

Agree with you, 32-bit float has potential advantages in post, but NOT recording.

And that's really the crux of the matter with these devices. The line between "recording" and "post processing" is blurred. As I mentioned here and also in some other posts, the "gain" control that they expose to the user is just post-capture digital volume adjustment. But to the end user it looks as if there's some "infinite gain magic" going on, courtesy of the 32bit float format.
I only looked at a short video of a Rode device, but it seems like they're doing something similar when they're demonstrating "no clipping".

So Stagetec TrueMatch cannot argue 32-bit float has a higher integer bit depth UNLESS they use 32-bit fixed! NOT FLOAT.

They do use 32bit integer, I believe. They claim 158dB(A) of dynamic range, for example here and here (although I read somewhere that there's a caveat...).

 

[maxotics]

But that scale is important, if you're dealing with the digital signal at around/over 0dBFS.

Yes. But you agree? That when it comes to recording an analog input, from an ADC, you already know your scale from your reference voltage so you're just playing games in your head if you think it makes a difference where you put your usable ~12 bits of data in the beginning, middle or end of 16,24,32, or 64 bits

And that's really the crux of the matter with these devices. The line between "recording" and "post processing" is blurred. As I mentioned here and also in some other posts, the "gain" control that they expose to the user is just post-capture digital volume adjustment. But to the end user it looks as if there's some "infinite gain magic" going on, courtesy of the 32bit float format.
I only looked at a short video of a Rode device, but it seems like they're doing something similar when they're demonstrating "no clipping".

Yes, I do a video on just that. The purposely put something like a 16-bit output from an ADC out of scale in 32-bit float (that is higher or lower than the software expects it) and then "magically" bring down the "levels" so "clipping" seems removed. One can see the same bs trick with RAW video. RAW video has NO COLOR. What it has is a wider data range than what is expected in rec.709. So they show RAWS 14-bits unnormalized, so to speak, in an 8-bit data space that expects pre-gamut calculated values.. RAW data isn't gray OR super saturated. It's nothing but a recorded electron stream. It's just linear sensor data (like microphones). Everyone wants to look like a filmmaker genius when they re-scale the RAW data into a color space we expect.

They do use 32bit integer, I believe. They claim 158dB(A) of dynamic range, for example here and here (although I read somewhere that there's a caveat...).

As memory prices continue to decrease and what they can do on chips advances why not throw in some extra memory. It is super funny in a way that you can tell someone a big number, like "32" and put a new word behind it "float" and they're packing their bag for Mars

 

[earlevel]

All (or most) 24-bit DACs don’t resolve to 24 bits either.. so 24-bit DACs also don’t exist

That's what I said (twice I mentioned 22 bits—to be generous). However, there is normally an attempt—ladder 24-bit converters (rare as they might be these days) always generated 24 bits via a 24-bit ladder, whether the last few were any good or not. And all types of 24-bit converters return 24 bits. OTOH, SSL touts 32-bit converters—a claim not made by the makers of the parts—while not returning more than 24 bits (AFAIK—it would be awkward considering the audio systems they are connected to typically use a 32-bit float conduit). Isn't that a different thing entirely?

 

[AnalogSteph]

First, even SSL is neither sending (to the host computer from ADC) nor receiving (from the computer to the DAC) 32 significant bits.

Hmm. The ASIO control panel smells of Thesycon driver, I do think that can do 32-bit output (their website lists int32 and float32 support). On Windows you could ask the ASIO Properties dialog in RMAA for the formats supported (e.g. the Realtek ASIO drivers says it supports Int24LSB, while ASIO4All can do Int32LSB).

And as far as I know, neither is ESS processing to 32-bit resolution—I don't think I'm going out on a limb here, despite not taking time to read the spec.

SMSL DO200 MKII DAC Review

This is a review and detailed measurements of the SMSL DO200 MKII stereo USB DAC. It was sent to me by aoshida-audio who is a distributor for SMSL and costs US $469. Not much to complain about here as it fits the latest design of SMSL line. I like the clarity of the LCD and large volume...

www.audiosciencereview.com

(ES9068AS)

Linearity is perfect:

You wouldn't see that without >24-bit precision, IMHO. As mentioned, with plain 24 bit samples or 24-bit truncation you would see a slight droop by -120 dBFS.

Same here:

Measurements of SMSL D400ES ESS9039Pro DAC - L7Audiolab

台式设备 随着一个个项目评审会的结束，我忙乱的日子也开始看到了曙光……前两天双木的晶晶问我，说之前测了D400EX之后怎么没测同时送到的 SMSL D400ES 。我也只能很无奈的说了了期末+之前病休导致的忙乱。无论如何，接下来应该会逐渐拉上测量的频率……

www.l7audiolab.com

The narrowband measurement is up by +0.1 dB by -120 dB purely from remaining noise.

RME provides some "bit test" files for use with their ADI-2 Pro / ADI-2 DAC series devices. Those can check for bit accuracy internally and will display a message if the test passed. They'll only be any good for checking the signal path up to the DAC though.

In REW there is in fact a "Treat 32-bit data as 24 bit" option for ASIO I/O, for devices that will just pad / truncate the data internally. I remember old Envy24 family based cards being good candidates for this... or was it Asus Xonars? In any case they only had int16 or int32 options or something, or int32 was working properly when int24 wasn't (bloody CMedia driver bugs).

Int32 I/O has actually been available far longer than Float32. Envy24 family cards would accept int32 via MME way back in the Windows XP days. I think it was added with WAVEFORMATEXTENSIBLE support (i.e. multichannel and such).

while not returning more than 24 bits (AFAIK—it would be awkward considering the audio systems they are connected to typically use a 32-bit float conduit).

What fundamental difference does it make if software has to perform int16 --> float32, int24 --> float32 or int32 --> float32 conversion? Yes, you could theoretically be losing something during int32 --> float32, but since we have established that there are no audio ADCs with more than an effective 22 bits worth of analog dynamic range, the mantissa will always be plenty. Even on the DAC side, float32 --> int32 is still better than float32 --> int24 when no dithering is involved.

 

[earlevel]

Hmm. The ASIO control panel smells of Thesycon driver, I do think that can do 32-bit output (their website lists int32 and float32 support). On Windows you could ask the ASIO Properties dialog in RMAA for the formats supported (e.g. the Realtek ASIO drivers says it supports Int24LSB, while ASIO4All can do Int32LSB).

SMSL DO200 MKII DAC Review

This is a review and detailed measurements of the SMSL DO200 MKII stereo USB DAC. It was sent to me by aoshida-audio who is a distributor for SMSL and costs US $469. Not much to complain about here as it fits the latest design of SMSL line. I like the clarity of the LCD and large volume...

www.audiosciencereview.com

(ES9068AS)

You wouldn't see that without >24-bit precision, IMHO. As mentioned, with plain 24 bit samples or 24-bit truncation you would see a slight droop by -120 dBFS.

Same here:

Measurements of SMSL D400ES ESS9039Pro DAC - L7Audiolab

台式设备 随着一个个项目评审会的结束，我忙乱的日子也开始看到了曙光……前两天双木的晶晶问我，说之前测了D400EX之后怎么没测同时送到的 SMSL D400ES 。我也只能很无奈的说了了期末+之前病休导致的忙乱。无论如何，接下来应该会逐渐拉上测量的频率……

www.l7audiolab.com

The narrowband measurement is up by +0.1 dB by -120 dB purely from remaining noise.

RME provides some "bit test" files for use with their ADI-2 Pro / ADI-2 DAC series devices. Those can check for bit accuracy internally and will display a message if the test passed. They'll only be any good for checking the signal path up to the DAC though.

In REW there is in fact a "Treat 32-bit data as 24 bit" option for ASIO I/O, for devices that will just pad / truncate the data internally. I remember old Envy24 family based cards being good candidates for this... or was it Asus Xonars? In any case they only had int16 or int32 options or something, or int32 was working properly when int24 wasn't (bloody CMedia driver bugs).

Int32 I/O has actually been available far longer than Float32. Envy24 family cards would accept int32 via MME way back in the Windows XP days. I think it was added with WAVEFORMATEXTENSIBLE support (i.e. multichannel and such).

What fundamental difference does it make if software has to perform int16 --> float32, int24 --> float32 or int32 --> float32 conversion? Yes, you could theoretically be losing something during int32 --> float32, but since we have established that there are no audio ADCs with more than an effective 22 bits worth of analog dynamic range, the mantissa will always be plenty. Even on the DAC side, float32 --> int32 is still better than float32 --> int24 when no dithering is involved.

I'm sorry, that's just too hard to read (and I'm time-constrained), I don't know what to respond to.

I'm not sure what you're arguing—I don't know if you're saying these ESS converters are really 32-bit, and deal meaningful 32-bit data, or that they are not 32-bit and deal 32-bit data anyway, or that someone could make a real 32-bit converter that deals 32-bit data even if ESS doesn't, or that someone could deal meaningless 32-bit data.

Could you tell me whether you disagree with my SSL/ESS assertion, or my assertion that 32-bit converters are not possible?

I'm not sure what you're background is, maybe I could frame things better. "AnalogSteph"—if that means you're an analog circuit designer, or work with and test a lot of analog gear, you might have a good idea of the lowest noise floor possible. If so, I might suggest that the lowest bit of a 32-bit converter that outputs +4 dBV at full scale, accounting for signed output is 2^-31 x 4 dBV, or 0.000000000738 volts if I didn't screw up, 0.7 nanovolts—less than a billionth of a volt. Johnson-Nyquist noise voltage of a 1k ohm resistor at room temperature, 20 kHz bandwidth, is 569 nV RMS (-125 dBV).

Do you see how it might be a problem in getting 24 true bits, much less 32, another 48 dB down?

 

[AnalogSteph]

Could you tell me whether you disagree with my SSL/ESS assertion, or my assertion that 32-bit converters are not possible?

We are 100% in agreement when it comes to the value added in going from 24 to 32 bits (which is nil on the ADC side and very little on the DAC side, and that very little is going away entirely when playing actual music material at any sensible level of attenuation). I'll gladly be recording with a 20-year-old 24/192 AK5394A any day of the week. (Particularly when it has to go straight to 44.1 for whatever obscure reason. The filters on a lot of modern ADCs kind of suck, and I'd even prefer running the current AKMs at 352.8/384 kHz.)

That being said, I don't see what would make a 32-bit converter impossible. As previously stated, Delta-Sigma is kind of flexible. If in doubt you'll just get 8 more bits filled with noise - so what. You could even make a 64-bit one if you insisted, silly as it may seem. (I know - shh, don't give them any ideas. ) It's like with Rob Watts and his 300 dB digital filters, it's silly and there is zero practical benefit but it is doable.

(Incidentally, I won't be too surprised if we start seeing composite ADCs on a chip eventually, complete with additional +/-15 V analog supplies. It would have to be at least a 2-die affair and may not be worth the hassle after all, but still. Analog dynamic range extension already is a thing right now. We may or may not see monolithics crack 24 bit @ single speed level eventually... we've been stuck in the 120s for what seems like ages now, and recording the entire dynamic range of a low-noise LDC mic at once isn't exactly a mainstream killer app.)

Now you were accusing SSL of misleading advertising with their 32/192 converters, and notwithstanding the fact that such a thing has definitely never happened once in the entire history of advertising (), I can find zero indications of that being the case:

1. The converters are about as 32 bits as it gets these days, with up to 32 bit samples going in and out and linearity measurements of other ESS-based DACs indicating that they are in fact >24 bits. Yes, the same converters that have "32 bit" plastered all across the first datasheet page, at least 4 times.
2. There is a good likelihood of there actually being a 32-bit data path to the interface. (It's pretty common these days, even basic ubiquitous $100 class XMOS-based DACs will ofer 32-bit output.) If not, that would be 100% testable on the DAC side with a linearity measurement.

Incidentally, among all the midrange/high-end DAC chips that have been newly released in the last 10 years, there is not a single one that isn't 32-bit capable. The first came out as early as 2009. For ADCs the switchover was a bit later, about 2014-15. (Good thing I have a table for that. )

 

[earlevel]

That being said, I don't see what would make a 32-bit converter impossible. As previously stated, Delta-Sigma is kind of flexible. If in doubt you'll just get 8 more bits filled with noise - so what. You could even make a 64-bit one if you insisted, silly as it may seem. (I know - shh, don't give them any ideas. ) It's like with Rob Watts and his 300 dB digital filters, it's silly and there is zero practical benefit but it is doable.

Again, maybe it's semantics, but if someone proudly announced, "I've done it! I've made a 64-bit audio DAC and ADC!", and you said, "Amazing! What's the accuracy?". And they replied, "±42 lsb!". You'd be OK with that, and call them 64-bits converters? We can disagree on this. I'm an old-timer electrical engineer, if a converter wasn't within about ± half an lsb, it simply wasn't the claimed resolution. For 32-bit, the bottom eight would be a Gaussian noise generator—I don't understand the "so what" part of that.

Now you were accusing SSL of misleading advertising with their 32/192 converters, and notwithstanding the fact that such a thing has definitely never happened once in the entire history of advertising (), I can find zero indications of that being the case:

1. The converters are about as 32 bits as it gets these days, with up to 32 bit samples going in and out and linearity measurements of other ESS-based DACs indicating that they are in fact >24 bits. Yes, the same converters that have "32 bit" plastered all across the first datasheet page, at least 4 times.
2. There is a good likelihood of there actually being a 32-bit data path to the interface. (It's pretty common these days, even basic ubiquitous $100 class XMOS-based DACs will ofer 32-bit output.) If not, that would be 100% testable on the DAC side with a linearity measurement.

Incidentally, among all the midrange/high-end DAC chips that have been newly released in the last 10 years, there is not a single one that isn't 32-bit capable. The first came out as early as 2009. For ADCs the switchover was a bit later, about 2014-15. (Good thing I have a table for that. )

Well, maybe ESS does claim 32-bit, though when I've looked I see the 32-bit attributed to processing (32-bit filters, 32-bit gain). If they claim outright 32-bit conversion, they are not being fully honest. You can't settle out a 32-bit reading if the bottom 8 bits are below they noise level. <shrug>

(Incidentally, I won't be too surprised if we start seeing composite ADCs on a chip eventually, complete with additional +/-15 V analog supplies. It would have to be at least a 2-die affair and may not be worth the hassle after all, but still. Analog dynamic range extension already is a thing right now. We may or may not see monolithics crack 24 bit @ single speed level eventually... we've been stuck in the 120s for what seems like ages now, and recording the entire dynamic range of a low-noise LDC mic at once isn't exactly a mainstream killer app.)

I appreciate your detailed reply, but some of your comments, including this, make me feel that you either didn't fully read my post you replied to, or you don't believe there is such a thing as Johnson-Nyquist noise and others. Are you implying ("stuck in the 120s for what seems like ages now") that we can hope to be in the 130s? (140s?)

I'm not sure what you think we're going to do with the thermal noise. And if we could suspend that law of nature (assuming it would do any good when we couldn't hear it), there's shot noise down a bit further. That's strictly a numbers game, you're cutting the number of electrons per given time interval in half for each additional bit. A a point, it begins to matter a whole lot that you can't flow a fractional charge.

 

[antcollinet]

Again, maybe it's semantics, but if someone proudly announced, "I've done it! I've made a 64-bit audio DAC and ADC!", and you said, "Amazing! What's the accuracy?". And they replied, "±42 lsb!". You'd be OK with that, and call them 64-bits converters? We can disagree on this. I'm an old-timer electrical engineer, if a converter wasn't within about ± half an lsb, it simply wasn't the claimed resolution. For 32-bit, the bottom eight would be a Gaussian noise generator—I don't understand the "so what" part of that.


Well, maybe ESS does claim 32-bit, though when I've looked I see the 32-bit attributed to processing (32-bit filters, 32-bit gain). If they claim outright 32-bit conversion, they are not being fully honest. You can't settle out a 32-bit reading if the bottom 8 bits are below they noise level. <shrug>


I appreciate your detailed reply, but some of your comments, including this, make me feel that you either didn't fully read my post you replied to, or you don't believe there is such a thing as Johnson-Nyquist noise and others. Are you implying ("stuck in the 120s for what seems like ages now") that we can hope to be in the 130s? (140s?)

I'm not sure what you think we're going to do with the thermal noise. And if we could suspend that law of nature (assuming it would do any good when we couldn't hear it), there's shot noise down a bit further. That's strictly a numbers game, you're cutting the number of electrons per given time interval in half for each additional bit. A a point, it begins to matter a whole lot that you can't flow a fractional charge.

Replying so I can like this twice.

 

[voodooless]

I still don't see the point.. when has an audio DAC ever been advertised with its actual measurable resolution? It's just not done. The datasheets contain plenty of information about its actual performance. Read those, and you'll be fine, regardless of the amount of bits written on the box. And remember, that technically, these things aren't even 16-bit DACs: they are multilevel delta-sigma, I think the ESS DACs are like 6 levels?

 

[AnalogSteph]

Yep, multibit delta sigma with dynamic element matching, with plenty of oversampling + noise shaping. The upsampling / decimation is all digital, so you can go in/out with just about as many bits as you want. And if memory serves, the (audio band) modulator noise level of high-end DACs is a good bit below their analog thermal noise these days.

BTW, the award for the most ludicrously "bit-drenched" converter goes to this mobile codec intended for BT headsets and such (the Presonus Audiobox GO uses it - I was honestly surprised not to see a 1-chip USB solution):

TSCS25xx - Tempo Semiconductor

Ultra-Low Power Audio CODEC The TSCS25xx is a low-power, high-fidelity integrated CODEC with 32-bit stereo playback / stereo record functionality with integrated stereo true capless headphone amplifiers. The two digital audio data interfaces (I2S / LJ / RJ) supports both master or slave modes...

temposemi.com

ADC dynamic range is - hold on to your hats - a whopping 90 dB(A). That's 17 out of 32 bits worth of noise. (Obviously it's still just fine for the intended application, which will generally be recording voice on a MEMS mic / electret capsule. The Audiobox GO sensibly is "only" making use of 24 bits.)

I guess 32 bits these days is like support for RGB headers on PC motherboards. It comes standard almost anywhere, whether you need it or not.

 

[maxotics]

For 32-bit, the bottom eight would be a Gaussian noise generator—I don't understand the "so what" part of that.

Or six engines of the SpaceX Starship Gaussian explosion generators. I know that sounds completely off topic and irrelevant. Or bottom eight bits of mRNA vaccine side effects unimportant because people are dying and that's the only data that matters. We've moved from GIGO to MAPA--I make up here, on the fly, "Memory Added, Progress Achieved". No one worries as more and more carbon is released into the atmosphere because we'll learn how to program a device with "Quantum Mechanics 1,024 Terabyte Quadra Phase, Duel Linear, Multi-Variate Memory" (or whatever they'll market it as) that will remove C02 digitally from the planet.

I smirk a little when people say we (say my wife) notice a difference between 8-bit and 16-bit audio. I roll my eyes at 24-bit vs 16-bit. At 32-bit--I get scared. When society gets detached from reality people end up burned at the stake. Again, I go off topic. Then again, I don't think I could be any more ON TOPIC for some of us here.

 

[KMO]

I guess 32 bits these days is like support for RGB headers on PC motherboards. It comes standard almost anywhere, whether you need it or not.

Well, it's the next common step after 16 bits.

To have anything in between 16 and 32 is only going to happen on dedicated audio circuitry, but general-purpose computation doesn't bother with non-power-of-2 data units.

To a large extent the increasing prevalence of 32-bit data paths, whether it be integer or float, is because there's a move towards general-purpose computation rather than custom audio DSPs. If you want more than 16 bits, then you're going to get 32 bits.

I myself have some silly embedded thing I'm doing now where I'm filling a 32-bit buffer with 18-bit data. Setting my I2S interface to 32-bit mode and doing all processing as 32-bit is by far the easiest thing to do. It's either that or round it down to 16-bit.

 

[maxotics]

o a large extent the increasing prevalence of 32-bit data paths, whether it be integer or float

32-bit float is rescaled 24-bit fixed data into a wider imprecise data space. 32-bit float is a stored calculation; that is, Number^Exponent. Show me any analog electronics that output in numbers and exponents Certainly, 32-bit float is becoming the norm in audio electronics/DAWs, etc., but only because it's easy for computers to work with. In the end, (under the hood) it's converted down to 24-bit fixed when anything is put into it or taken out.

 

[BadAudioAdvice]

I sent my MixPre3-II to @amirm for testing. As a Mac user, I am not familiar with using ASIO drivers in Windows. I have a $150 Windows11 laptop that I tried to install and test the MixPre before sending it to Amir, but could not get the ASIO drivers working, so I suggested that he just use it in plug-and-play mode, which limits it to 24bit/96Khz. It is very likely that it was my unfamiliarity with Windows that was why I couldn't get it to work.

Given the discussion in this thread, it seems that it would be good if Amir could use the ASIO drivers to enable 32-bit capture for his testing?

https://www.sounddevices.com/asio-driver-for-mixpre-ii-series/