![]() |
Timing problem
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:
Ich verwende zwar Winprocessmessages damit andere prozesse weiterlaufen können
// 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; dadurch habe ich aber ein stocken im song ..
Delphi-Quellcode:
Hat jemand nen Tip für mich wie ich das besser Händeln könnte ?
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; gruss |
AW: Timing problem
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.
|
AW: Timing problem
Zitat:
Mich stört halt nur das die Anwendung bzw.. der Song dann stockt. Meinst das kann man nicht verhindern ? gruss |
AW: Timing problem
Du könntest mal die
![]() Ob das Timing präzise genug ist, um Musik damit abzuspielen, musst du ausprobieren. |
AW: Timing problem
Vielleicht wird es besser, wenn man anstelle einer Schleife einen
![]() Der sollte dafür gemacht sein. |
AW: Timing problem
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. |
AW: Timing problem
Zitat:
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 |
AW: Timing problem
Ein
Delphi-Quellcode:
gibt die Verarbeitung sofort an andere Threrads ab und beim nächsten Durchlauf wird sofort weitergearbeitet.
Sleep(0);
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:
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. |
AW: Timing problem
Zitat:
Delphi-Quellcode:
Macht fast genau das gleiche wie ich es eh schon verwende ;)
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; gruss |
AW: Timing problem
Zitat:
Und wie unterbricht die Schaltfläche die Schleife? Dann ruf den Code doch vor dem Schließen auf. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:31 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz