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

[Scott Wilson <i@xxxxxxxxxxxxxx>]

*** ERROR: SynthDef rec not found

> On 29 Nov 2015, at 12:43, Scott Wilson <i@xxxxxxxxxxxxxx> wrote:
> 
> 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/


_______________________________________________
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/