roar_vs_latency() should have an interpolating mode

[themaister]

When calling roar_vs_latency() a lot (video players typically), there needs to be a way to avoid going over the network to determine this.
I suggest that roar_vs_latency() should have a mode where it returns latency immediately using some kind of calculation. Implementation details should be discussed.

[ph3-der-loewe]

If it has such a mode. The data returned will depend on old data. So you need to call it from time to time. Where and when do you plan to do so? If you do this in a background thread, for example the same thread as you run your iterates this requires locking which is not yet implemented.

[ph3-der-loewe]

The uncontrolled latency at my test was approx 12.7 times ctime (=1/cfreq).

The band is nearly symmetric with a width of ctime/2, so it's 12.7*ctime ± ctime/4.

Peaks are all negative in my case within a band ctime lower. So the general band for latency values is:

(12.7-n)*ctime ± ctime/4, n ∈ ℕ.

The latency seems to grow and fall saw like but this is normal if you do not include time between _write() and _latency() in calc. If we correct this the value looks very stable.

It seems like a interpolation using a PT₁ system works good. Extrapolation seems to work nicely using this formular:

lag_k+p = lag_k + lag'_k*p, p ∈ [0, 1] in units of k.

However the true function is very chaotic so this is just a poor extrapolation. It seems to mainly depend on stuff we can not know like multitasking stuff and such.

Some facts:

• This depends on two old values of lag with known time in between.
• It should be implemented in a second function to not break API. Normal _latency() should be called from time to time to refresh data.
• _position() is recommended.
• It is not recommended to implement own _latency() like function on top of _position() as this only leads to problems.
• _position() and _latency() use internal values not visible by API like internal buffer status.
• Explicit use of _stream() may help to improve values (for file mode).

[ph3-der-loewe]

I just implemented a function doing non-blocking latency calcing. But still this can be tuned:

• It does not calc clock drifts
• It does not yet support async updates
• A lot code is implemented twice
• The code should be re-merged by the next soname change

[ph3-der-loewe]

async updates are now supported. clock drift is currently ignored as 'to low to measure'. This is true for my devices. May not be true for all devices (with bad clock).