Re: [sc-dev] scsynth audio driver, behavior of oscTime variable

[Scott Wilson <i@xxxxxxxxxxxxxx>]

Just a guess, but oscTime will drift relative to to the audio driver. On Mac at least this is periodically corrected. I imagine doing this could have an effect, as could not doing this. Not sure what Linux does here.

For totally sample accurate scheduling we would need the oft proposed AudioClock.

S.

> On 29 Nov 2015, at 11:06, James Harkins <jamshark70@xxxxxx> wrote:
> 
> I was trying today to track down those discrepancies in the behavior of OffsetOut that I mentioned in a thread on sc-users. I found that OffsetOut looks up its offset in the graph's sample offset member variable, so I looked up where that comes from. This is set in the audio driver's Run function. (As I'm in Linux, I'm looking at the Jack driver.)
> 
> void SC_JackDriver::Run()
> .....
> int64 oscTime = mOSCbuftime = (int64)((mDLL.PeriodTime() - mMaxOutputLatency) * kSecondsToOSCunits + .5);
> 
> The offset comes from the bundle's scheduled timestamp minus "oscTime" -- I'm assuming this is the timestamp st the beginning of the current control block but I could be wrong.
> 
> while ((schedTime = mScheduler.NextTime()) <= nextTime) {
> 	float diffTime = (float)(schedTime - oscTime) * oscToSamples + 0.5;
> 	float diffTimeFloor = floor(diffTime);
> 	world->mSampleOffset = (int)diffTimeFloor;
> 	world->mSubsampleOffset = diffTime - diffTimeFloor;
> 
> 	// scprintf("sched %llu, osc %llu, osc2samps %f, diffTime %f, offset %d\n", schedTime, oscTime, oscToSamples, diffTime, world->mSampleOffset);
> 
> 	if (world->mSampleOffset < 0) world->mSampleOffset = 0;
> 	else if (world->mSampleOffset >= world->mBufLength) world->mSampleOffset = world->mBufLength-1;
> 	SC_ScheduledEvent event = mScheduler.Remove();
> 	event.Perform();
> }
> 
> I confirmed, with an scprintf, that the scheduled timestamps are exactly 1 second apart, matching the language-side code. I don't know how to read the oscTimes as yet.
> 
> I'm running 44.1kHz with a 64-sample block size. 44100 % 64 = 4. So, for events 1 second apart and assuming perfect sample accuracy, I'd expect the offset of each subsequent event to increase by 4. Because the sample clock is inexact, I can't assume that, but still I would expect a deviation of no more than 1-2 samples per second. Instead, when I print the offsets, they appear to be entirely arbitrary. The sound is also far, far wrong, and recording impulses into a buffer and analyzing the IOIs reveals really quite bad timing errors.
> 
> The one piece I've observed that doesn't immediately make sense is oscTime. It appears, in Linux, that this comes directly from Jack. Are we doing something wrong with this number?
> 
> I'm attaching an scd file with analysis code and data. A WAV file with the impulse stream that I was analyzing is at:
> 
> http://www.dewdrop-world.net/download/OffsetOut-data.wav
> 
> hjh
> 
> <OffsetOut-data.scd>


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/