Timing zu langsam?

[EWeiss]

Bin nen opengl lyricsplayer am schreiben..soweit funktioniert alles
Allerdings habe ich ein problem mit dem timing.

Die erste Linie funktioniert einwandfrei danach läßt die genauigkeit nach.
Ich verwende IdleLoop und aus dieser heraus spreche ich die Render Routine an.

Dort wird dann mit dieser zeile geprüft

Delphi-Quellcode:

timeBeforeNext := MidiLyrics.getLyricTime(CurrentLyric) - currentTime;
  if (timeBeforeNext <= 0) then
    begin
      inc(currentLyric);

getLyricTime gibt die nächste startposition zurück vom nächsten char das gerendert wird.
currenttime hole ich mir über

Delphi-Quellcode:

currentTime := TimeGetTime() - loadDelay - Settings.delay;

wobei settings.delay normalerweise immer 0 ist es sei denn es liegen schwankungen vor
betreffend einer ungenauigkeit des Lyrics innerhalb des MidiFiles (Konfigurierbar)

Um was es mir jetzt geht ist es möglich das IdleLoop das problem bei mir verursacht seitens des Timing?
Mich wundert es nur das die erste Linie funktioniert
Hab es auch schon mit GetTickCount versucht da ist aber Zeitlich gesehen keine große differenz

gruss

[Furtbichler]

Ich dachte immer, der normale Zeitgeber hat eine Auflösung von 18ms. Ohne absoluten Timer wirst Du die Ungenauigkeiten addieren.

[EWeiss]

Zitat:

Zitat von Furtbichler (Beitrag 1170143)

Ich dachte immer, der normale Zeitgeber hat eine Auflösung von 18ms. Ohne absoluten Timer wirst Du die Ungenauigkeiten addieren.

na ja muss mal schaun
es kann nur an der berechnung von currentTime liegen
denn die StartPosition ist immer gleich.

die ich als LongInt deklariert habe.

gruss

[himitsu]

Zitat:

The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds. The resolution of the GetTickCount function is not affected by adjustments made by the GetSystemTimeAdjustment function.

Außerdem ist Windows kein RealTime-/Echtzeitsystem ... da wird und kann es einfach nicht ganz genau sein (ohne gewisse Voraussetzungen) und man muß sollte Ungenauigkeiten einberechnen.
Auch muß man beachten daß Programme nie "durchlaufen", sondern ständig Pausen machen, während andere Threads/Programme verarbeitet werden, oder hast du genauso viele Kerne wie Threads?

[EWeiss]

Fakt ist aber das es auch bei anderen Programmen funktioniert
Kann mir nicht vorstellen das bsp. C++ schneller sein soll was GetTickCount(Delphi), Clock(C++) angeht
Und dort gibt es programme die weitaus mehr vom Timer abverlangen als mein simpler LyricPlayer.
Also irgendwo muss ich die ZEit syncronisieren können.

Meine vermutung ist das vielleicht!!! bei idleloop da was ausgebremst wird.
an GetTickCount denke ich liegt es nicht.

zumal ich es ja auch nicht verwende sondern TimeGetTime()

gruss

[himitsu]

20-50 Millisekunden Verzögerung sollte man schon einplanen.

Nja, erstmal braucht man einen festen Bezugspunkt, gegen den man rechnen sollte, damit sich nichts aufsummieren kann.

Falls man weniger als 20 Millisekunden für die Auflosung benötigt, dann benötgt man auch einen passenden Timer.
GetTickCount => If you need a higher resolution timer, use a multimedia timer or a high-resolution timer.

[EWeiss]

Zitat:

If you need a higher resolution timer, use a multimedia timer or a high-resolution timer.

you den von mmsystem versuche gerade mein glück ob ich damit von der zeit her hinkomme.
Den festen bezug habe ich ja das stellt kein problem dar.

gruss

[Aphton]

Was bitte ist "idleloop" genau?
Meinst du das OnIdle Event von Application?
(Da musste nämlich Done immer auf false setzen und das ganze ein bisschen ausbremsen..)

[EWeiss]

Zitat:

Zitat von Aphton (Beitrag 1170172)

Was bitte ist "idleloop" genau?
Meinst du das OnIdle Event von Application?
(Da musste nämlich Done immer auf false setzen und das ganze ein bisschen ausbremsen..)

Jup das meinte ich.
Und ich hab es auch auf Done false gesetzt.
Muss mal schaun ob das wirklich so dermaßen abbremst.

PS:
Bin wohl auf den falschen weg hat nichts mit dem Timing zu tun
muß da nochmal mit meinem Kumpel reden da läuft was falsch bei der übergabe der StartPosition des Textes.
OnIdle habe ich verwendet um den Timer zu ersetzen und das ist fast schon zu schnell da die Anwendung ab und zu hängt.

gruss

[EWeiss]

habe jetzt mal ein und das gleiche MidiFile geparst und stelle fest das MidiFile2 unterschiede zeigt.

Zitat:

StartTime: 53013 0 > 53014
StartTime: 53218 1 > 53219
StartTime: 53423 2 > 53425
StartTime: 53833 3 > 53836
StartTime: 54038 4 > 54041
StartTime: 54243 5 > 54247
StartTime: 54653 6 > 54658
StartTime: 54755 7 > 54760
StartTime: 56296 8 > 56301
StartTime: 56501 9 > 56507
StartTime: 56706 10 > 56712
StartTime: 56911 11 > 56918
StartTime: 57321 12 > 57329
StartTime: 57526 13 > 57534
StartTime: 57526 14 > 57534
StartTime: 59580 15 > 59589
StartTime: 59785 16 > 59795
StartTime: 59990 17 > 60000
StartTime: 60400 18 > 60411
StartTime: 60605 19 > 60616
StartTime: 60810 20 > 60822
StartTime: 61323 21 > 61336
StartTime: 62658 22 > 62671
StartTime: 63068 23 > 63082
StartTime: 63273 24 > 63288
StartTime: 63546 25 > 63562
StartTime: 63819 26 > 63836
StartTime: 64092 27 > 64110
StartTime: 64400 28 > 64418
StartTime: 64502 29 > 64521
StartTime: 64502 30 > 64521
StartTime: 66145 31 > 66164

Nur ein kleiner ausschnitt.
Die Frage wäre dann woher diese Unterschiede DateiTypen bedingt?

Die position wird berechnet..

Delphi-Quellcode:

result := round(PTempoData(FTempoList[K])^.TimePos
  + ((TickVal - PTempoData(FTempoList[K])^.TickPos) / FTicksPerQuarter) 
  * (PTempoData(FTempoList[K])^.Tempo / 1000.0));

  TTempoData = record
    TickPos: LongWord;
    TimePos: LongWord;
    Tempo: LongWord;
  end;

FTicksPerQuarter: Word;
result: LongWord;

was könnte jetzt die Differenz ausmachen?
Wie man sehen kann addiert sich die ungenauigkeit deshalb stehe ich auch nicht
auf der richtigen Cursor position im Text.

gruss

gruss