AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Timing problem

Ein Thema von EWeiss · begonnen am 7. Apr 2011 · letzter Beitrag vom 8. Apr 2011
Antwort Antwort
Seite 1 von 7  1 23     Letzte »    
EWeiss
(Gast)

n/a Beiträge
 
#1

Timing problem

  Alt 7. Apr 2011, 23:45
Ich verwende für mein Piano einen Loop um den Song zu spielen
Leider muss ich feststellen das dieser sehr CPU lastig ist.
Also 25% hab ich dann schon.

Delphi-Quellcode:
  // Starte den Song
  while PlayingSong do
  begin
    //Weiterlaufen bis die 16.tel Note (Pause) abgelaufen ist
    while GetTickCount < Tick + TempoWait do
      Winprocessmessages;

    Tick := GetTickCount;
    PlayNotes;
    DrawGraphics(WinHandle);
    hsi.nPos := StartX + XSizeMid;
    SetScrollInfo(WinHandle, SB_HORZ, hsi, True);
  end;
Ich verwende zwar Winprocessmessages damit andere prozesse weiterlaufen können
dadurch habe ich aber ein stocken im song ..

Delphi-Quellcode:
procedure WinProcessMessages;
var
  ProcMsg: TMsg;
begin
  while PeekMessage(ProcMsg, 0, 0, 0, PM_REMOVE) do
  begin
    if (ProcMsg.message = WM_QUIT) then
      Exit;
    TranslateMessage(ProcMsg);
    DispatchMessage(ProcMsg);
  end;
end;
Hat jemand nen Tip für mich wie ich das besser Händeln könnte ?

gruss
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#2

AW: Timing problem

  Alt 8. Apr 2011, 00:03
Was hast du dagegen, wenn die CPU das macht wofür du sie gekauft hast, nämlich rechnen? So lange der Prozess CPU Zeit abgibt, wenn sie ein anderer Prozess benötigt, ist doch alles in Ordnung. Und dein ProcessMessages hat keinen Einfluss auf andere laufende Prozesse. Du hast ja selbst die Implementierung gepostet. Guck doch mal, was da passiert. Wenn du wirklich Rechenzeit abgeben willst, dann musst du Sleep aufrufen. Damit sagst du Windows, dass du den Rest deiner Zeitscheibe nicht mehr benötigst. Der Thread wird dann schlafen gelegt und die Rechenzeit kann von einem anderen Thread in einem anderen Prozess genutzt werden.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
EWeiss
(Gast)

n/a Beiträge
 
#3

AW: Timing problem

  Alt 8. Apr 2011, 00:05
Was hast du dagegen, wenn die CPU das macht wofür du sie gekauft hast, nämlich rechnen? So lange der Prozess CPU Zeit abgibt, wenn sie ein anderer Prozess benötigt, ist doch alles in Ordnung. Und dein ProcessMessages hat keinen Einfluss auf andere laufende Prozesse. Du hast ja selbst die Implementierung gepostet. Guck doch mal, was da passiert. Wenn du wirklich Rechenzeit abgeben willst, dann musst du Sleep aufrufen. Damit sagst du Windows, dass du den Rest deiner Zeitscheibe nicht mehr benötigst. Der Thread wird dann schlafen gelegt und die Rechenzeit kann von einem anderen Thread in einem anderen Prozess genutzt werden.
Schon recht manche Dinge benötgen halt Rechenzeit und das geht auf die CPU.
Mich stört halt nur das die Anwendung bzw.. der Song dann stockt.

Meinst das kann man nicht verhindern ?

gruss
  Mit Zitat antworten Zitat
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#4

AW: Timing problem

  Alt 8. Apr 2011, 00:11
Du könntest mal die Delay-Funktion(en) aus der CodeLib probieren, wobei du erstere natürlich auf NonVCL umschreiben musst, was aber kein großes Problem sein sollte.

Ob das Timing präzise genug ist, um Musik damit abzuspielen, musst du ausprobieren.
  Mit Zitat antworten Zitat
Benutzerbild von BUG
BUG

Registriert seit: 4. Dez 2003
Ort: Cottbus
2.094 Beiträge
 
#5

AW: Timing problem

  Alt 8. Apr 2011, 00:12
Vielleicht wird es besser, wenn man anstelle einer Schleife einen Multimediatimer benutzt?
Der sollte dafür gemacht sein.
Intellekt ist das Verstehen von Wissen. Verstehen ist der wahre Pfad zu Einsicht. Einsicht ist der Schlüssel zu allem.
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#6

AW: Timing problem

  Alt 8. Apr 2011, 00:12
Windows hat ein präemtives Multitasking System implementiert. Das heißt Windows teil den Threads Rechenzeit zu und entzieht sie ihnen auch wieder. Dadurch dass die Zeitscheiben, die ein Thread zur Nutzung der CPU zustehen, kurz gehalten sind, entsteht der Eindruck, dass Threads parallel laufen. Dabei ist für jeden Thread die Zeitscheibe gleich groß. Über das Setzen der Priorität kann man jetzt beeinflussen, wie oft ein Thread eine Zeitscheibe zugeteilt bekommt. Das nur mal zum Verständnis.

Du verursachst das Stcoken selber. Mit deinem Aufruf von ProcessMessages veranlasst du den Thread dazu die Schleife zu unterbrechen und Nachrichten aus der Nachrichtenschlange mit der Nachrichtenschleife abzuholen und zu verarbeiten. Ruf ProcessMessages nur alle 10 oder 100 oder 500 Schleifendurchläufe auf.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
EWeiss
(Gast)

