somedev My thought is that a digital go signal can start multiple bela units playing, but the specific frame number within an 8 frame block in which the digital go is received is not guaranteed. Thus the belas may commence playback at slightly different times.
That may be down to your software ... Bela samples the digital inputs at the same sampling rate as the audio, so you can achieve sub-sample time-alignment if your software does it properly. In C++ this is relatively easy, but if you are using PureData, you should try and do everything in the signal domain, as when you start using messages I think these get quantised to the block.
Generally speaking, one issue you may have when using more than one Bela unit is that the clocks will drifts between each of them (i.e.: 44100Hz is never exactly 44100Hz, but they are always slightly off between each other by some hundred part per million (or worse, depending on the crystal's accuracy). If you cannot tolerate a minimal amount of drift, which could easily cause the boards to drift off by one samples every few seconds, then you should consider synchronising the digital clock generators, using one board as the clock generator and routing its clock signals to the other boards. These are high-speed signals (1.4MHz at least), so signal quality cannot be easily guaranteed without appropriate routing. This ensures the frequency of the sampling is synchronised between different units.
Synchronising two boards at the block level may require some changes to the PRU code, so that
N-1 boards wait for a GPIO from the main board before they start clocking out samples. This ensures that the phase of the processing is synchronised between different units.
All of this is doable, but it is not straightforward, so you should probably ask yourself: what (if any) of this do you need? If you are doing recordings that are a no longer than a few minutes and the inter-board phase accuracy is not critical, then I'd guess you probably don't need any of these.