Modify audio on the fly, can do?

Been too busy but I just managed in fixing the CD frequency.
I was wrong on the frequency I use the wrong cd service manual :mad:
New Crystal: 4981-QT49-16.9344MBBK-B-ND
Spdif Fq test.jpg

PXL_20251226_211751811.jpg
PXL_20251226_211910576.jpg


h4yn0nnym0u5e said:
Then, when I disconnect the S/PDIF input, I would expect the chip to detect the loss of lock (which it does) and fall back to the internally-generated clock (which it doesn't). Instead of using the internal clock, I get wildly-varying values for LRCLK and SPDIF_SR_CLK, though at least those two values retain the correct relationship. As the PLL is detectably not locked, I could perhaps fix this in software by changing the relevant register(s), but I don't think that should be necessary, according to the datasheet.
Click to expand...
Interesting I think we need some software SAI reconfiguration depending on SPDIF_SRPC_LOCK.
Original: I2S_TCR2_DIV((1)) | I2S_TCR2_MSEL(1)
SPDIF: I2S_TCR2_DIV((0)) | I2S_TCR2_MSEL(3));
 
Last edited:
Chris O. said:
I think we need some software SAI reconfiguration depending on SPDIF_SRPC_LOCK
Click to expand...
Yes, that was my conclusion, too. Strange, because the datasheet appears to imply S/PDIF transmit will use the internal clock if the receive loses lock, without needing software reconfiguration. I'll get to it at some point, lots of family stuff going on over the holiday :) 🍗🍾
 
OK, after a lot of distractions, I've done a bit of work on this and have a work-in-progress branch for consideration, if anyone's interested. As it turns out the fallback to the built-in clock doesn't appear to work as expected if the S/PDIF input goes away, I've bodged in a way for the I²S to be switched by the sketch itself. A code fragment looks like this:
C++: 
AudioInputSPDIF3         spdifIn;
AudioOutputI2S           i2sOut;


// call this "sufficiently often"
void pollSync(void)
{
  bool syncSPDIF = spdifIn.sampleRate() != 0;

  i2sOut.syncToSPDIF(syncSPDIF);
  i2sOut.grabUpdateResponsibility(!syncSPDIF);
  spdifIn.grabUpdateResponsibility(syncSPDIF);
}
This assumes spdifIn should have update responsibility if there's a valid incoming signal, otherwise i2sOut should have it. This will be dependent on your specific sketch.

So far I've only implemented the syncToSPDIF() method for stereo I²S output. I should definitely do it for I²S input and
AudioOutputSPDIF3, and ideally any audio I/O which admits to being clocked by the recovered S/PDIF clock. Unfortunately this doesn't include TDM, as it needs a faster base clock.

I should point out that as part of this, I've integrated the "copy permitted bit" update by @jmarsh, as discussed on this thread. Kudos to him for that. But please note, I haven't tested my integration as yet, so I could have broken it. I will test it soon.
 
Bugfix update pushed: intermittent S/PDIF tends to cause weird PLL speeds (nothing to lock to), which in turn was resulting in an attempt to transmit NULL audio block pointers. This isn't trapped by the Audio library, and the Teensy crashes...

Still need to do the other I²S stuff, and MQS (which uses SAI3). I think nothing else can be clocked by S/PDIF input.
 
No, it wasn't ideal! I'm guessing you're using the previous branch, which I've left intact while I break stuff on the new one. That probably doesn't have that issue, it's just when I try to flip back and forth between recovered and internal clocks.

Is your AudioOutputADAT3 internally clocked, or synced to S/PDIF? It's really frustrating that NXP didn't think to recover a 2x or 4x clock, as what we're given is too slow to run anything but I²S, as far as I can tell. It can't even run the "hacked together" S/PDIF on SAI1 and SAI2, let alone TDM. I mean, it's probably not a major use case, but still...
 
h4yn0nnym0u5e said:
Is your AudioOutputADAT3 internally clocked, or synced to S/PDIF?
Click to expand...
I wish I could tell you all the details but it's been a while since I was working on that project (about 3 years).
From what I remember all SAI 1~3 is running in slave mode and it's not synced to S/PDIF this is one of the reasons I am interested in this synchronization.
 
OK, fair enough. Do say if you have a specific routing in mind, but bear in mind I don’t have any ADAT kit so it’d be hard to test. Though if there’s a cheap interface you could recommend, I might spring for it.
 
You must log in or register to reply here.
Back
Top