synchronizing multiple bela units

take my answer with a grain of salt, i am not a BELA dev or an expert on the field..

my understanding would be that playback of the audio is also block based, so it will almost certainly be "out of sync" by a fraction of a buffer since the two bela boards run independently from each other. what you would want to do is to sync the samplerate and potentially also the block beginning and end.. (with a master BELA and one or multiple slaves). i don't think there is a mechanism for that.

may i ask why you need such high precision? what exactly is the application? you won't notice the starting difference in normal audio playback.

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.

I don't know if there is something readily available but we have used this in the past:

/* Convert HSV to RGB (the actual mechanics here0 */
void rgbledHSVToRGB(uint8_t hue, uint8_t saturation, uint8_t value,
        uint16_t *red, uint16_t *green, uint16_t *blue) {
    if(saturation == 0) {
        /* Gray = all colors the same intensity; convert value from 8 to 12 bits */
        *red = *green = *blue = (uint16_t)value << 4;
    }
    else if(value == 0) {
        *red = *green = *blue = 0;
    }
    else {
        uint8_t sector = hue / 43; /* Divide 0-255 range into segments 0-5 */
        uint8_t factorial = hue - (sector * 43);

        /* Intermediate factors for HSV->RGB */
        uint32_t p = value * (255 - saturation); /* Range 0-(255*255) */
        uint32_t q = value * (255*42 - saturation * factorial); /* Range 0-(255*255*42) */
        uint32_t t = value * (255*42 - saturation * (42 - factorial)); /* Range 0-(255*255*42) */

        /* Normalize each intermediate value to 12-bit range (0-4095). All intermediate values
         * should stay within 32-bit range. The numbers below come from reducing the fractions
         * to keep the intermediate value as small as feasible.
         */
        p = (p * 273) / (17*255);
        q = (q * 273) / (17*255*42);
        t = (t * 273) / (17*255*42);

        /* Safety check */
        if(p > 4095) p = 4095;
        if(q > 4095) q = 4095;
        if(t > 4095) t = 4095;

        switch(sector) {
        case 0:
            *red = (uint16_t)value << 4;
            *green = t;
            *blue = p;
            break;
        case 1:
            *red = q;
            *green = (uint16_t)value << 4;
            *blue = p;
            break;
        case 2:
            *red = p;
            *green = (uint16_t)value << 4;
            *blue = t;
            break;
        case 3:
            *red = p;
            *green = q;
            *blue = (uint16_t)value << 4;
            break;
        case 4:
            *red = t;
            *green = p;
            *blue = (uint16_t)value << 4;
            break;
        case 5:
            *red = (uint16_t)value << 4;
            *green = p;
            *blue = q;
            break;
        default:
            /* Shouldn't happen */
            *red = *green = *blue = 0;
            return;
        }
    }
}

In this case, RGB values are 12-bit (0 to 4095) and you probably want them 8-bit, so you have to divide the red, green, blue by 16.

That's surely fine on the analog inputs side: the analog inputs are high-impedance (literally some megaohms). Remember that the analog inputs are 5V-tolerant but the usable range is 0 to 4.096V.

Regarding the digitals, each digital input has a "weak" (tens of kiloohm) pull-down resistor, so when you start connecting many in parallel, they may become "stronger" (i.e.: lower or comparable resistance) than your external 10k pull-up. Still, it probably works fine for a small number of units (2? 3?). This internal resistor can be disabled via software but it's a bit complicated. I would recommend instead, if at all possible, that you wire them up with an external 10k pull-down and then when you press the button you short the inputs to 3.3V. This way, the internal pull-downs won't cause trouble.

Can't wait to see more of this system in action!

somedev Er, wait, only one 10K is needed here.

Yes that would be fine.

Wow, incredibly fortunate indeed! What an incredible archive to be working with. Please do keep on posting updates as you go and we'd love to feature something about this project on the blog in the future.

Good luck! I'm looking forward to the result.