The general idea is to use a state machine which resets itself when Teensy sends the frame sync pulse, in the cycle before the beginning of a 256 bit data frame.

So the second CS42448 chip which gets the state machine's frame sync will be operating 16 cycles "behind" the first chip which gets its frame sync pulse directly from Teensy.

Then all that's needed (I hope) is some 2:1 muxes to route the data each CS42448's 16 upper bits to/from Teensy while the other chip's 16 low bits get ignored.

Initially I though I would need to use a CPLD or small FPGA.  I even asked friends on Twitter for which parts are best to use these days...

https://twitter.com/PaulStoffregen/status/1339052117072470025

But then pondering this for a while, I started to think maybe just some 74 series logic chips could do the job.  Since this little side quest project is just going to be a blog article, without kits or parts sold, having to set up an unfamiliar toolchain just to program a CPLD for 1 board seems like quite a barrier to DIY building.  A small collection of 74 logic chips is more parts to buy & solder, but has a nice simplicity.

I started looking at specs.  74HC parts at 3.3V are pretty slow.  This data stream uses an 11.3 MHz clock where data changes on the falling edge and needs to be stable 44ns later at the rising edge.  There's already some propagation delay in the chips, so adding a few dozen nanoseconds might just barely work, but seems risky.

Fortunately, 74LCX parts have much faster timing.  The big downside though is the selection of chips in LCX family isn't nearly as good as HC.

After some research, I found 74LCX163, which is a 4 bit synchronous counter which can be cascaded.  So I decided to use 2 of those to count where we are in the 256 bit frame.  By another stroke of luck, I found 74LCX157 exists, and it's rated to add only 5.4ns (worst case) from signal in to signal out.  It should be able to get its control signal directly from one of the 74LCX163 binary count bits.  The 74LCX163 has a worst case delay of 7.3ns from the clock edge to its count output.  So together those add up to a worst case delay of the audio data stream by 12.7ns.  That's about 29% of the half cycle time, so hopefully whatever that CS42448 and Teensy are doing now gives at least that much extra timing margin.

So that's the plan at this point.  And a secondary goal is to try using Hackday's project site, not like a blog where I get it all working and post a nice polished (relatively speaking) result, but rather try updates along the way.