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.

PCM2906C: S/PDIF input from DIT4096

Part Number: PCM2906C
Other Parts Discussed in Thread: PCM1808, , DIT4096, PCM1801, PCM9211

Hi TI,

 

We are having issues getting our audio solution working and would like some support to resolve it.

Background:

We have designed two PCBs, one PCB will record audio from a microphone and send the audio as S/PDIF over an optical cable. The second PCB will receive the audio from the optic cable and convey it to a computer over USB.

The signal chain looks like the following:

Microphone -> Audio conditioning circuit -> PCM1808 ADC -> [I2S, 24bit, Fs= 48 kHz] -> DIT4096 -> [S/PDIF] -> Optical transmitter -> Optical reciever -> PCM2906C -> [USB] -> Computer.   

The PCM2906C S/PDIF input and USB connection we have verified by connecting it to another S/PDIF source and have had the audio successfully conveyed to a computer. The optical transmitter and receiver we have also managed to rule out to be the root cause. Using an oscilloscope we can see the S/PDIF waveform on the PCM2906C S/PDIF input, but the PCM2906C does not report anything back to the computer. Upon reading through the datasheets again we noticed that the only mentioned supported bit-depth of the PCM2906C S/PDIF input is 16-bit but we are supposedly sending 24-bit audio(?). Can you confirm that the PCM2906C won't accept 24-bit audio on its S/PDIF input? Or does it just ignore the 6 LSB?  

 

Either way, we decided to quickly prototype a new PCB but instead use the PCM1801 16-bit ADC, which made the signal chain look like the following    

Microphone -> Audio conditioning circuit -> PCM1801 ADC -> [I2S, 16bit, Fs= 48 kHz] -> DIT4096 -> [S/PDIF] -> Optical transmitter -> Optical reciever -> PCM2906C -> [USB] -> Computer.

But we have still not managed to get the PCM2906C to accept the S/PDIF generated by the DIT4096. Some further details:  

  • DIT4096 is configured as the I2S master. 
  • PCM1801 is configured for I2S. 
  • The PCM1801 SCKI pin and the DIT4096 MCLK pin are supplied from an 18.432 MHz oscillator (384*fs)  
  • The DIT4096 is configured in SW mode with the following settings:
    • [Register] Value
    • [0x03] 0xAD
    • [0x02] 0x04
  • I2S SYNC clock measured to 48 kHz and I2S data clock measured to 3.072 MHz. The PCM1801 is outputting data on the I2S data line.  
  • We can see the S/PDIF data on the PCM2906C S/PDIF input pin but nothing on the computer.  

Are we configuring the DIT4096 properly? Do we need to do any configuration for the channel status data buffers?   

Any help or suggestion is highly appreciated. 

 

Thanks,

Jonas

  • A small addition to the original post:

    We captured the I2S data between the PCM1801 and DIT4096 using a logic analyzer. We then converted the captured I2S data back to audio and could clearly hear the original recorded audio. So we are now confident that the I2S input to the DIT4096 is valid/correct.    

  • Hello Jonas,

    Thank you for the thorough explanation of your problem.  The PCM2906C does only accept the outputs shown below. 

    I would recommend continuing down the signal chain. Using the logic analyzer, you could probe the optical tx and rx to see if the signal is making it to the PCM2906C input as expected.

    Would it be possible to send a schematic? In particular, I would like to look at the connection between the DIT4096 and the optical transmitter as well as the connection between the optical receiver and the PCM2906C. 

    Best,
    Andrew

  • Hi Andrew,

    Thank you for your response.

    That at least explains why we could not get it to work using the 24-bit PCM1808 ADC. So let's focus on getting the PCM1801 16-bit ADC solution to work.  

    The image below is a snippet of the S/PDIF signal taken using the logic analyzer. We do not see any abnormalities between the DIT4096 output and the PCM2906 input. Measuring the pulse widths at arbitrary places, it seem to be preserved at least down to 2 ns (minimum difference we could measure, limited by our logic analyzer sampling frequency). We also tried connecting the DIT4096 S/PDIF output to a Toslink speaker and were able to play/hear the sound entering the microphone (although there where quite much static/humming noise also present, not sure why). 

    We could send the schematic, but would need to hide away a few non-related details first. First, can you confirm that you agree with our SW configuration of the DIT4096? Right now we do not do any changes to the channel status data buffers which we are unsure if we should. Could it be an issue related to the PRO/Consumer and copyright bits that are sent over the S/PDIF protocol?               

    .

    Best regards,

    Jonas

  • Hello Jonas, 

    So far the DIT4096 looks correct. I will check with the larger team about the PRO/Consumer copy bits to see if this could be the issue. However, I would like rule out a schematic issue if at all possible. 

    Best,
    Andrew

  • Hi Andrew,

    Thank you for checking with the team. What would be the most convenient way to send you the schematics in private? 

    Best regards,

    Jonas 

  • Hi Jonas,

    Email would be best. Can I reach out to you on the email listed for your myTI account?

    Best,
    Andrew

  • Hi Andrew,

    Yes, please do that.

    Regards,

    Jonas

  • Hi Jonas,

    Thank you for sharing the schematic.

    The PCM2906C S/PDIF input and USB connection we have verified by connecting it to another S/PDIF source and have had the audio successfully conveyed to a computer. The optical transmitter and receiver we have also managed to rule out to be the root cause.

    I believe this means that you have verified performance using an external SPDIF signal with the PCM2906C (although with a 24-bit)? Have you done this test with the 16-bit format and the PCM2906C plays to the computer correctly? Essentially, I am looking to confirm that the PCM2906C/optical receiver is verified with the 16-bit format. 

    If this is true then, I the disconnect would be between the DIT4096 output and the PCM2906C. Which points to a formatting miss match since it seems like the signal chain works (outputs data) from the mic input to the optical receiver (which I believe you suspected in the quote below), 

    Could it be an issue related to the PRO/Consumer and copyright bits that are sent over the S/PDIF protocol?               

    If we can confirm that the disconnect is between these two devices, please provide a capture of the S/PDIF protocol packet from the DIT4096/transmitter and a data packed that worked on the receiver/PCM2906C. Ideally, this will show us if there is a formatting mismatch.

    Best,
    Andrew

  • Hi Andrew,

    I believe this means that you have verified performance using an external SPDIF signal with the PCM2906C (although with a 24-bit)? Have you done this test with the 16-bit format and the PCM2906C plays to the computer correctly? Essentially, I am looking to confirm that the PCM2906C/optical receiver is verified with the 16-bit format. 

    If this is true then, I the disconnect would be between the DIT4096 output and the PCM2906C. Which points to a formatting miss match since it seems like the signal chain works (outputs data) from the mic input to the optical receiver (which I believe you suspected in the quote below), 

    The S/PDIF source in this case was the S/PDIF output of the same PCM2906C, I should have been more clear about that. Below I tried to visualize the signal path, the bold components are on the SPDIF Transmitter schematics (SPDIF_Transmitter_24bit.PDF) I sent you. The looping was done by connecting an optical fiber between U1 and U4. So the optical receiver and the PCM2906C input have been verified (at least with its own S/PDIF output as source).     

    Computer -> [USB] -> PCM2906C -> [S/PDIF, 16bit, 48kHz] -> Optical transmitter -> Optical Reciever -> 

                                                                                                                                                                          |

                                                                                                                                                                          v

                                         Computer <- [USB] <- PCM2906C <- Optical Reciever  <- Optical transsmitter < -

    If we can confirm that the disconnect is between these two devices, please provide a capture of the S/PDIF protocol packet from the DIT4096/transmitter and a data packed that worked on the receiver/PCM2906C. Ideally, this will show us if there is a formatting mismatch.

    We got our hands on another logic analyzer that supports S/PDIF decoding. Analyzing the working S/PDIF source (the PCM2906C S/PDIF output) it has the following channel status blocks bits set to logic '1' (starting at bit index 0): Bit[9] = 1, Bit[15] = 1 and Bit[25] = 1, rest of the Bits are logic '0'. From the S/PDIF specification, the Bit[8:15] indicates the kind of equipment that generates the digital audio interface along with the generation status. Bit[24:27] indicate the sampling frequency, which in this case is 48 kHz which is correct.

    Analyzing the DIT4096 S/PDIF output all the channel status block bits are logic '0', this is with the following SW configuration done to the DIT4096:

    • [Register] Value
    • [0x03] 0xAD
    • [0x02] 0x04

    We tried configuring the DIT4096 channel status data buffer (following Figure 9 in the datasheet) to match the PCM2906C output but the value we tried to program into the UA buffer we could not read back successfully. Below is a code snippet along with some comments. We will continue to investigate this further tomorrow.   

    Also, in Table VIII in the DIT4096 datasheet there is a CS_N column, what does it  mean? 

     

    DIT4096Write(0x03, 0xAD);
    DIT4096Write(0x02, 0x04);
    delay(100);                                 //Delay 100 ms after power up. 
    uint8_t BTD = 1;                             //Set BTD to 1
    DIT4096Write(0x07, BTD);                     //Write BTD to register 0x07
    SerialUSB.println(DIT4096Read(0x07));        //Readback register 0x07, response is 0x01: OK!
    
    delay(500);
    SerialUSB.println(DIT4096Read(0x08),HEX);    //Read register 0x08, response: 0xFB
    delay(500);
    DIT4096Write(0x08, 0x00);                    //Write 0x00 to register 0x08
    SerialUSB.println(DIT4096Read(0x08),HEX);    //Read register 0x08, response is 0xFB: NOT expected. 
    
    BTD = 1;                                     //Set BTD to 0
    DIT4096Write(0x07, BTD);                     //Write BTD to register 0x07

    Best regards,

    Jonas     

  • Hello Jonas, 

    Thanks for the added information. 

    Let me check with the team on the proper use of the CS_N header. From what I can tell this is related to "FIGURE 6. Write Operation Format" and may be the header byte need to write to that register, but I will need to look into this further. 

    Best,
    Andrew

  • Hi Jonas, 

    Quick update (I am still reviewing all the info with the team). The DIT4096 tends to be hard to program.  Please try the following config script for the DIT4096 and let me know if this is configuring the device. 

    # PCM9211_Init.txt
    #this script is for SPDIF-->RXIN0-->DIR-->MainOutput, Record sound from SPDIF to PC through TAS1020
    
    #1, Chose RXIN0 to DIR
    #2, Active DIR
    #3, chose DIR output as Mainoutput's source.
    
    #Also HW modification
    #1, Flying to High Level(3.3V) to make sure U7's output is Hi-Z
    #or 2, TAS1020 output logic high on P1.2 I2S enable signal. 
    #**************************************
    
    #System RST Control
    #w 80 40 00
    w 80 40 33
    w 80 40 C0
    
    #XTI Source, Clock (SCK/BCK/LRCK) Frequency Setting
    # XTI CLK source 12.288 and BCK 3.072, LRCK 48k = XTI/512
    w 80 31 1A
    w 80 33 22
    w 80 20 00
    w 80 24 00
    #ADC clock source is chosen by REG42
    w 80 26 81
    
    #XTI Source, Secondary Bit/LR Clock (SBCK/SLRCK) Frequency Setting
    w 80 33 22
    
    #*********************************************************
    #-------------------------------Start DIR settings---------------------------------------
    #REG. 21h, DIR Receivable Incoming Biphase's Sampling Frequency Range Setting
    w 80 21 00
    
    #REG. 22h, DIR CLKSTP and VOUT delay
    w 80 22 01
    
    #REG. 23h, DIR OCS start up wait time and Process for Parity Error Detection and ERROR Release Wait Time Setting
    w 80 23 04
    
    # REG 27h DIR Acceptable fs Range Setting & Mask
    w 80 27 00
    
    # REG 2Fh, DIR Output Data Format, 24bit I2S mode
    w 80 2F 04
    
    # REG. 30h, DIR Recovered System Clock (SCK) Ratio Setting
    w 80 30 02
    
    #REG. 32h, DIR Source, Secondary Bit/LR Clock (SBCK/SLRCK) Frequency Setting
    w 80 32 22
    
    #REG 34h DIR Input Biphase Signal Source Select and RXIN01 Coaxial Amplifier
    #--PWR down amplifier, Select RXIN2
    #w 80 34 C2
    #--PWR up amplifier, select RXIN0
    w 80 34 00
    #--PWR up amplifier, select RXIN1
    #w 80 34 01
    
    #REG. 37h, Port Sampling Frequency Calculator Measurement Target Setting, Cal and DIR Fs
    w 80 37 00
    #REG 38h rd DIR Fs
    r 80 38 01
    #***********************************************************
    #------------------------------------ End DIR settings------------------------------------------
    
    
    #***********************************************************
    #---------------------------------Start  MainOutput Settings--------------------------------------
    #MainOutput
    #REG. 6Ah, Main Output & AUXOUT Port Control
    w 80 6A 00
    
    #REG. 6Bh, Main Output Port (SCKO/BCK/LRCK/DOUT) Source Setting
    w 80 6B 11
    
    #REG. 6Dh, MPIO_B & Main Output Port Hi-Z Control
    w 80 6D 00
    #***********************************************************
    #------------------------------------ End MainOutput settings------------------------------------------
    
    # read back all registers to ensure GUI integrity
    r 80 20 5E
    

    Best,
    Andrew

  • Hi Andrew,

    Looking at the script in your post it does not seem compatible with the DIT4096(?). 

    Best regards,

    Jonas

  • Hello Jonas, 

    Sorry for the confusion.

    PCM9211 is a similar device. You can use the structure; however, the registers might be different. Attached is another script which should be compatible, but the first script is good to show the steps for DIR and DIT programming.

    DIX4192_5F00_script.txt

    Best,
    Andrew

  • Hi Jonas, 

    In general, this DIT4096 part is quite old and supporting it is difficult. The best guess here is that there is some SPDIF packet/data frame mismatch that is causing the PCM2906C to not recognize the audio packet. The best recommendation here is to use a logic analyzer to look at a packet that works with the PCM2906C and see how it differs from the DIT4096's SPDIF output. 

    After further review we have the following comments:

    1. In SPDIF_reciever.PDF please replace R131 with a capacitor. Unused analog inputs should be AC coupled to GND (or left floating).
    2. In SPDIF_Transmitter_16bit.PDF, U4 pin 28 is tied to 3.3V. Which means that it is set for Hardware mode operation. 
      1. It does seem that you have been programing the device so hopefully this isn't the reason that programming the channel status registers is an issue, but I still wanted to bring it up. 
      2. I suspect that the packet not being received by the PCM1801 is the result of a mismatch in the DIT4096 SPDIF packet in the VUCP bits. This may be easier to configure in hardware mode. 

    I hope this and the previous replies help.

    Best,
    Andrew

  • Have you found anything that will result in the PCM2906C recording a S/PDIF signal that has been applied to the PCM2906C DIN pin?

  • Hello Michael Sirkis, 

    I believe this question is related to (+) PCM2906CEVM-U: S/PDIF input doesn’t work. - Audio forum - Audio - TI E2E support forums. I have replied to you in your original thread. 

    Best,
    Andrew

  • Hi Andrew,


    We managed to get our original solution with the PCM1808 (24-bit, 48kHz I2S) and DIT4096 in HW mode to work with the PCM2906C S/PDIF input. The issue was the copyright bit (bit 2) in the S/PDIF channel status data, which needed to be logic 1. To get this we needed to pull the COPY pin (pin 2) high and L pin (pin 3) low on the DIT4096 (HW mode). The PCM2906C only states that it can handle 16-bit S/PDIF input, so we assume that it just truncates the LSB of the 24-bit S/PDIF signal.    

    If anyone stumbles on this thread, the following bits in the S/PDIF channel status data bits were logic 1 in the working configuration, Bit[2, 9, 11, 12, 25, 32, 33, 35], and the rest were logic 0. The Sigrok Pulseview software comes with a S/PDIF decoder, supports a lot of logic analyzers, and where really helpful for troubleshooting this, can recommend.

    One annoying thing is that we still could not manage to program the S/PDIF channel status bits using the DIT4096 in SW mode, the other configuration registers we could program without any issue. Either way, we will now verify our audio solution and determine if we are happy with the quality of the 24-bit to 16-bit truncation or if we need to rethink and go with a 16-bit ADC and try to tackle the DIT4096 in SW mode.             

    Have you found anything that will result in the PCM2906C recording a S/PDIF signal that has been applied to the PCM2906C DIN pin?

    Yes, see above! 

    Regards,

    Jonas