sACN Sync Packet

[DaAwesomeP]

I recently learned of the sACN sync packet. It is defined in E1-31-2018 sections 1.5, 4.2, 6.2.4, and 6.3.

I would be great if OLA was able to:

• Send sync packets as a part of the advanced API
• Receive sync packets and hold proxying non-sync-capable protocols across universes until sync packet is received
• Also allow for API-induced sync packet/method when sending data to protocols without sync

I see evidence of a KiNET sync method as well, but I don't know how it is implemented.

[peternewman]

• Send sync packets as a part of the advanced API

So the first thing on this front is probably to establish what if any other data the union of the different sync packets. Are they all independent of, or are some in addition to a DMX packet (e.g. a sync flag within a DMX over IP packet)?

• Receive sync packets and hold proxying non-sync-capable protocols across universes until sync packet is received

Yeah this was what I was imagining. Probably some generic re-usable block of code which can take and store DmxBuffers until it needs to send them on. If it can be triggered by either a specific call, or when a particular DmxBuffer is set, it could allow a variety of useful functionality, potentially even beneficial outside of this particular use case. It can also be fairly easily unit tested to confirm it's behaving as expected.

I suspect this bit is probably the easiest bit to implement as it's just supporting something the protocols already support.

Remember the internal OLA infrastructure doesn't (currently) know the sync status of the end port, so it could either always proxy (which would just work into e.g. a USB interface), or have a setting where it passes the data on immediately and then sends the sync packet on cue, which would allow bridging say Art-Net sync to sACN sync.

Obviously sync across two different USB interfaces (or indeed two different synced plugins (e.g. sACN and Art-Net) may not work as intended timing wise...

• Also allow for API-induced sync packet/method when sending data to protocols without sync

Again we'll need to scope this out a bit. The E1.31 model of assigning each actual universe to a sync universe may make sense (or even doing it in the set DMX call). If people potentially want say multiple different sync planes, or data is coming from multiple sources and being merged, there are a few edge cases to consider.

I see evidence of a KiNET sync method as well, but I don't know how it is implemented.

So in terms of other "protocols" where sync would be relevant/beneficial, there's these that I'm aware of:

• sACN as mentioned
• KiNET as you mentioned above
• Art-Net as mentioned in their guide/already somewhat supported by us
• On the more abstract front there is:
  • SPI - Our plugin already has a concept of a sync port, to trigger when the SPI data is sent, but could take an internal sync packet too
  • Open Pixel Control - Up to 65k bytes per message, currently we just send a full frame, but sync would let us expand that
  • Scanlime Fadecandy - The device is no longer made from what I understand, but again it can output more than a universe of pixels per port
  • OSC - In theory we could send bigger sets of data then, I don't know what the actual message size limit is, probably an edge case that's unlikely to be too relevant