-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sACN Sync Packet #1940
Comments
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)?
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...
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.
So in terms of other "protocols" where sync would be relevant/beneficial, there's these that I'm aware of:
|
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:
I see evidence of a KiNET sync method as well, but I don't know how it is implemented.
The text was updated successfully, but these errors were encountered: