• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 3282 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DIR9001: SPDIF goes in, no I2S coming out

Carlos Moreno1
Intellectual 550 points
Part Number: DIR9001

Hello,

I did a preliminary design of an S/PDIF to I2S converter based on the DIR9001.  Doesn't seem to be working.

In the definitive design, I'm planing to use it in standalone (hardware) mode.  No external crystal  (as I understand, the crystal / XTI signal is only needed when we want finer-grained control over clocking and rates.

See schematic below  (designed and routed with KiCAD 5.1.2).  One mistake I'm noticing is that I did not connect XTI to GND, as the manual instructs to do when we do not use an external clock signal.  Could this be the reason why it's not working?  (that woud be good news --- an easy fix!)

Other than that, do you see any reason why it won't output the I2S signals?   With an oscilloscope, I see activity at the RXIN pin, but nothing at the LRCLK, BCLK, SDATA signals.  I do not need a "master clock" I2S signal, as my DSP (an ADAU1701) accepts the BCLK signal as MCLK if I configure the input clock settings for the PLL to 64×Fs.

The DIR9001 portion of the layout --- I omit the input stages, as these seem to be working fine  (since I do get a clean-looking RXIN signal):

It's a two-layer board, bottom layer (in teal-ish / blueish/greenish color in the image) is the GND plane.

Thanks,
Carlos
--

  • 0
    TI__Mastermind 30100 points

    Carlos, 

    I would check the Error pin, to see what the status is there.  Also check the FSOUT pins. 

    Is the activity you see on the RXIN pin the proper signal levels?

    best regards,

    -STeve Wilson

  • 0 in reply to Steve-Wilson
    Intellectual 550 points

    Thanks Steve!

    Still doesn't work well, but I found what seems to be the main issue --- the RESET line:

    The datasheet states that the RESET line must remain asserted (low) for at least 100ns after Vdd reaches 2.7V.  In any case, after I press the RESET button, it works.

    However, it does not work well.  One channel (L) sounds perfect  (at least based on a casual listening test),  the other one (R) blasts noise at essentially a deafening level (maybe not random noise:  it does sound like it could be an extra-distorted version of the audio).

    This is the setup:

    The I2S output from the DIR9001 goes to an ADAU1701, which takes the Left audio channel to do its thing locally, and outputs an exact copy of the input through its I2S output channel.   That output goes to another ADAU1701 which does exactly the same thing, except that it works with the Right audio channel.

    The setup works perfectly with a USB-to-I2S based on the PCM2707C.  I'm only replacing the original I2S source --- instead of the I2S output from a PCM2707C, I'm connecting the I2S output from the DIR9001.

    The puzzling detail is:  the ADAU1701 that receives its I2S signal directly from the DIR9001, that one sounds ok;  the one that receives the I2S from the other ADAU1701, that one fails.  The puzzling part being:  for the second ADAU1701, nothing has changed --- it is still receiving the signal from the other ADAU1701. Nothing has changed in the connection from ADAU #1 to ADAU #2, or the firmware of either one of the ADAU's.

    Can you think of anything that would explain this behaviour?

    Thanks,
    Carlos
    --

  • 0 in reply to Carlos Moreno1
    TI__Mastermind 30100 points

    Carlos, 

    I'm not sure I understand what you're saying.  The DIR9001 is now functioning,  and the ADAU1701 that you have connected to the DIR9001 works fine,  but a second ADAU1701 that connects to the first ADAU1701 does not work right? 

    best regards,

    -STeve Wilson

  • 0 in reply to Steve-Wilson
    Intellectual 550 points

    Essentially, yes.

    My initial suspicion was 100% on the DIR9001 side  (even putting aside the RESET line detail), because the setup of the two ADAU1701's works flawlessly with the PCM2707C USB-to-I2S board as the source of audio.  It was only when I replaced the USB-to-I2S board with the SPDIF-to-I2S board that the problem appeared, so the main suspect was the SPDIF-to-I2S board, naturally.

    My second round of suspicion pointed to something weird with the I2S signal that would cause the first ADAU1701 to read the right channel incorrectly  (and that would explain why the second ADAU, which handles the right channel, outputs the blasting noise).  However, I put an oscilloscope at the I2S signals, and they look consistent.  For that matter, everything I've tested checks out, so now I'm kind of extra-puzzled.

    At this point, I'm inclined to believe that the problem is on the ADAU1701 side --- or in any case, that the solution to whatever glitch/bug or inconsistency in the connections/setup will be on the ADAU1701 side.

    I'll flag this thread as answered now, and I may come back and ask a related question, if I find additional clues that point to the DIR9001.

    Thanks,
    Carlos
    --

  • 0 in reply to Carlos Moreno1
    TI__Mastermind 30100 points

    Carlos, 

    That is rather odd. Could it just be a formatting issue?   

    note that the DIR9001 is 24bit I2S with 64bclk/Fsync ratio,  the PCM2707 would be 16bit,  and I don't believe the bclk/fsync ratio is 64.  Its hard to imagine the ADAU1701 locking on to the first word, but not the second... but i don't know how their audio serial bus works. 

    best regards,

    -Steve Wilson

  • 0 in reply to Steve-Wilson
    Intellectual 550 points

    Thanks Steve, for these additional tips!

    Steve-Wilson said:

    That is rather odd. Could it just be a formatting issue?   

    note that the DIR9001 is 24bit I2S with 64bclk/Fsync ratio,  the PCM2707 would be 16bit,  and I don't believe the bclk/fsync ratio is 64.

    Hmmm --- how could it not be 64?  As I understand it, that is a "fixed" parameter in the I2S specification?   (maybe I've misunderstood that detail)

    In any case, what I observe (through the oscilloscope, tapping on the I2S signals coming from the DIR9001) is consistent with Table 4 --- LRCLK is the 48kHz sampling frequency, and BCLK shows at 3.072MHz  (64 times 48kHz).

    In any case, I was already suspecting that part --- however, I thought the 16-bit vs. 24-bit should not be an issue;  I wrote this in the Analog Devices forum:

    Carlos Moreno / on Analog Devices forum said:

    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?

    That was based on my observation through the oscilloscope --- looking at the I2S signals from the DIR9001.

    They do look like it is 16-bit, but I figure it is 24-bit with the 8 LSB set to zero (or 1 for negative values), which is why I figured there's no real difference.

    What I see looks perfectly consistent with the timing diagrams on Figure 15  (the last one, as I'm using I2S format everywhere).   What had not occurred to me is to look at the I2S signals coming out of the PCM2707C  (I had done that long ago when I was debugging the PCM2707C board);  maybe I could spot some differences that will provide additional clues as to what's going on?

    Thanks again for your additional comments!

    Carlos
    --