RJHollins wrote: ... but sure hope we get a TROG sighting !
Caeful what you wish for - I get a "Trog Sighting" every day, first thing in the morning in the bathroom mirror - not a pretty sight!
Interesting little chat you've been having while I had my little break (I had a little taste of being Malc, while we got our next big project finished at work - every time I tried to log in, the pixels were swimming in front of my eyes, so I thought I'd better take a rest!).
In general, I'm pretty much in agreement with MyCo (about FS's inner workings) and tester (how do we test these things properly without reference to 'special cases').
Is "supergreen" real? In a sense, it may be - it is entirely possible that introducing a Ruby section changes the way that FS's various threads interact with each other, and that in certain cases it causes 'green' sections to be scheduled in a slightly different way that has a positive side-effect not accounted for in the "theory".
First, let's examine what we means by "sample accurate". The CPU clock has very little to do with this beyond "faster is better" - the clock inside the soundcard determines the sample rate, and send requests to the software to grab samples as and when it needs them. So long as the CPU can complete all of the tasks that it needs to do before it gets another buffer request, and each data point is somehow 'tagged' with it position within the buffer, we can call that 'sample accurate'. But no maths or CPU opcode actually happens at precise sample boundaries except by pure conicidence - the FS 'one sample at a time' model of DSP is just a very clever illusion to make our lives easier as developers.
Unlike green, Ruby is told when these buffer requests happen, and uses them to regulate the flow of data - Ruby doesn't really care about timing, only about the sample 'position' within the buffer (an array index), and that there is a "boss" out there (driver/host) that at some point is going to ask "where are those samples you promised me?!".
And it is not predicting the future either - it just processes as fast as it can, and then waits for the soundcard to tell it when the appropriate moment is to release the data (and the soundcard's latency is what gives it the time to do this).
Now, if a Ruby event in turn creates a green event - will the green event be "sample accurate". It is possible. If the green event were in some way "timestamped" by Ruby to say which sample within the buffer it was associated with, and all such events could be collected and sorted before the next buffer request, they would, to all intents and purposes appear "sample accurate". This certainly seems to be how MIDI events work, as MyCo pointed out earlier.
In fact, we could already see this with SM - the Windows clocks were terrible for scheduling accurate events, but MIDI events coming in from outside the schematic were able to generate green events more rapidly and accurately (again, so long as the trigger and all it's 'descendents' were able to be processed quickly enough).
But that is a pretty big IF - 'green' (and presumably Ruby) have lower thread priority than streams and the ASIO/DS components - if those parts need to do something, and the CPU cycles are running low, the triggers will go into "suspended animation" while the more important stuff gets done, and they might miss the next buffer request and be held over to be done later.
Can this be relied upon? Certainly not! - but it gets more likely the faster your CPU runs, and with schematics that are better optimised to reduce unnecessary triggers.
So it may be that there are beneficial side effects of Ruby due to, for example, the CPU load being spread more evenly with fewer big "spikes", or the Ruby/ASIO combination might be causing threads to talk to each other at more regular intervals. But, once a high-priority thread has possession of a piece of data, no other thread is allowed to change its value, and must wait its turn. If that high-priority event happens to be an audio buffer request, then the data has 'missed the boat', and won't even be in the same buffer, let alone at the same sample
Can working the CPU harder make things work better, as billy seems to see in X11?
This is not impossible either. Most PC's use all sorts of weird and wonderful technology to try an reduce power consumption etc. - for example, by lowering the CPU clock speed and voltages when there is low load - or by buffering data saved to disk so that it can all be dumped in one big chunk.
CPU "throttling" can be a bit of a pain in this respect sometimes, as switching between "normal" and "power saving" modes can take quite a bit of messing around. When the CPU is well loaded, that switching won't happen, and the CPU runs constantly at full power with no chance of "glitches".
Similarly, in day gone by, it used to be recommended to turn off "write behind caching" for hard drives, because the HDD buffer would sit there doing nothing until there was a shed-load of data, and then attempt to dump it all at once right in the middle of a really good recording - better to have it saving small chunks more regularly.
I'm not saying that is definitely either of those things that cause billy's observations, but they are typical of the kind of things that modern PC's do to keep power consumption/temperature etc. down - so there is a precedent for that kind of anomalous behaviour.
