initial delay is too long

[catfact]

somehow have created the situation where material arriving on the write head isn't heard until 2 loop cycles later, instead of 1 cycle as expected. (bad logic somehow in update cycle and read/write offset)

[catfact]

sorry, think i am being tricked by test setup (involving a loopback driver on macos and lots of extra latency)

in any case, added variable offset for write pointer (compared to read pointer,) in samples. 904c5630b5bdd1f3031ddd3aa8812ed60378a86e default is -8. small negative offsets should apply a small amount extra delay. positive offsets double the delay time introduced by the looping interval, minus the offset. (i think?) some small offset is always a good idea, otherwise read and write interpolation intervals will overlap.

[catfact]

no, it's definitely wrong and my statement above is also wrong.

between arrival of signal and first playback, there's an initial delay that's not necessarily equal to the loop cycle time.

what i would actually expect:

• with +N offset (such that write index = read index +N), one should hear a delay of N samples, before the loop cycle delay.
• with -N offset, initial delay should be (loop samples - N).

what's actually happening: the above, but there is an additional (loop time / 2) added to the initial delay. can't explain it yet, clearly have done something crazy.

[catfact]

datapoint: happens with resampling totally disabled

[catfact]

another correction (sorry): the extra delay is actually fixed, and not a function of loop time.

i'm on macos, will check on other platform(s) in case this is just an issue with portaudio wrapper or something

[catfact]

ayup, it appears that portaudio on mojave somehow multiplies the buffer latency by a factor of 10x. yikes! (tested by comparing the portaudio and native drivers in max/msp.)