[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] [RFC] sample accurate scheduling

Hi all,

Here is a possible approach to long term synchronization:

	Server sends an incremental samplesComputed number at some interval
	The OSCresponder subtracts that value from samplesProvidedByClock

	Clock adds samplesComputedInInterval to samplesProvidedByClock and
blocks if that value exceeds maximumComputeAhead If the server and the language are running on the same machine, you can almost certainly allow maximumComputeAhead to be a negative number corresponding to the maximum server latency (i.e., the server will be late with its reassurances everything is ok, and the system can make an allowance for that.)
For this to work, the Clock runs a little fast relative to the servers physical sample rate (not at a higher sample rate, just thinks time is passing a delta faster). We don't need a fancy PLL, just setting the clock to prevent starvation is enough.
Another question is the amount of clock jitter acceptable at the language end. This really depends on what else is happening. For graphics, 10 msec will be fine, for parallel musical systems ("MIDI" by which I mean non-sample accurate performance on another server) you probably want that tightened down to 1 msec. If the sample clock variance is +-0.5%, then worst case is 1%, so 1 second updates would suffice for graphics and 1/10 second for MIDI. (I guess we need to fold in the maximum discrepancy between the language clock and the sample clock to make this fully accurate, but this is a reasonable ballpark figure.)
So long term syynchronization boils down to a TempoClock that blocks. This seems a litttle easy to me, 
so it may be nonsense.  If so, tell me why!

RJK



On Nov 28, 2007, at 7:26 PM, blackrain wrote:


Since the lang does not have an idea of how much time it takes a
sample step for the synth, we give an offset in samples; the synth
will make the bundle effective based on that delta.

if we schedule a synth spawn for 1 sec in the future, scsynth will
execute the event in 1 second from the time of request but we have no
warranty that 1 second will be exactly 44100 samples from now (@
44.1kHz).
Scheduling a synth spawn 44100 samples from now will be 44100 samples from now. 

we dont really need to know a sample count in the lang. latency will
allow us to play with delta samples times and always land exactly
where we want.

if there was the need, a PLL approach may work to obtain an interface
sample count but will probably result a bit expensive; depending of
course on the sync rate and the application.

in fact, we can still sort of calculate deltas in time (within bounds
as the examples I posted) but schedule in samples and we will be sure
the result will be there.

what I meant about the one sample impulse was in order to sync other
apps that may be connected thru digital audio lines to the synth -
this applies to other hosts too.
in that case the coreaudio clock for both interfaces (the same digital
clock) will advance at the same rate.
for a setup like that, all we need is a one sample impulse from the
foreign app to tell where play was engaged for example.

#sbndle (thinking a bit - still 8 bytes) will not break the current
standard implementation.
the server will know it is receiving a bundle that states a delta in samples. 
we can use a Float64 to state deltas and be ale to handle subsample
accuracy instead of the usual 64 bit integer used to form time stamps.


x

On Nov 28, 2007 5:52 PM, Sciss <contact@xxxxxxxx> wrote:

maybe you mean a kind of PLL (phase-locked loop) or servo-controlled-
clock on the sclang side? so it queries in intervals the current
scsynth clock and adjusts itself accordingly, so that s.latency for
#sbundle's stay in a safe range?

Am 29.11.2007 um 00:43 schrieb Sciss:



sounds interesting, but (maybe it's too late in the night) i don't
yet get how the #sbundle approach is working.

Am 29.11.2007 um 00:32 schrieb blackrain:
[...]

All that is needed like Jan states, is a one sample impulse and a
responder to tell where the synth is.


_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://www.create.ucsb.edu/mailman/listinfo/sc-devel


_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://www.create.ucsb.edu/mailman/listinfo/sc-devel


_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://www.create.ucsb.edu/mailman/listinfo/sc-devel