I have a product that has been in the market for several years now using the ADAU1452.
It's only limiting factor for us right now is that the SPDIF input on that part maxes out at 96khz and we have many customers wanting to use 192K (or higher) PCM spdif data input into our product.
I am testing with doing a drop-in replacement with the ADAU1462. So far, I am having some issues.
The program doesn't run perfectly with no changes. This may be related to the changes in the DM paging. Or maybe there is another PLL change?
The SPDIF input through the ASRC appears to be working only to 96kHz and the TDM128 Inputs and outputs appear to now be at the wrong word rate. We are expecting to run at 24Bit 96khz i2s over TDM128. 4CH per a serial port. And this is all functioning correctly on the ADAU1452. Dropping in the 1462, the L-R Clock for the serial ports connected to the ADC and DAC are both now running at 192kHz. Our MCLK Frequency is 24.576mHz.
So: The questions are:
Is this expected for doing a drop-in replacement of the 1462 in place of the 1452 for the clocks?
If so, and a recompile in SigmaStudio will fix that, is there a register we can query in the DSP so our firmware and customer GUI know which part is installed and the proper image sent over?
And the SPDIF input is the real kicker for us. Is the 1462 really work at 192K on the SPDIF input reliably? Will the above recompile currently fix the issue that the I am seeing with this where the 1462 with a 192kHz SPDIF input has regular dropouts and clicks.
The '52 and '62 are fully pin and code compatible. A program compiled for the '52 will run on a '62 without modification. The serial ports and clocking are identical. Unfortunately, there is not register that can be read to distinguish between the parts.
The trick to getting the S/PDIF to run at 192 kHz is found on the SPDIF tab of the register tab:
The clock used to control the receiver and transmitter blocks must be set to run at SYSCLK rather that SYSCLK/2. The latter setting is the default only to maintain full backward compatibility.
Ken, could you elaborate on that last point? The fact that these registers exist at all and default to 1 (SYSCLK/2, i.e. no 192 kHz support) makes me a bit nervous. Is there some undocumented downside to setting these registers to 0 (SYSCLK) ?
By the way, the ADAU1463/1467 datasheet (r0 and rA) describes these registers incorrectly in the "S/PDIF INTERFACE" section on page 74. It claims RX/TX_MCLKSPEED bit needs to be set for sample rates above 96 kHz, whereas it actually needs to be cleared.
The ADAU1462/1466 datasheet (rB and rC) doesn't mention these registers at all in the "S/PDIF INTERFACE" section, nor does it list them in table 49 ("S/PDIF Interface Registers") on page 75, nor are they described in the "CONTROL REGISTER DETAILS" section.
Thank you for pointing out these missing registers, and I apologize for the errors. Updates for both of these datasheets, as well as the eval board manuals for these parts, are in the works. I understand why these registers make you nervous, but you don't need to be. The designers began work on the '6x parts with the '5x design database, and they only added logic. None was removed. That is the reason these registers exist.
I've just double-checked on the bench. For 192 kHz operation, RX_ and TX_MCLKSPEED should be cleared as you have observed. Graphically:
Other required configuration:
Enable the S/PDIF transmitter in the routing matrix, and configure an ASRC as follows:
Since the audio is passing through an ASRC, you will not get bit accuracy. This is necessary since the recovered clock will not be synchronous with the DSP core. However, I'm seeing optical-to-optical THD+N at about -132 dB on an AP. There is a good discussion here regarding avoiding pops and click on loss of S/PDIF clock (e.g. the cable is removed).
Again, I apologize for errors in the docs. In the meantime, I'm happy to answer any other questions that you may have here.
To comment on Ken's response.
We do have a tool in our GUI to twiddle registers in the DSP for testing.
The ADAU1452 parts will always read this address. (0xF606) as a 0 even if a 1 is written too it.
The ADAU1462 does read initially with a 1 and clearing it to a 0 does allow the SPDIF interface to sync at a faster speed.
Writing to that address on the ADAU1452 parts seems to have no change in behavior.