The stuck MIDI notes I mentioned in the last log were caused by lost packets in the USB module. Which happened because the USB driver uses a bulk endpoint, and the transition to the CAN bus was not buffered. I added a buffer to make sure all packets are sent to the internal bus, which improved it. I have still noticed some issues with high throughput, so that's something to investigate further.

The I2S connection had a couple of problems, the left and right channels were constantly swapping and the sample rate was slightly wrong. I ended up fixing the sample rate by implementing a simple
PID regulator to adjust the frequency generated by the PLL. The Tx direction regulates the rate by aiming for a set number of samples in the buffer, this lets the USB host dictate the rate of samples while still tolerating some errors. The Rx direction can't do that because the USB driver can send extra samples in a frame, so it uses a running average of the number of samples sent in a frame. The module uses the same clock for both Rx and Tx, so the Tx takes care of regulation when both are enabled. This probably won't settle completely due to jitter in the USB frames, and it still has some stutters, but it is much better.

Trying to fix the audio channel swapping was very annoying. It seems like there only is a problem when the DMA stops, so regulating the sample rate helps during normal operation. It can still encounter fetch errors or stop when the audio stream is turned off. The current solution is to check the word select signal when a DMA block is completed and suspend it if it's wrong. Then restart it on the next positive edge. This solution is not perfect but seems to self-correct most of the time.

A new revision of the PCBs is getting near now, then I can finally fix the hardware issues. But before that, I want to look closer at the CAN bus.