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

["James McCartney" <asynth@xxxxxxxxx>]

The issue of hardware clock drift was certainly understood when
deciding to use OSC time stamps. SC3's goal was not sample accurate
scheduling, but accurate distributed scheduling based on a shared
clock (NTP time). So even on servers running at different sample
rates, you get simultaneous events. An anchor point and rate scalar
can be computed between the actual hardware rate and OSC time on each
server and broadcast to interested clients.


On 11/28/07, blackrain <blackrain.sc@xxxxxxxxx> wrote:
> It would be great to listen to what Mr McCartney thinks.
> Maybe he already has something in mind.
>
> x
>
> On Nov 28, 2007 7:31 PM, Scott Wilson <i@xxxxxxxxxxxxxx> wrote:
> > Might be worth running this by James McCartney if he's not already
> > following this thread. I believe he mentioned this issue in his talk
> > in the Hague, and the general desirability of scheduling against a
> > variety of different clocks as needed.
> >
> > S.
> >
> >
> > On 29 Nov 2007, at 00:26, 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
> >
> >
> > _______________________________________________
> > 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
>


-- 
--- james mccartney