NI SPDIF Input Module

Question

Has anyone tried to use the NI SPDIF Input Module? I already checked the document, but still, I am having troubles making it work. It doesn't read a 48 KHz signal with a 7831R board.
Thanks for any suggestions.

Answer 1

I have two suggestions to try.
In regards to developing your own SPDIF reader; when you only measure the pulse lengths you get the proper readings, but as you add more code to the loop the readings changes and become incorrect. This is most likely a result of the extra code slowing down the loop and causing it to not run fast enough to read each pulse. Using a regular While loop in LV FPGA, each function block you use takes up at least one FPGA clock cycle. In addition the While loop has an overhead of two FPGA clock cycles. So assuming you have a While loop with 5 consecutive functions it will take 7 clock cycles to run each iteration of the loop. If you were to use this loop to measure the pulse length it would give you a measurment with a resolution of 7 ticks, i.e. the pulse length would be 7, 14, 21, 28, etc. As you add more code to this loop the length of each iteration increases and the resolution of the pulse width decreases. In order for us to adequately measure the width of the pulses in the SPDIF signal we need to have a loop iteration time of less than 6 or 7 clock cycles (about half of the shortest pulse we want to measure). This is the reason why the original SPDIF code is set up in three different loops and the first loop that measures the pulse width is kept very simple. It also uses pipelining to further reduce the time of each iteration and we compile the FPGA for a 80 MHz clock rate to get more clock cycles per pulse. I think in your code as you add the Case structure and additional code, you are increasing the loop time above the necessary limit.
One 'easy' solution to this problem is to use the Single Cycle Timed Loop (SCTL) instead of the While loop. This loop is processed differently by the compiler so that all of the code inside the SCTL is executed in one clock cycle. (The SCTL was not available in LV FPGA when the original SPDIF code was developed, otherwise we would have used it then.) So in the updated SPDIF code we use the SCTL and can include all of the SPDIF processing in one loop. There are some limitations on the code that can be included in a SCTL. Information about the SCTL and optimizing FPGA code can be found in this prsentation (Advanced FPGA Programming). I think if you convert your code to the SCTL (right click on the While loop and chose Replace with Timed Loop) you should be able to measure your signal correctly.
Getting back to the SPDIF code I included on my last post. This code does work correctly on my end with a SPDIF signal coming from a Soundblaster sound card. This signal has two raw audio channels with 20-bit data per channel. The 4 AUX bits in the SPDIF packet are not used. I have logged the data to file and can load the file using the Reader VI included in my last post. To play the sound back on a regular sound card in LabVIEW I have to resample the data to 44.1 kHz and then use the upper 16-bits of the 20-bit audio signal. I'm attaching a sample file of logged data on this post that you can open and play back using Read SPDIF Data File.vi.
Is there a chance that the audio data in your signal is formatted differently? Could it be using 5.1 or 6.1 encoding with DTS or Dolby?
Christian Loew, CLA
Principal Systems Engineer, National Instruments
Please tip your answer providers with kudos.
Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system,
or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject
to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense
Attachments:
sampledata.zip ‏2987 KB