I would be grateful if anyone can explain why the DF1704/6 filter chips need to have the bit depth defined for left-justified input formats. The options available are 24 bit left-justified, 16 bit I2s and 24 bit I2s. Does truncation take place if 24bit data are input to a 16bit I2s setting?
Hi @Ardee, not sure if anyone answered this? For the DF1706, you don't need to specify bit depth for left justified data. The chip will interpret all of the data that has arrived before the next word clock transition, so if there are 16 bits, it will recieve 16. If there are 24, it will accept all 24. And if there are 16, but 24 clock, the last 4 will usually be zeroes anyway, so it just treats it as 24 bit data with 0s in the 4 LSBs.
With Right Justified data, you must specify the bit depth, otherwise it doesn't know what the MSB is. Extract from the datasheet attached. I recommend 24 bit I2S if you plan to use it in a design. I2S is also left justified.
With Right Justified data, you must specify the bit depth, otherwise it doesn't know what the MSB is. Extract from the datasheet attached. I recommend 24 bit I2S if you plan to use it in a design. I2S is also left justified.
Thanks for the reply @APEXHiFi, but how can the filter chip maintain linearity without knowing how many of the 32 bits of the word are active? I assume that is why the DF1706 has the two settings. The only filter I have seen which does not have a bit depth setting for LJ is the PMD100, which is a bit of an outlier in many ways - even the PMD200 needs to know the LSB position. It should be possible to detect bit depth by observing when an LSB is active, but that doesn't seem to be what happens.
The number is bits is actually dependent on the number of bitclock pulses per wordclock cycle so it depends on the circuit used to decide the input signal. It's often 32, but 24 and other numbers is also used.
If using 24 clock cycles with only a 16 bit signal (for example) the first 16 bits will contain the audio data and the DF1706 will then also read in the next 8 bits, but the source doesn't have any data for these, so they will all be zero. So you actually end up with a 24 bit input signal where only the 16 MSBs contain useful data and the last 4 are all 0. That is still perfectly linear, but it does make the assumption that the source data stream puts zeroes in the unused bits. If it doesn't, you would have a problem, but fortunately that's not normally an issue.
If using 24 clock cycles with only a 16 bit signal (for example) the first 16 bits will contain the audio data and the DF1706 will then also read in the next 8 bits, but the source doesn't have any data for these, so they will all be zero. So you actually end up with a 24 bit input signal where only the 16 MSBs contain useful data and the last 4 are all 0. That is still perfectly linear, but it does make the assumption that the source data stream puts zeroes in the unused bits. If it doesn't, you would have a problem, but fortunately that's not normally an issue.
I'm also not sure what you mean by "observing when an LSB is active". The bit is either a 0 or 1. How would you differentiate between an active 0 and an inactive 0?
I2S has two 32 bit words per clock cycle. That's the specification. Treating 16 bits plus padding as 24 bits would probably affect linearity, but whether this would be audible, I don't know. The fact that there are two different settings indicates it might be measurable, at least.
Active implies a change of state, and even minimal dither would make the LSB active. You would have to monitor the LSB's for 16, 18, 20 and 24 bits to work out the bit depth but, so far as I know, nobody does that, and filter chips were mainly in equipment where the bit depth was preset, unlike some USB audio output.
Anyway, there must be a good reason why filter chips needed to have an input bit depth setting.
Active implies a change of state, and even minimal dither would make the LSB active. You would have to monitor the LSB's for 16, 18, 20 and 24 bits to work out the bit depth but, so far as I know, nobody does that, and filter chips were mainly in equipment where the bit depth was preset, unlike some USB audio output.
Anyway, there must be a good reason why filter chips needed to have an input bit depth setting.
It would only make difference if you truncate the data stream from, say, 24 bits to 16 bits. Then such truncation may introduce additional noise and there you may consider using dithering.
However @APEXHiFi is right in the case of streaming data to the DF: in LJ it does not matter whether data is 20 bit or 16 bit padded with zeros.
In case of 16 bit I2S word length is 32 bclk/word (16 bit/sample), in 24 bit i2s - 64 bclk/word (32bit/sample).
This is to match the data formats.
However @APEXHiFi is right in the case of streaming data to the DF: in LJ it does not matter whether data is 20 bit or 16 bit padded with zeros.
If you notice, in the SW control section the table says "Input Data Format and Word Length."
In case of 16 bit I2S word length is 32 bclk/word (16 bit/sample), in 24 bit i2s - 64 bclk/word (32bit/sample).
This is to match the data formats.
I2S has 2x 32 bit words, but Left Justified data is undefined so this can have fewer bits.
Treating the left 16 bits as data and adding padding is still inherently entirely linear (provided the 8x LSBs are all 0). If you think if this in Decimal, 0, 1, 2, 3, 4 etc is linear, but so is 0, 10, 20, 30, 40. It's exactly the same thing, just translated to binary.
I see your point on "active" LSB - that would work, but it isn't necessary so isn't implemented that way. Lots of other oversampling chips and algorithms do the same thing by accepting 16 bit I2S or Left Justified data of up to 24 bits even if only 16 are "active". The PMD-100, PMD-200, YSF210 etc can all be used this way.
Bit depth setting is VERY important for Right Justified data. If this isn't set correctly, you could either get a signal where the top few MBSs are incorrectly discarded, effectively leaving you with white noise, or you would receive a 24 bit signal with only the least significant 16 bits having any data in them. That would make for an extremely quiet output!!!
Treating the left 16 bits as data and adding padding is still inherently entirely linear (provided the 8x LSBs are all 0). If you think if this in Decimal, 0, 1, 2, 3, 4 etc is linear, but so is 0, 10, 20, 30, 40. It's exactly the same thing, just translated to binary.
I see your point on "active" LSB - that would work, but it isn't necessary so isn't implemented that way. Lots of other oversampling chips and algorithms do the same thing by accepting 16 bit I2S or Left Justified data of up to 24 bits even if only 16 are "active". The PMD-100, PMD-200, YSF210 etc can all be used this way.
Bit depth setting is VERY important for Right Justified data. If this isn't set correctly, you could either get a signal where the top few MBSs are incorrectly discarded, effectively leaving you with white noise, or you would receive a 24 bit signal with only the least significant 16 bits having any data in them. That would make for an extremely quiet output!!!
Thanks for the answers, but none of them have actually answered the question why the bit depth needs to be specified. (The PMD200 sets which bit carries the HDCD info, which is effectively the same thing.).
If there is no problem, only the 24 bit setting would be needed. The chip could dither everything down to 16 bits before converting to whatever the filter math uses., and maybe that's what happens with the 16 bit setting. That's what I would like to know, just out of curiosity.
If there is no problem, only the 24 bit setting would be needed. The chip could dither everything down to 16 bits before converting to whatever the filter math uses., and maybe that's what happens with the 16 bit setting. That's what I would like to know, just out of curiosity.
For left justified and I2S data (which is also left justified) the bit depth does not need to be specified. For Right Justified, it does. See my previous reply for reasoning.
It would be possible to autodetect but depth for right justified data, but the chip designers just didn't do this!
It would be possible to autodetect but depth for right justified data, but the chip designers just didn't do this!
If you look again at the settings in the table in the datasheet, there is only one setting for Left Justified input data. It's 24 bit. I2S does have 16 or 24 - I haven't checked the spec sheet as to how these differ, but I know for certain that you can use a 24 bit I2S input setting with 16 bit data - I use it in one of my designs amd it handles 24 bit and 16 bit sources seamlessly.
Are you looking at bit depth settings for the Output data? These are a very different set of signals!
Are you looking at bit depth settings for the Output data? These are a very different set of signals!
Quick look at the datasheet says the I2S 16 bit format just discards the last 8 bits of data. Perhaps insurance in case the source doesn't behave and puts random data in these bits?
No, but I admit that I did wonder if you were confusing the two.
I don't see that anywhere. Which page?
Note, there is no 16 bit left justified data format, only 24 bit.
Plenty of source ICs output 16 bit left justified 16 bit, and I also know for certain that the widely used CS8412 and DIR9001 can both be set up to output I2S 16 bit which the DS1706 correctly processes in 24 bit I2S mode since the 8x LSBs are all zeroes.
Plenty of source ICs output 16 bit left justified 16 bit, and I also know for certain that the widely used CS8412 and DIR9001 can both be set up to output I2S 16 bit which the DS1706 correctly processes in 24 bit I2S mode since the 8x LSBs are all zeroes.