• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). Come here to have fun, be ready to be teased and not take online life too seriously. We now measure and review equipment for free! Click here for details.

[solved] RME Adi-2 Pro FS (AK4490 DAC): positive sample values are always offset by -1 !

KSTR

Active Member
Joined
Sep 6, 2018
Messages
252
Likes
589
Location
Berlin, Germany
#1
Disclaimer: the issue I found has absolutely no effect on audio signal quality. This is only interesting for some specialist measuring applications.

I just made an interesting discovery while I was doing some low-level loopback measurements to check true (noise-less) 24-bit output depth of the RME's AK4490 DAC chips.

While it turned out the DAC-chip actually does output all bits down to the LSB and is pretty linear (as expected from a Delta-Sigma design) it looks like either the DAC-chip or the RME firmware are reducing all incoming positive (>0) sample values by one. This means a value sample sequence of, say, -2,0,1,0,2,3 gives -2,0,0,0,1,2.

The only reason I can think of why one would do that is the polarity inversion option the chip / device offers. Since the negative range of values is one larger that the positive range in the two's complement number system (like 8 bits go from -128 to +127), the largest negative value cannot be inverted (would give the same value, causing a nasty glitch in the output). By lowering all negative value magnitudes by one LSB, this problem would be avoided, though not in the smartest way (which would be to simply saturate negative values at -127, in the 8-bit example). It would also mean the DAC runs inverted in the RME and the analog section does another inversion to restore polarity? Hhm....


You might ask how this can be measured if the lowest 4...5 bits are buried in the noise?
Time-domain sample-synchronous averaging is answer here, in this case almost 30,000 block were averaged which gives a best-case attenuation by a factor of sqrt(30,000)=173 (=45dB) for any fully uncorrelated signal.

Test Setup:
- DAC output ref level +24dBu
- ADC input ref level +4dBu (so we have 20dB gain here to factor out the ADC influence. In the display this 20dB gain is corrected for, of course)
- XLR loopback cable
- 44.1kHz, 24bit (bit-identity checked with RME "bittest".wavs
- DAC filter NOS, ADC filter SLOW (choice of filters turned out to be irrelevant)
- Sample sequence was 1, 0,-1, 0, 2, 0, -2, 0, 3, 0, -3, 0 and so forth up to 16, 0, -16, 0. Each value is repeated 20 times.

The top trace is the input data for the DAC, the bottom trace is the result of the block averaging on the recorded data:
full.gif

Yikes, the very first "+1" sample train simply does not exist! And at closer inspection we find all positive values are one lower than they should be.


Zooming in on the first few values:
zoomed.gif

This confirms the -1 offset for all positive values and also explains the zero values not being zero but shifted up a fraction of a bit (time integral must be zero, there are at least two highpasses in the ADC chain -- and none in the DAC, btw).

Doing a web search and studying the RME manual and AK4490 spec sheet I find no hints to this behavior.
This all is of course completely irrelevant for audio reproduction but for those who use the Adi-2 Pro as a measurement front-end this might be relevant. Notably if you set up a LSB-toggling (0/1) test and wonder why the LSB isn't toggling at all or why you get a different result when toggling (0/-1).
 

pos

Senior Member
Patreon Donor
Joined
Feb 13, 2018
Messages
342
Likes
324
#2
Hello KSTR

I think this due to the internal float/integer conversion: there are several ways of mapping the symmetrical [-1;+1] float range to the asymmetrical [-2^23-1;+2^23] 24bit signed integer range, and none is perfect.
Many implementations will map it to a [-2^23-1;+2^23-1] range to keep it symmetrical, and this is probably what RME does here.
 

KSTR

Active Member
Joined
Sep 6, 2018
Messages
252
Likes
589
Location
Berlin, Germany
#3
True, but there is no format conversion in place in this specific test, at least none that I'm aware of. I'll check back with RME if any mapping of this kind in their firmware...
 

pos

Senior Member
Patreon Donor
Joined
Feb 13, 2018
Messages
342
Likes
324
#4
There is a volume control and an internal DSP, so maybe they have a int/float/int conversion in place even when volume setting is at 0dbFS and no EQ is engaged?
 

KSTR

Active Member
Joined
Sep 6, 2018
Messages
252
Likes
589
Location
Berlin, Germany
#5
That's indeed a possibility but I'm inclined to call it a bug if so. Distortion at very low signal levels (with noise factored out) would be compromised, this is an unneccesary zero crossing error of sorts. I need to measure this, with and without offset correction and see if it makes a change....
 

KSTR

Active Member
Joined
Sep 6, 2018
Messages
252
Likes
589
Location
Berlin, Germany
#6
OK, here we go (sorry for the monster post)...

I was succesful in repeating the measurement, now using a very low level sine @-128dBFS, checking waveform integrity and distortion, plus I did a simulation of the offset error to verify that what I see is really due to this processing glitch (all positive sample values >= +1 are reduced by 1, somewhere in the DAC's processing chain, inside the device).

0) Test setup:
- Win7 laptop with Adi-2 Pro FS attached via USB.
- Player : Foobar2000 via ASIO, all processing turned off, verfied with RME "bit-test" files which of course is paramount.
- Recorder : Adobe Audition via ASIO.
- Some written pieces of C code to generate the test signal and do the block averaging.
- Interface : RME Adi-2 Pro FS, 44.kHz/24bit, DAC and ADC filter "sharp", all processing off (!), level +24dBu, ADC input gain 20dB, XLR-loopback cable

1) Signal generation:
A pure sinewave sample block of 4409 samples length (prime, for self-dithering!) containing 100 sine periods (~1kHz) was computed, in 64 floating point. Magnitude was set to 4 refered to a 24bit depth, giving an equivalent sample value span from -4 to 4, ~-128dBFS peak levels. This was looped until the total size was 70544 to have room for nice 64k FFT. Looks like this:
low_level_sine(floating_point).gif

