Tír Na HiFi

I came across this back in 2010 as I was corresponding with the person who uncovered this issue, Raymond Celius, known as RayCtech on many forums.

The problem is related to how 16bit audio is extended to 24 bit or 32 bit. This is needed when sending a 16 bit audio file to a 24 or 32 DAC - which most are nowadays.

The standard way I2S is encoded at the bit level is in something called two's complement representation. http://en.wikipedia.org/wiki/Two's_complement

Two's complement coding is used because it can represent positive & negative numbers which are needed for audio that comprises of positive & negative waves. So in two's complement the first bit, the most significant bit (MSB) represents the sign of the number, 1 meaning negative & 0 meaning positive (MSB is on the left) (LSB is on the right = least significant bit)

So here's the problem - when changing a 16bit number in 2's complement into a 24 bit number the standard approach is to add 8 0's to the end irrespective of whether the number is positive or negative so:
1111 1111 1111 1111 (a neg number) under I2S becomes 1111 1111 1111 1111 0000 0000 0000 0000 - which is incorrect.
The correct way of doing it should add 0's to positive numbers & 1's to negative numbers so:
1111 1111 1111 1111 in correct 2's comp 1111 1111 1111 1111 1111 1111 1111 1111 - which is correct


The result of this mistake is that all negative numbers when converted are incorrect & therefore the negative going waveform that is generated based on these values are incorrect i.e our analogue waveform is incorrect.

How much is it off by?
Well 1 LSB is the answer.
What does this translate into? 1 LSB translates into 6dB which when the sound is loud is not much to worry about but in quieter passages & in fades of notes, it is something we should be concerned with.
Why haven't DAC chip manufacturers addressed this? Who knows?

No DAC manufacturer that I know of has implemented this correction except for Light Harmonic with their auto-LSB correction.

What can be done? Well we can correct this outside of the DAC in software.

I have spoken to Gordon & he is looking into doing this at some point on MQN. I hope LEKT reads this & might incorporate the correction in his software player. It's actually an easy correction - do a conditional bit-stuffing based on the sign of the number i.e if MSB is 1 then stuff the extra bits with 1s - if MSB is o then stuff with 0s

I would be interested in hearing the effect of this correct approach & how audible it might be.

Isn't digital audio fun? :)

Just to explain further:
The only bit of that Wiki entry that is relevant is this bit

When turning a two's-complement number with a certain number of bits into one with more bits (e.g., when copying from a 1 byte variable to a two byte variable), the most-significant bit must be repeated in all the extra bits and lower bits.
Some processors have instructions to do this in a single instruction. On other processors a conditional must be used followed with code to set the relevant bits or bytes.

If this isn't done correctly i.e negative values are padded with 0s instead of 1s then we have an error of 1bit (in the least significant bit) on all negative values. What this means is that with loud signals it probably isn't noticeable but with quieter signals & fades of instruments it probably will be noticeable.

I'm interested in hearing how this sounds when fixed

Its more of a DAC implementation issue rather than I2S is broken. I2S can be used to transport data types other than twos complement especially if there is additional processing done before the final dac stage. This is why the data type handling is usually done in the software and the I2S link be kept data independent. But the majority is twos-comp so there is certainly an argument for making the transmitter/receiver aware of it.
Such a shame though that I2S never really caught on in commercial hifi such as external DAC's. It's more suited to inter-chip comms as the standard doesnt specify what cabling should be used for the 3 signals. Hence why you get many different ways of using I2S over cables.

DaveF wrote:Its more of a DAC implementation issue rather than I2S is broken. I2S can be used to transport data types other than twos complement especially if there is additional processing done before the final dac stage. This is why the data type handling is usually done in the software and the I2S link be kept data independent. But the majority is twos-comp so there is certainly an argument for making the transmitter/receiver aware of it.
Such a shame though that I2S never really caught on in commercial hifi such as external DAC's. It's more suited to inter-chip comms as the standard doesnt specify what cabling should be used for the 3 signals. Hence why you get many different ways of using I2S over cables.

That's true DaveF - it's more an issue with the use of two's complement number format & how it is usually extended to longer bit depths in digital audio .
Don't think the high speed clock signal line would be a good candidate for transmission over a cable of any useful length unless something like LVDS (Low-voltage differential signaling) was used.

I've only seen LVDS used in cables where the speeds are much greater than what's needed for audio . Have you ever seen it used for audio, John?
LVDS offers very good noise immunity (common mode) and with all our discussion on noise recently, maybe LVDS could be considered.
There is also sub-LVDS which is a lower power version of LVDS but it is used for inter-chip comms. Originally pushed by Nokia for Camera Interfaces in mobile phones. Not sure if you could use this down a cable though and most Xilinx FPGA IO's are not directly compatible with sub-lvds signalling. Not without some passive circuitry anyway.

The Twisted Pear Audio Transport module is an LVDS solution designed for this sort of work I think. It works very well (according to user reports), allowing deterioration-free transfer of I2S over some meters.

With regard to the issues of encoding on I2S interfaces, I recall Ray bringing this up on DIYAudio in the Exadevices thread. I believe the developer wrote a fix into the device driver. It doesn't get much coverage elsewhere though.

LowOrbit wrote:The Twisted Pear Audio Transport module is an LVDS solution designed for this sort of work I think. It works very well (according to user reports), allowing deterioration-free transfer of I2S over some meters.

With regard to the issues of encoding on I2S interfaces, I recall Ray bringing this up on DIYAudio in the Exadevices thread. I believe the developer wrote a fix into the device driver. It doesn't get much coverage elsewhere though.

Yea, a couple of LVDS solutions are offered for audio, I believe.

Indeed Ray posted about this on DIYA & I think commisioned & subsequently helped SDTrans to incorporate it in their firmware. I believe he did the same for Light Harmonic - did he do the same for Exadevices?

Only other place I've seen it mentioned is here http://www.whatsbestforum.com/showthrea ... ion-errors & I banged on about it recently on another thread on that forum. Funny how reluctant some people are about it - DonH does an analysis of it's effects (but an incorrect one, in my view) & my recent posts about it were responded to by JJ Johnston (well known guru & psychoacoustic expert) with a condescending

I suggest a basic DSP book. You're barking up the wrong tree there.

The problem isn't even remotely novel. I don't doubt that digital manufacturers have blown it more than once. Ask me about rounding and denorms in IEEE arithmetic some day in a different thread.

So he's saying it's trivial but deflects from the question I asked him which was does he know any audio DAC manufacturer who addresses this?

It's as if some are afraid to admit digital has any implementation flaws but quiet happy to point out analogue implementation issues (& yet analogue still gives digital audio a run for its money & is better than most digital implementations)

DaveF wrote:Its more of a DAC implementation issue rather than I2S is broken. I2S can be used to transport data types other than twos complement especially if there is additional processing done before the final dac stage. This is why the data type handling is usually done in the software and the I2S link be kept data independent. But the majority is twos-comp so there is certainly an argument for making the transmitter/receiver aware of it.
Such a shame though that I2S never really caught on in commercial hifi such as external DAC's. It's more suited to inter-chip comms as the standard doesnt specify what cabling should be used for the 3 signals. Hence why you get many different ways of using I2S over cables.

Actually, DaveF, I take it back - it is the I2S specification that is wrong.

This quote from the Philips I2S specification says ithttps://www.sparkfun.com/datasheets/Bre ... I2SBUS.pdf

When the system word length is greater than the transmitter word length, the word is truncated (least significant data bits are set to ‘0’) for data transmission.

jkeny wrote:

DaveF wrote:Its more of a DAC implementation issue rather than I2S is broken. I2S can be used to transport data types other than twos complement especially if there is additional processing done before the final dac stage. This is why the data type handling is usually done in the software and the I2S link be kept data independent. But the majority is twos-comp so there is certainly an argument for making the transmitter/receiver aware of it.
Such a shame though that I2S never really caught on in commercial hifi such as external DAC's. It's more suited to inter-chip comms as the standard doesnt specify what cabling should be used for the 3 signals. Hence why you get many different ways of using I2S over cables.

Actually, DaveF, I take it back - it is the I2S specification that is wrong.

This quote from the Philips I2S specification says ithttps://www.sparkfun.com/datasheets/Bre ... I2SBUS.pdf

When the system word length is greater than the transmitter word length, the word is truncated (least significant data bits are set to ‘0’) for data transmission.

I see your point alright but I believe that I2S was designed to be data independent. It's an old spec though and I wonder at the time when it was written was it common usage for the link to be transporting positive & negative 2s-comp numbers or just positive or normal binary values?
When I first started working after college(long time ago now) my first design was an 8 channel I2S interface that was going between processors as opposed to a DAC. The MAC(multiply and accumuate) cores would be configured over I2C beforehand though. I dont recall 2s-comp data being used though.
But you could argue that now the spec doesnt take in account 2s-comp numbers.

DaveF, the I2S spec does say that it uses two's complement

Serial data is transmitted in two’s complement with the MSB first.

Gathering some more info related to this issue. So apart from Light Harmonic implementing it - John Westlake seems to have recognised that processing these padding bits is detrimental to the sound & introduced something called D3E Decorrelator in the Auidolab M-Dac which can be switched off, on full or partial.. According to the manual When talking about 16 bit in a 24bit container or 24bit in 32bit container

"ln normal circumstances a DAC will still attempt to process the eight null bits: Audiolab's D3E Decorrelator, however, claims to cancel out the bits that present no data, leaving the DAC to focus on those remaining bits intended for conversion"

And elsewhere

Digital Data Decorrelation Engine – Decorrelates the fixed “LSB’s” data pattern within the Audio data stream when less then 24Bits. Data decorrelation at the DAC substrate level reduces both Digital and Analogue Second order effects within the DAC at the silicon Die level"

He seems to have determined that having these padding bits is detrimental to the sound (& users have reported improvement when the decorrelator is switched on) - maybe this is because of it's wrong negative values?

Now if only we can convince Gordon or Lekt to try to implement it :)