Support Request #16382
closed
Clock handling for timer runner and playback
Added by hidden over 2 years ago.
Updated over 1 year ago.
Requester's Priority:
Normal
Platform:
Windows 10 64bit
Description
Supportanfrage
Ich würde gerne wissen, auf welcher Zeitbasis der „Default Timer Runner“ läuft.
https://support.digitalwerk.net/adtf/v3/adtf_html/page_default_core_objects_plugin.html#section_default_timer_runner
Ist das die „Stream Time“?
Lösung
Sämtliches Timing in ADTF wird von der Reference Clock übernommen, zur Laufzeit spricht man von der Stream Time, unabhängig davon, wer sich angemeldet hat, der Taktgeber zu sein für die Reference Clock zu sein.
Siehe auch https://support.digitalwerk.net/adtf/v3/adtf_html/page_clock_concept.html
Im Playback schreitet die Zeit diskret voran. Die Timer holen allerdings "verpasste" Takte geblockt beim ersten Sample nach der nächsten Deadline nach.
Das wird sich in einer der nächsten Versionen von ADTF verbessern, in dem die Timer die Möglichkeit bekommen über die Clock dem Player (und seiner Clock) mitzuteilen wann sie denn das nächste mal geweckt werden wollen.
Zusätzlich wurde im Player noch die "reset_recording_offset" Property im Vgl. zu ADTF 2.x entfernt. Heißt die Sample Timestamps und die Streamtime (basierend auf der Chunktime) werden nie mehr manipuliert und sind exakt die Selben wie bei der Aufzeichnung.
- Project changed from Public Support to 20
- Description updated (diff)
- Status changed from New to Customer Feedback Required
- Customer set to VW
- Department set to IAV
- Topic set to ADTF::Clock
Danke für die Antwort. Also hier nochmal um mein Verständnis zu verifizieren:
Im Playback Mode wird, solange man nicht eine eigene clock registriert, die Reference Clock durch die timestamps der Samples im DAT-File erzeugt.
Solange man nicht die Interpolation im Playback Service aktiviert hat, schreitet die Reference Clock also diskret mit den Zeitstempeln aus den samples fort.
Der „Default Timer Runner“ hat damit im Playback Mode maximal die Auflösung der Zeitstempel aus dem DAT file.
Wenn ich also z.b. einen Timer Runner habe, der mit 10ms triggern soll, aber alle Daten im DAT-File nur alle 100ms aufgezeichnet wurden, wird der runner nie diese Zykluszeit erreichen.
Mir ist klar das dieses Beispiel etwas konstruiert ist, weil man ja oft viele streams in einem DAT-File hat und die Reference Clock über alle samples hinweg gebildet wird, sodass dieses Scenario meist nicht auftreten kann.
- Status changed from Customer Feedback Required to In Progress
Hi Sebastian,
ja genau, im Playback schreitet die Zeit diskret voran. Die Timer holen allerdings "verpasste" Takte geblockt beim ersten Sample nach der nächsten Deadline nach.
Das wird sich in einer der nächsten Versionen von ADTF verbessern, in dem die Timer die Möglichkeit bekommen über die Clock dem Player (und seiner Clock) mitzuteilen wann sie denn das nächste mal geweckt werden wollen.
Grüße,
Martin
- Status changed from In Progress to Customer Feedback Required
Ja genau!
Zusätzlich wurde im Player noch die "reset_recording_offset" Property entfernt. Heißt die Sample Timestamps und die Streamtime (basierend auf der Chunktime) werden nie mehr manipuliert und sind exakt die Selben wie bei der Aufzeichnung.
Grüße,
Martin
Ok. Dann vielen Dank für den super Support!
Von mir aus kann das Ticket jetzt geschlossen werden.
Grüße
Sebastian
- Status changed from Customer Feedback Required to To Be Closed
- Resolution set to Solved Issue
- Affected Products ADTF 3.13.2 added
- Platform Windows 10 64bit added
- Project changed from 20 to Public Support
- Subject changed from Frage zu timerrunner to Clock handling for timer runner and playback
- Description updated (diff)
- Private changed from Yes to No
- Status changed from To Be Closed to Closed
Also available in: Atom
PDF