How to transmit/receive SPDIF user data reliably?
For a stereo active speaker system, we need to send the same SPDIF audio and control information to ADAU1467 devices in both speakers. The approach is to make one speaker a "primary" that receives the SPDIF audio and then transmits the audio and control information to the "secondary". We have an optical cable that connects the primary to the secondary, and this works fine for the audio. However, we are trying to send the control information (volume level, filter and EQ settings, etc.) using the User Data bits. This approach seems to work, but we are concerned about making sure we send valid data from the ADAU1467 primaryand that we receive it correctly.
On the transmit side, we can put the data into the registers at 0xF6C0 to 0xF6CB, but how do we make sure the data isn't sent out while we are in the process of updating the registers? That is, how do we synchronize our writes to the start of the 192-bit block to ensure that all the data in the registers is transmitted while the data is valid and not partially written? We want all 12 user bit words to be sent out at the same time. Obviously, we could read the data on the receive side and only accept data that is the same for at least two blocks--is that the only way to ensure that the data is sent reliably?
On the receive side we have a similar problem. We expected that we could poll the Receiver Auxiliary Bits Ready Flag Register (0xF60F) to tell us when a new 192-frame block has been received, but once this flag is set, indicating that Auxiliary bits are ready, it doesn't get cleared by reading the flag register or reading the user bits. The flag gets set when it first gets SPDIF data and then it stays set. Is there some way to clear it so we can use it to read the data and ensure it is valid? We tried writing to that register to clear it, but that didn't work. That flag seems to behave the same as SPDIF_LOCK_DET.
Is there more detailed information on using the SPDIF User Bits for this device? We've done this messaging via SPDIF User Bits with the DIR9001 chip but are thrashing with how to accomplish the same with the ADAU1467 (the DIR9001 outputs a block frame flag).
Audio Signal Processors
Datasheet/Specs
adau1467
SigmaDSP Audio Processors
Hello Neildavis,
We are looking into this and will respond to you soon.
Regards,
Harish
Hello Neildavis and Harish,
I am looking into this here where I can talk to the digital designers.
I understand your issue and I have some ideas on how you could do this. How you use the data nits might help.
One engineer I talked to mentioned it would be good to do some sort of CRC or other error checking. Do you do anything like that?
One other question. Do you have any sort of counter that you use? Could you implement a counter?
Are you communicating in both directions? Sending data to the secondary DSP and then sending data from the secondary back to the Primary?
I have some ideas, just need a little more info...
Dave T
Thanks for looking into this.
I think I can implement a solution without synchronizing to the 192-frame block, but it's somewhat "kludgy", and I am hoping there is a better solution.
I only need to go in one direction, from the primary ADAU1467 to the secondary. Each DSP is controlled by an ESP32, and the primary ESP32 receives audio processing commands (volume, crossover, EQ, etc.) via BLE from an Android app. But BLE is point-to-point, so I want to send a copy of the audio and the audio processing command from the primary ADAU1467 to the secondary ADAU1467 using an SPDIF connection. The commands are very short --only 3 to 5 bytes long, so the 12 words of User Bits in the block are adequate.
The kludgy method I am working on is to transmit the command using the User Bits, followed by a "zero" command. On the receive side, the ESP32 samples the User Bits until it sees a command and then waits until the command changes back to "zero". If the timing is right between the primary and secondary CPU's, this should work OK, as long as valid data is latched into the User Bits on the primary side.
I assume the User Bit shift register is double buffered, but my concern is that I don't know when the data gets latched into the shift register, and it is possible that it gets latched while I'm trying to write into the data registers. If I could poll a register that told me when the block started, I could be assured that the data was valid. But I don't see any such register in the ADAU1467 datasheet.
I was able to make this type of "SPDIF messaging" work with the DIR9001 chip because it had a hardware signal for the start of the 192-frame block, and I used that as an interrupt for the controller. The ESP32 with SPI is fast enough that polling would work, but I don't see anything in the datasheet that I can use to synchronize with the SPDIF block.
It seems a bit odd to me that there are so many pages in the datasheet devoted to the SPDIF auxiliary bits but no mechanism to synchronize to the frame--that's why I asked whether there might be some other information that might not have made it into the datasheet.
Thanks again for looking into this.
Please log in to reply.