n/a Beiträge
 
#7

AW: Timing problem

  Alt 8. Apr 2011, 00:32
Zitat:
Du verursachst das Stcoken selber. Mit deinem Aufruf von ProcessMessages veranlasst du den Thread dazu die Schleife zu unterbrechen und Nachrichten aus der Nachrichtenschlange mit der Nachrichtenschleife abzuholen und zu verarbeiten. Ruf ProcessMessages nur alle 10 oder 100 oder 500 Schleifendurchläufe auf.
Ja ist mir klar weil halt die anderen Prozesse auch ihren Zeitraum benötigen um ihre Arbeit abzuschließen.
Es ist definitiv so wenn ich die Schleife belasse kann ich selbst mit Winprocessmessages die Anwendung nicht mehr schließen.

Selbst eine PostQuitMessage(0) schafft es nicht diesen Loop zu Unterbrechen.
Ich muss quasi das Lied erst über den Button beenden wenn ich die Anwendung schließen will.

Das war mit eines der probleme warum ich das Timing problem angesprochen habe.

Ob es mit dem Multimediatimer funktioniert müßte ich mal versuchen.
Denke aber das er letztendlich auch nicht schneller ist wie der loop selbst.

Könnte mir aber mehr zeit lassen für andere dinge anstelle von Winprocessmessages.
Wobei die Frage ist ob dieser nicht das gleiche macht um anderen Prozessen Zeit zu verschaffen.

gruss

Geändert von EWeiss ( 8. Apr 2011 um 00:34 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.063 Beiträge
 
Delphi 12 Athens
 
#8

AW: Timing problem

  Alt 8. Apr 2011, 00:37
Ein Sleep(0); gibt die Verarbeitung sofort an andere Threrads ab und beim nächsten Durchlauf wird sofort weitergearbeitet.
Wenn dein Programm wirklich für eine kurze Zeit nicht zu tun hat, kannst du damit die Rechenleistung an andere Programme weiterreichen.

Bei Multiprozessorsystemen sollte Windows dein exzesiv rechnendes Programm, bzw. deinen Thread auf einem Kern laufen lassen und nahezu alle anderen Threads auf die restlichen Kerne verteilen ... dann sollten die anderen Programme auch nicht mehr gestört werden.

Und wie schon gesagt, kannst du über die Prioritäten der anwendung und des entsprechenden Threads auch auf die CPU-auslastung Einfluß nehmen ... niedrige Priorität = mehr Zeit für Andere.

Aber egal was du machst, sobald du dein Programm irgendwie ausbremst, muß du auch damit rechnen, daß es eben ein bissl langsamer läuft und eventuell auch mal etwas stockt.

Tipp: Verschieb die Sounderzeugung in einen eigenen Thread und laß die Grafiksachen ruhig etwas langsamer rangehn (wenn die Grafik etwas/unmerklich stockt, isses ja nicht so schlimm)
und wenn es getrennt ist, dann können sich anzeige und grafik nicht mehr so leicht gegenseit sörten ... und veriß im Soundthread den "Mist" mit der Messagebehandlung.

[add]
Zitat:
Es ist definitiv so wenn ich die Schleife belasse kann ich selbst mit Winprocessmessages die Anwendung nicht mehr schließen.
Genau deswegen macht man auch rechenintensive/langwierige Dinge nicht im Hauptthread.

PS: Ein Multimediatimer ist quasi genau das Selbe wie ein TTimer (nur schneller).
Und ob ein Timer für dich die Lösung ist, mußt du selber wissen.
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PoSex im Delphi viel seltener praktiziert.

Geändert von himitsu ( 8. Apr 2011 um 00:40 Uhr)
  Mit Zitat antworten Zitat
EWeiss
(Gast)

n/a Beiträge
 
#9

AW: Timing problem

  Alt 8. Apr 2011, 00:38
Du könntest mal die Delay-Funktion(en) aus der CodeLib probieren, wobei du erstere natürlich auf NonVCL umschreiben musst, was aber kein großes Problem sein sollte.

Ob das Timing präzise genug ist, um Musik damit abzuspielen, musst du ausprobieren.
Delphi-Quellcode:
procedure Delay(msecs: Longint);
var
  targettime: Longint;
  Msg: TMsg;
begin
  targettime := GetTickCount + msecs;
  while targettime > GetTickCount do
    if PeekMessage(Msg, 0, 0, 0, PM_REMOVE) then
    begin
      if Msg.message = WM_QUIT then
      begin
        PostQuitMessage(Msg.wParam);
        Break;
      end;
      TranslateMessage(Msg);
      DispatchMessage(Msg);
    end;
end;
Macht fast genau das gleiche wie ich es eh schon verwende

gruss
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#10

AW: Timing problem

  Alt 8. Apr 2011, 00:39
Ja ist mir klar weil halt die anderen Prozesse auch ihren Zeitraum benötigen um ihre Arbeit abzuschließen.
Nein! Mit dem Aufruf von ProcessMessages gibst du anderen Prozessen KEINE Rechenzeit. Du veranlasst nur deinen eigenen Thread dazu die anstehenden Nachrichten abzuarbeiten.

Und wie unterbricht die Schaltfläche die Schleife? Dann ruf den Code doch vor dem Schließen auf.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 7  1 23     Letzte »    


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:28 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz