Hi Keith,
Fiirst of all let me thank you very much for the knowledge sharing. We are very appreciated, your input is very valuable to us. This is what SSLMixed community is all about. We are relying on everyone's help to achieve the best possible solution for this community project and in the end everyone will benefit from it.
Just to update you, it's true there's not much posts updates here in the forum. That's partially my fault because I'm trying to manage the community expectations. We've been working hard during these last 6 months and I believe we will start to be able to show our work soon. We have a private Mailing List and most of the weekly action goes there with many boring and complex detail the community does not want to hear about. We are currently prepping to send the first prototype design to manufacture. A lot of sweat have been put into this so we're crossing fingers to have a winner here!
You can see an October update of the project here:
http://forum.sslmixed.com/index.php?topic=694.0Some things have change in the meanwhile, such as box configuration, since now we are confident we'll be able to put 128 I/O in one box only.
We also got back to a modular configuration, but this is only for an internal configuration optimization. There is still no "slotted module" support, and there won't be for pricing reasons.
DISCLAIMER -Now this is going to start to get nerdyBut regarding this topic, thankfully the way we are designing it, both in hardware and software land we've been able to completely decouple the sampling rate issue from the SMPTE rate. This will allow us to mangle with both without having serious system compromise.
I will try to describe the entire process on how we are doing it on our system. To help I also did some diagrams:
On the hardware side we are currently planing to do the initial testings with at least double the max expected SMPTE rate (30fps), which means we will be sampling at least at 60Hz. This will guarantee that we can sample faithfully frequencies up to 30Hz, which i believe is more than suffice to sample fader movement.
Like you said, if 30Hz where enough back in the days, 60Hz will be awesome. Anyways we can very easily mingle with this value since that this is only a software variable in the micro-controllers.
So the data is sampled by the micro-controller and then sent to the main (brain) computer in realtime through ethernet. - The hardware architecture is a bit more complex but for the sake of simplicity lets assume there's only 1 micro-controller - Actually the micro-controller maintains an internal fader status table so only changes will be effectively sent in an update style saving processing time and Ethernet bandwidth (you can also request full updates).
...when the data reaches the main computer that's where the fun begins:
This data is collected by the main computer and updates an internal fader status table. This table always has the latest known fader state and is updated at the rate that the micro-controller sends it. There's only one status per fader, which means new updates replace the older ones.
Here's a diagram explaining this process:
It's important to mention that at this stage there no SMPTE involvement whatsoever. This sampled data is not synced to SMPTE nor has any relation to it. So you could in fact be sampling at 60Hz and have a SMPTE TC input at 25 fps.
Once the data is in the main computer it can be synced to the incoming SMPTE signal:
The way we are saving the data will indeed have much more precision than SMPTE gives it, since 40ms (at 25 fps) is not enough precision to accurately record fader movement nuances, specially if complex fader action occurs in between SMPTE frames. For this process we decided to greatly increase incoming SMPTE precision, by demuxing the frames.
Already in software land we are making "SMPTE" subframes/time divisions. We divide it up to 16 subframes giving us a 2.5ms of inter-frame precision (at 25fps). The frame #1 is always synced to the SMPTE frame, the other frames are internally interpolated by the internal computer clock at SMPTE HZ/16. We expect a bit of clock skew but it's marginal as this gets always re-synced on frame 1.
Here's a diagram explaining this process:
Now the way we internally sample the fader data and sync it to SMPTE is by taking a snapshot at each clock sync/tick of the fader status table, which has the most recent fader status the system has received so far. At each SYNC signal we take a full snapshot and each TICK we have an update-only snapshot (only differences are saved).
Here's a diagram explaining this:
[/URL]
With this process we've been able to effectively decouple the TC/SMPTE sync from the sampling frequency. This will allow us to change sampling rate (at the hardware side) and precision values (at the softwareside ) at anytime without having major system breakdowns and having to resort to weird sample conversions. One detail is still true, if you record data at a certain SMPTE rate, you can't play it later at a different rate.
This is all happening in a asynchronous way so it's very fast.
Would love to know your input about this process. Other members are also free to jump in and share their thoughts too since this is the first time I am posting this information!
Once more thank you very much for your support!
Cheers,
Artur
