Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#97 closed enhancement (fixed)

roar_vs_latency() should have an interpolating mode

Reported by: themaister Owned by: ph3-der-loewe
Priority: medium Milestone: RoarAudio major release 0.4
Component: VS API Version: current
Keywords: Cc: themaister, ph3-der-loewe
Architecture: Compiler:
Difficulty: Kernel:
Operating System: Parent Tickets: #76
Patch attached: no Protocol:
Sound driver: Topic: New feature

Description

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.

Subtickets

Change History (4)

comment:1 Changed 9 years ago by ph3-der-loewe

  • Milestone set to RoarAudio major release 0.4
  • Topic set to New feature
  • Version set to current

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.

comment:2 Changed 9 years ago by ph3-der-loewe

  • Cc themaister ph3-der-loewe added
  • Owner changed from themaister to ph3-der-loewe
  • Status changed from new to accepted

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 PT1 system works good. Extrapolation seems to work nicely using this formular:

lagk+p = lagk + 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).

comment:3 Changed 9 years ago by ph3-der-loewe

  • Resolution set to fixed
  • Status changed from accepted to closed

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

comment:4 Changed 9 years ago by 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).

Note: See TracTickets for help on using tickets.