The question relates also to the T.I. S/PDIF receiver DIR9001 --- I asked in the TI forum, but I'm thinking that the issue may actually have to do with my ADAU1701 setup (a bug that had remained hidden / non-manifested).
I have a setup with an ADAU1701 that receives audio through its I2S input, reads the L channel and implements a crossover; at the same time, it outputs an exact copy of the input through its I2S output. That output then goes to another ADAU1701 that does exactly the same, except that it works with the R channel.
The setup has been working fine --- I did an USB-to-I2S converter based on the T.I. PCM2707C. It works.
Now, I'm trying to replace the USB-to-I2S converter with an SPDIF-to-I2S converter --- same output interface so that it connects to the same ADAU1701 board.
Well, the left channel (the one that directly receives the I2S audio from the DIR9001 board) sounds ok. The right channel (the one that receives the I2S from the other ADAU1701), that one blasts what sounds like noise at a deafening level (maybe not noise --- it sounds like it could be an extra-distorted version of the audio; so distorted and so loud that it ends up sounding like noise).
The puzzling detail: for the second ADAU1701 (the one the works with the R channel), nothing has changed --- it is still receiving audio from the same ADAU1701 that it has always received it (and has been working). And that one is precisely the one that does not work.
Can you think of any reason for this? (some "bug" in my ADAU1701's setup that had not manifested?)
Digging / debugging some more, I can't seem to find anything wrong with the I2S output from the DIR9001, which would point in the direction that I have some bug in my ADAU1701 board.
The system, as has been working well for the past several months, is roughly as shown below:
The dotted lines denote the fact that the ADAU board outputs an exact copy of the I2S input to its I2S output --- in addition to "tapping" into the I2S signal to apply some processing --- both boards (ADAU #1 and #2) are identical hardware, and the SigmaStudio project is essentially identical --- one of them grabs the LEFT channel to process it, the other one grabs the RIGHT channel to process it.
Ok, now, I just replace the USB to I2S board with an S/PDIF to I2S board based on the DIR9001, and the right channel just outputs this loud/blasting noise (but the left channel sounds fine!).
I measured the LRCLK and SDATA lines coming out of the DIR9001 --- they look perfectly fine:
Left channel (oscilloscope trigger set on the LRCLK signal, falling edge)
Right channel (oscilloscope trigger set to rising edge)
Looks perfectly consistent with a 16-bit I²S signal (left-justified with 1-bit skipped after the LRCLK edge). Notice that the picture captured the superposition of multiple sweeps in the oscilloscope.
The settings in the SigmaStudio project look consistent with this as well:
I guess (hope) there is no real difference between 16-bit and 24-bit --- what the PC transmits seems to be 16-bit because the source file comes from a CD and is 16-bit. But the ADAU#1 then outputs 24-bit. Since it is MSB-first and zero-padded, I guess the receiving end treats it as 24-bits regardless, adding 8 zeros as the least-significant bits, and it scales them appropriately (i.e., a full-scale 16-bit will map to essentially the same analog level as a full-scale 24-bit --- just the negligible difference of the low 8 out of 24 bits). Is my interpretation correct?
I will mention this detail in case it could be related to the issue: one puzzling detail is: when I tap on the SDATA line with the oscilloscope probe (which should be super high input impedance), both channels emit a loud/blasting noise. I have no idea why this could be --- the SDATA output from the DIR9001 goes to an SN65LVDS1 driver to be transmitted to the ADAU board (I'm using LVDS transmission for each of the I²S signals). I'm placing the probe at the LVDS driver input pin (there is nothing else connected there --- the output pin from the DIR9001 goes directly to the input pin of the LVDS driver, and it goes nowhere else!)
Another possibly relevant detail: the ADAU1701 generates its internal clock from the BCLK signal of the I²S (I set PLL0/PLL1 to 64×Fs). This could introduce a difference between the two boards --- ADAU #1 gets its clock from the BCLK generated by the DIR9001 (which I noticed only shows up after I play some audio). ADAU #2 gets its clock from the BCLK generated by the ADAU #1 board --- could there be some weird out-of-sync condition due to the transition from no-clock to clock-present?
Aside from these, can you think of something else I could be doing wrong that would explain these symptoms?