As perfect as it gets, even with "only" 32 bit floating point precision within Audition.


After conversion to 24 bits with 1 bit of dither (no noise shaping) things change wrt noise floor, as to be expected:
low_level_sine(24bit+dither).gif

Samples are bouncing around zero +-6 samples but purity is uncompromised. Looks like a very valid test signal for distortion to me.


2) Emulation of the RME offset error:
I emulated the RME's behavior and lowered all positive samples of the test signal by 1 which adds the distortion pattern just like the real device. The signature found is of the same type as in the initial test, and the distortion impact very visible in both domains:
low_level_sine(24bit+dither)+RME-emulation.gif



4) Loopback measurement with real device:
First we look at the raw recording which took over 15 minutes to record more than 9000 blocks with 4409 samples per block. Note the input gain of 20dB (to remove/reduce any ADC error), lifting the peak magnitude to -108dBFS as seen by the ADC:
sine(RME_loopback-response_raw).gif

The 1kHz pattern is not very easy to find in this sea of analog noise. The spectral line is 20dB above noise floor and within that range no distortion is apparent, if any it must be under the noise floor. This makes clear we are dealing with a very low level problem completely irrelevant for music playback and any typical measurement tasks users may perform with this excellent RME interface.

5) Block Averging to reduce the uncorrelated noise.
Block averaging over 9000 sample blocks (15 minutes of recording) gives close to 40dB noise reduction and by this we can extract strongly signal-correlated distortion way down in the noise:
sine(RME_loopback-response)+Block_Averaging.gif
he
Yikes, the 40dB noise improvement peels out the suspected distortion very clearly!
I did not expect this level of pattern matching compared to #2 plot. The wave shape sure looks a bit more triangular that it should and the train of harmonics tell the same.


6) OK, now that we have nailed it, can we really correct it?
Yes, by applying an inverse pre-distortion as compensation for the error by increasing all sample values >=1 by 1 in the test signal I could restore the ouput signal to what it is supposed to look like, again with the same parameters for the block averaging:
corrected_sine(RME_loopback-response)+Block_Averaging.gif

Again, I did not expect that level of signal quality. Mind you, the DAC is toggling +-6 LSBs (~ lowest four bits of 24), playing a -128dBFS sine buried in its own output noise and there is no visible distortion from the whole loopback chain! This is only possible with good Sigma-Delta converters and both the DAC (AK4490) and the ADC (AK5574) seem to perform top notch with regard to their true linearity once they're fed with correct data.

------------------------------------

7) Conclusion:
While the issue is quite certainly irrevelant in practice for any audio record/playback and typical measurement tasks, it was found that this 1 LSB asymmetric offset error, as discovered in the first post, really exists and causes additional distortion when effective noise reduction methods are used to look at distortion components below the analog noise floor. If matters for a specific measurement task, pre-correction of the test signal is easy, though.
If anything, it demonstrates the power of heavy sample-synchronous time-domain block averaging.
 

restorer-john

Major Contributor
Joined
Mar 1, 2018
Messages
2,519
Likes
4,155
Location
Gold Coast, Queensland, Australia
#7
Very interesting investigation. Zero cross error basically mean the D/A is now officially a 31 bit D/A converter...
 

solderdude

Major Contributor
Joined
Jul 21, 2018
Messages
2,725
Likes
4,434
Location
The Neverlands
#8
Seems like a firmware update could most likely correct for this ?
I assume you contacted RME about this ?
Is this only happening in the RME or also seen in other 4490 applications ?
 

KSTR

Active Member
Joined
Sep 6, 2018
Messages
252
Likes
589
Location
Berlin, Germany
#10
Yep, I'll contact them, now that some more data is available which really seems to back up the observation.

EDIT: I'll do another series of tests first with a more realistic signal level for the 1kHz test signal, like -60dBFS which seems to be used often to check low-level distortion, and try different frequencies, higher frequencies should be more prone to develop significant distortion whereas higher signal levels should reduce relative error proportionally so that the absolute levels of the harmonics should stay still under the noise floor... we'll see.
If I find the issue is dominating any distortion seen in non-averaged conditions I think RME should take action. Otherwise it is pretty much academic but a remedy for this erratic behavior would be appreciated at any rate.

I'm aware there still is a residual risk of "user error" from my side, that's why I'd love to see if somebody could back it up with their Adi-2 or Adi-2 Pro. I can share the C sources and win32-executables as well as more detailed info on the processing if that is of any help. EDIT: Adi-2 or any other DAC-only device will be harder to test because an external ADC is required and it's much harder to get ultra-precision sample-synchronous record-while-playback which is required for the heavy averaging not to skew the data from small short-term drifts and jitter.

I don't have any other 4490-equipped DAC so I can't say if this is a chip quirk. IMHO, chances are much higher for it to be a pre-processing issue in the RME firmware.
 
Last edited:
Joined
Jun 14, 2018
Messages
19
Likes
43
Location
Heidelberg, Germany
#12
What about feeding the DAC with a -1/0/+1LSB signal and looking at the SDATA input of the AK4490 using a DSO? This would answer the question whether this bug resides in the AK4490 or in the DSP …
 

mansr

Addicted to Fun and Learning
Joined
Oct 5, 2018
Messages
523
Likes
1,255
Location
Hampshire
#13
I don't have any other 4490-equipped DAC so I can't say if this is a chip quirk. IMHO, chances are much higher for it to be a pre-processing issue in the RME firmware.
I'd start by checking the values on the I2S input to the DAC chip. Maybe you've found the secret to the "VELVET SOUND" from AKM.
 

KSTR

Active Member
Joined
Sep 6, 2018
Messages
252
Likes
589
Location
Berlin, Germany
#14
Inspecting I²S means opening the case which breaks a warranty seal, I wanted to avoid that as long as possible.
Also, gut feeling tells me it's not AKM... we'll see...
 

KSTR

Active Member
Joined
Sep 6, 2018
Messages
252
Likes
589
Location
Berlin, Germany
#15
I've tried different frequencies and levels (with the emulator) but it seems the absolute levels of the harmonics brickwall at about -150dBFS, still below noise floor. However, I noted that some harmonics of higher test frequencies (6kHz) get mirrored down. This, together with the IMD distortion seen with actual music signals, definitely creates some form of nasty hash, eg correlated noise. Being that low in level buried in the analog noise floor, though, I would personally doubt this could ever be audible. OTOH, people are discussing the sound differences from different 1-bit dither algorithms with 24bit data.
Anyway, this 1 LSB asymmetric offset error could easily be set up for blind testing if anybody wanted to really do this.
 

KSTR

Active Member
Joined
Sep 6, 2018
Messages
252
Likes
589
Location
Berlin, Germany
#17
Good idea. Actually, the processed digital stream sent to the DAC-chip can be monitored on the digital outs as an option, but only in 2-channel mode where analog inputs are the only accessible through USB but no digital inputs, a pity. For this I'll need to hook up an indepedant AES/SPDIF-recorder (2nd PC with another soundcard). Either that, or use my AP which is not in the house atm, though...
 

KSTR

Active Member
Joined
Sep 6, 2018
Messages
252
Likes
589
Location
Berlin, Germany
#19
RME (Matthias) responded at their forum and wrote the issue is already known and will be settled in the next firmware where the whole output path processing/routing will be redone.

And I have to correct my statement of monitoring the rendered DSP output in multichannel, it is possible (RTFM, looking at the diagrams alone doesn't suffice ;-)

Doing so, I could confirm the error isn't there which means the topic is a bit more complex than excpected, that is, the DSP renderer's output is correct (no error seen) but the actual feed to the DAC chip is not.

Anyway, the issue will be settled in the next firmware and that's why RME is such a great company, the do care about their stuff and customers.
 

Music1969

Addicted to Fun and Learning
Joined
Feb 19, 2018
Messages
615
Likes
175
#20
RME (Matthias) responded at their forum and wrote the issue is already known and will be settled in the next firmware where the whole output path processing/routing will be redone.

And I have to correct my statement of monitoring the rendered DSP output in multichannel, it is possible (RTFM, looking at the diagrams alone doesn't suffice ;-)

Doing so, I could confirm the error isn't there which means the topic is a bit more complex than excpected, that is, the DSP renderer's output is correct (no error seen) but the actual feed to the DAC chip is not.

Anyway, the issue will be settled in the next firmware and that's why RME is such a great company, the do care about their stuff and customers.
Great investigative work by you.

And fantastic support by RME as you say.
 
Top Bottom