adau1467 - using register 0xF602 to detect the incoming S/PDIF wordlength

Hello StasT,

Sorry for the delay in response.

Though I don't have a complete detailed info on this, but I will show you what I tried.

For a 24-bit word length, you should get the value 0x2EC on SPDIF_RX_DECODE Register (0XF602).

To get the value, you should change the SPDFI_TX_CS_Right 9 (0XF6B9) and SPDFI_TX_CS_Left 9 (0XF6A9) register values. If you set the value 0xBB (187), it will match with a 24-bit word length. Please refer to the below settings.

If you set this in the Tx side and set the source in SPDIF page as "source from register map", then in the SPDIF reception, you will get the respected value that you want. I checked this with loopback method as well as giving the (Tx) signal to another SPDIF receiver. please look below.

Regards,

Harish

Hello StasT,

Thanks for bringing this to our attention. I had been working on this for the past couple of days and did not know that Harish was also working on this. In this case it is great that he was because he did find a way to send and receive this data. I was running into a brick wall on this. I am using an Audio Precision 2700 and it seems that the SPDIF implementation they did does NOT send any data for word size! It also does not receive it or report it.

I looked up the specification for SPDIF and I was only able to find an old spec but what I found was that it is byte 5 that is where the word size data is located. So I was trying that and it was not working. Then I see the response from Harish that he changed byte 9! 9? Really? So there may be some issues with our implementation as well and I am going to seek the formal specifications internally here at ADI. Meanwhile, you can use what Harish suggested and it does seem to work. However, I do not know if it actually changes the word size? I worked on this all day so I need to get on with some other issues.

I did do something else for you. I put together a program that simply looks at the bits and reports the word size based on the data in the audio. If there is dither it does not work as well but I think putting in a debouncing block might fix that.

So this may or may not help you. It was a good exercise for sure. I tested it using the Audio Precision.

ADAU1452 SPDIF Loopback Bit Depth Sensing Example.dspproj

I also was using the ADAU1452 DLL for this program so the register map page will look a little different. We did not change much when we went from the 1452 to the 1467. We only changed the clocking to allow SPDIF to go to 192kHz.

I hope this all helps.

Again, thanks for pointing out these issues. I will investigate more and hopefully improve things for the future.

Dave T

Hi Harish and Dave,

Thank you both for the replies. We're seeing that '11' decimal is enough in both of those registers to show 24-bit operation. When we measured the channel status word output from another commercial S/PDIF source, we saw the following values (in decimal):

Frequency
Wordlength
#9
#10

44.1kHz
16bits
242
32

44.1kHz
24bits
251
32

48kHz
16bits
210
544

48kHz
24bits
219
544

96kHz
16bits
82
2592

96kHz
24bits
91
2592

192kHz
16bits
18
3616

192kHz
24bits
27
3616

We were also surprised to find the wordlength in word #9. But after thinking about this for a while, we believe the entire map is reversed, and then it should make sense, since there are four bytes "below" the wordlength setting which agrees with the maps we're finding. I think we can all concur that more documentation on this point would be nice, even if it's just to state that the map is reversed from what one would normally expect (big-endian, in a partial sense).

We're not seeing any ability for the ADAU1467 to detect professional stream headers. We tested setting bits of the final, or supposedly lowest, word, which should enact the AES3 header type, but the wordlength remained properly detected even though it should have moved in the map. This would imply that we can't receive any sense of rate above 48kHz, as it doesn't appear that the consumer version has any place to share this. That said, the table above suggests that the reserved areas which we see described may later have taken on additional meaning, but we can't find free documentation on this. It may then be safest to just copy the table above for most use cases. We're fine with printing the sampling frequency gleaned from the ASRC ratio registers for all three of our input types, but we were just concerned that some equipment may not be able to do this based on our S/PDIF output.

Thank you, Dave, for sharing that schematic - it's got a lot of good stuff in it. Ideally we would like wordlengths for our I2S inputs (Bluetooth/USB) as well, which of course aren't directly available in the registers. We believe the optimal way to implement this would be through a post-filtered XOR function between the current sample and the previous sample, where a nonzero filter output would indicate entropy on certain bits. That way, the lower bits could all be '1' permanently and it would still work. The filter would provide ride-through in situations where the bits didn't change temporarily, such as for short muted periods. This may take a little while to draft and test, though.

This is somewhat off-topic, but we've found that the programming executive on the ADAU1467 has a bug where about 1 in 200 EEPROM page write commands is ignored, leaving the page still empty with all '0xFF' values (at least with 256-byte-page SPI EEPROMs). We load/command the executive directly via a microcontroller and have resorted to doing an immediate page verification to work around this problem, and reissue the write command when necessary. On some systems we can hardly get SigmaStudio to program the EEPROM through the DSP at all, and we find no SPI communications to the EEPROM in many of those cases - yet thankfully our own code works quite reliably as a backup programmer. We're also aware of at least two other SigmaStudio bugs which we may post about, time permitting.

Thanks for the help,

- Arthur M. and Stas T.

Hello Arthur and Stas T,

Thanks for the info and investigations. It seems like the SPDIF/AES3 "standards" are a bit of a free-for-all and not as standardized as it should be. I have run into this before for other issues. Like the Validity Bit. We do not implement it but others do. You are correct that we only implemented the consumer SPDIF standard and did not make an attempt to follow the professional formats. I wish we had made that an option but it would have complicated things even more! Many customers have used our parts and converted the output to the 110ohm AES3 electrical level formats and it works for most other products. Using a transformer is the best solution in my opinion.

It is interesting about the page write commands. I have seen issues with programming due to having the Selfboot enabled while trying to do it. I explain it in this post:

(+) Selfboot Problem on ADAU1452 - Q&A - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone (analog.com)

I will report back as I get more information and find the documentation for the actual standard.

Dave T