C#/.NET: Soundausgabe mit DirectSound

> Dann pack den Aufruf doch einfach ins Paint-Event...
Mit welcher Begründung räumst du dem Ansatz mehr Erfolg ein? Mal 
abgesehen davon, dass das Paint-Event wahrscheinlich permanent ausgelöst 
wird, sobald man mit der Maus über's Fenster fährt oder dieses 
bewegt/minimiert, etc.

Ralf

Ralf schrieb:
> Mal
> abgesehen davon, dass das Paint-Event wahrscheinlich permanent ausgelöst
> wird, sobald man mit der Maus über's Fenster fährt oder dieses
> bewegt/minimiert, etc.
Jenau. Man will ja auch nicht die beim Hausbau errichtete Garage 
neubauen, nur weil man tapeziert. :D

Aber du sagst, wenn du den Code im Event-Handler auskommentierst, wird 
das Fenster angezeigt. Klingt eher so, als würde das Event doch 
auslösen, nur der im Handler blockierende Code verhindert den 
Fensteraufbau; also dein Direct-X-Aufruf gibt nicht zurück. Wird denn 
wirklich nichts weiter angezeigt? Output-Window? Exception, auch nach 
längerer Wartezeit (Timeout)? Nichts?

@A.Simpson:
> Jenau. Man will ja auch nicht die beim Hausbau errichtete Garage
> neubauen, nur weil man tapeziert. :D
grins Naja, ich kenne Leute, denen würd ich selbst das zutrauen, aber 
lassen wir das... ;)

> Aber du sagst, wenn du den Code im Event-Handler auskommentierst, wird
> das Fenster angezeigt. Klingt eher so, als würde das Event doch
> auslösen, nur der im Handler blockierende Code verhindert den
> Fensteraufbau; also dein Direct-X-Aufruf gibt nicht zurück.
Das komische ist halt, dass nicht mal der erste Befehl angesprungen 
wird, wenn ich dort einen Breakpoint setze.
Ich hab's auch schon über einen Button probiert. Den DirectSound-Code 
habe ich in eine eigene Funktion gepackt und im Button-ClickEvent 
aufgerufen. Beim Klicken pausiert die Form. Lässt sich nicht mal 
bewegen.
Pausiere ich den Debugger, dann steht der Ausführungsmarker beim Aufruf 
der Funktion, und nicht irgendwo im DirectSound-Code.
Kann es sein, dass man DirectX/DirectSound-Zugriffe in einem separaten 
Thread ausführen muss? Also gelöst vom GUI-Thread?

> Wird denn wirklich nichts weiter angezeigt? Output-Window? Exception, auch
> nach längerer Wartezeit (Timeout)? Nichts?
Im Output-Window war nüscht, und nach zwei Minuten gab's immer noch 
keine Exception oder sonstwas (ich weiss, dass DirectX/DirectSound nicht 
unbedingt das schnellste ist, aber sooooo lange kann's ja wohl nicht 
dauern ;)

@ Uhu Uhuhu:
>> Mit welcher Begründung räumst du dem Ansatz mehr Erfolg ein?
> Für manche Dinge ist FormLoad zu früh - ich hatte damit auch schon
> Probleme.
> FormLoad wird sehr früh nach der Erzeugung des Window-Handles gerufen.
> Wenn es sich bei dem Form um das Hauptfenster handelt, läuft der Message
> Loop noch nicht.
> Wenn man in diesem Stadium irgendwas startet, was selbst Messages
> schickt, dann werden die nicht verarbeitet und Folge ist ein Deadlock.
Danke für den Hinweis. Ich hab zwar in der Variante über das 
FormLoad-Ereignis auch schon probeweise geprüft, ob das Fenster ein 
Handle hat (wenn nicht wird es wohl automatisch bei der Abfrage 
angelegt), da eine der DirectSound-Funktionen ein Handle erwartet, aber 
dass die MessageLoop zu dem Zeitpunkt evtl. noch nicht läuft wusste ich 
nicht.

> Und was hindert dich daran, ein Flag zu setzen, daß die Sound-Kiste
> schon läuft?
Für's Ausprobieren okay, ansonsten unschön :) Aber zum Prüfen schon 
machbar, das stimmt.

> Ansonsten hängs auf einen Button, oder nimm einen Timer, der in FormLoad
> angekickt wird und mit Zeitverzug den Sound startet - nicht schön, aber
> umschifft solche Probleme.
Wie oben genannt, die Button-Variante tat's auch nicht. Man sieht noch, 
wie der Button geklickt wird, danach ist Ende, kein Bewegen des Fensters 
möglich, der Button bleibt "hinterlegt" (weil ja der Mauscursor drüber 
war), aber sonst nüscht.

> Und jetzt setz dich hin und probiers aus.
Aye, Captain ;)

Ich werd jetzt mal die Gegenprobe auf nem WinXP 32-Bit System machen. 
Vielleicht finde ich so heraus, an was es noch klemmen könnte.

Ralf

@Uhu Uhuhu:
> Hast du mal einen Breakpoint auf die Click-Eventroutine gesetzt, dann im
> Einzelschritt weiter gemacht und vor Aufruf der Sound-Geschichten die
> Parameter überprüft?
Ja, hab ich auch schon. Der Ausführungsmarker steht auf dem Aufruf der 
Funktion mit dem DirectSound-Code. Wenn ich dann einen Single-Step 
mache, passiert gar nix. Das ist vom Verhalten her wie wenn man die 
Ausführung fortsetzen würde, es wird einfach nicht weiter gesprungen. 
Ich kann das Programm dann lediglich wieder anhalten.

> Bist du sicher, daß der Sound-File gesund ist?
Das File selbst existiert, der Pfad sollte auch in Ordnung sein. 
Gegenwärtig verweise ich auf ein MP3-File. Aber selbst wenn das File 
oder der Pfad fehlerhaft wären sollte das erst beim Anlegen des 
SecondaryBuffer eine Rolle spielen.

Ich werd morgen mal ein WAV-File direkt auf C: ausprobieren, zusammen 
mit dem WinXP Test, zu dem bin ich heut leider nicht mehr gekommen.

> Das muß man eigentlich nur dann machen, wenn die Soundroutine erst dann
> zurückkehrt, wenn der File komplett abgespielt ist und während des
> Abspielens der Message-Loop nicht mehr dran kommt.
Okay. Dann ist das also auch nicht das Problem.

> Bevor du dir darüber gedanken machen mußt, sollte die Ausgabe erstmal
> prinzipiell laufen.
Ganz meine Meinung. Sieht aus als ob das schon der schwierigste Teil 
ist, wenn ich den geknackt habe sollte alles andere easy sein ;)

Ralf