Hello everyone,
After some emails and quite some tests I had with Mr Joshua Parmenter
and Mr Ryan Brown, We came to the conclusion that the scheduling
model based on OSC time stamps (Host time stamps), renders inaccurate
results primary because of hardware interface fluctuations from the
nominal sample rate.
So far SuperCollider's model of sample accurate synthesis has been
based on a naive evolution from nyquist: OSC assumption - sample
period should be at least half lower (in fact is - much lower) than a
resolution the protocol is able to handle.
However, and sadly for us mere mortals, hardware interfaces` sample
rates drift (1).
The OSC model expects to deal with a world where a sample rate of
44.1kHz takes exactly 44100 samples per sec.
Real life shows, unless you are chained to a $3k house sync word
clock
or use a $1-2k interface, this wont happen (and then I smile at
subsample accuracy =) )
The end result is that OSC bundles will target calculated sample
times
which are best guesses.
After a bit, the three of us thought that it may be better to use OSC
to serve as a sleeve to our purpose and schedule a packet on a sample
count delta - OSC's original implementation never thought of this.
The idea is simple and here is the proposal:
The Lang does not need to know an interface sample count but only how
many samples I want a bundle to be effective from 'now'.
We can use a hack of OSC's current implementation and the creation of
a primitive:
NetAddr:sendSampleBundle
...end use for the rest of us is:
s.sendSampleBundle(44100.0, bundle...
(notice the float - subsample accuracy for us to deal with next.)
Then, Server:sendBundle could convert a time stamp into a sample
value
for the future:
s.sendBundle(0.1, ... )
becomes
s.sendSampleBundle(4410.0, ....)
Here are some facts about the current interface:
(
k = 2.pow(32) - 1;
SynthDef("counter", { arg request_bus=120, reset_bus=121;
SendTrig.ar(In.ar(request_bus), 1010,
Phasor.ar(In.ar(reset_bus), 1, 0, k, 0) )
}).send(s);
SynthDef("ctrl", { arg bus=120;
Line.kr(0,1,0.1,doneAction:2);
OffsetOut.ar( bus, Impulse.ar(0) );
}).send(s);
)
(
r = OSCresponder(s.addr, '/tr', { arg t,r,m;
l = l.add( m.at(3) );
m.postln;
}).add;
)
s.sendBundle(0.1, [9, "counter", 2000, 0, 1, "request_bus", 120]);
(
l = nil;
p = Routine({
loop {
s.sendBundle(0.1, [9, "ctrl", 2001, 0, 1, "bus",
120] );
1.wait;
}
}).play(SystemClock);
)
p.stop
(l.size - 1).do({ arg n; (l[n+1] - l[n] ).postln; });
Server:actualSampleRate playing in:
(may need to run this several times till you get a good value for k)
k = (s.sampleRate / s.actualSampleRate);
(
l = nil;
p = Routine({
loop {
s.sendBundle(0.1, [9, "ctrl", 2001, 0, 1, "bus",
120] );
k.wait;
}
}).play(SystemClock);
)
p.stop
(l.size - 1).do({ arg n; (l[n+1] - l[n] ).postln; });
The point is, we can sort of tell now (within bounds exposed above)
when a hardware interface rate doesnt fluctuate that bad and forecast
a sample position.
Yet this is not good enough when we want to schedule packets long in
the future or scheduling events based on an anchor obtained in the
past from a foreign source or yes, performing sample accurate
synthesis.
So it seems that what we really need is a sample based spawn model.
Mac's Built in interface seem to be quite solid but stressing the
processor's load makes things look odd (2).
linux implementation of Mac built in HW alsa drivers seems to be
'ok'
and I want to see them under stress - the first 3-5 sample figures
are
way off mark.
I can speak for what I have, an 001 - d!g!design with focusr!te
converters chained in: I get a rock solid timing under 10.2.8, zero
drift - I use it under 10.4.10, a hack install on a 2 GB, 1.5 GHz 2MB
L3 cache G4 ( 001's were never meant to be around this long) and the
card timing SUCKS. Works kewl you would not notice it but still.
We would be more than glad to listen to other suggestions or ways to
possibly go about this.
Josh remembers that Sciss was having problems with sample accuracy
also... Sciss - did you figure out a way around this???
1 - s.actualSampleRate
2 - the hal time stamp generator does a grand job, even when
overloads
but somehow it _still_ drifts a bit when pushed.
regards,
x
_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://www.create.ucsb.edu/mailman/listinfo/sc-devel