F: DirectSound

[Chris Lux]

nur erstmal die frage ob sich hier jemand damit auskennt, denn ich habe ein tiefergehendes problem mit StreamBuffers.

[zeckensack]

Jein :D

Ich verschieb's erstmal ins Progger-Forum.

[Chris Lux]

also:

das problem erstmal beschrieben:
ich erstelle streambuffer, dh es werden wav files stückweise in einen buffer geladen, wenn dieser an bestimmten positionen abgekommen ist beim abspielen. um das updaten kümmert sich ein thread pro buffer. die funktionier wunderbar, solange es sich nur um EINEN buffer handelt, sobald ein zweiter buffer dazukommt klingt der ton abgehackt und springt hin und her.

was ich alles schon probiert habe:
um viele mögliche fehlerquelle auszuschliessen habe ich viel probiert und kam auf etwas seltsames. und zwar tritt dieses verhalten nur auf, wenn die buffer in hardware (dh von der soundkarte) gemixt werden (kann man erzwingen mit DSBCAPS_LOCSOFTWARE oder DSBCAPS_LOCHARDWARE oder durch herunterstellen der hardwareunterstützung in den audioeigenschaften). getestet habe ich es auch auf mehreren systemen mit unterschiedlichster hardware. darauf gekommen bin ich als ich es auf einer onboard soundkarte testete, die standardmässig das LOCHARDWARE nicht bringt. probiert habe ich auch die stellen, an denen ich den buffer aktualisiere zu ändern um weiter von der playposition wegzukommen. aber wie gesagt wenn man auf software runtergeht funzt alles prima. nur so klingt es eben auch dann. getestet habe ich auch ob sich die Lock und Unlock operationen der buffer in die quere kommen, dies konnte ich aber nach mehreren test auch ausschliessen. was noch ein punkt war war die irq verteilung meiner hardware, aber nach nem halben tag basteln (alles raus was nich reingehört) und rumschieben der irqs (und dazu noch testen auf VIELEN systemen) habe ich dieses hardwareproblem auch abgetan.

im dx sdk ist ja ein schönes beispiel drin, aber dort wird sich auch nur auf einen sound beschränkt. (was ja wunderbar klappt, aber mit verschiedenen buffergrössen und notifycounts auch mal in die hose ging)

microsoft kann man ja nicht anschreiben ohne msdn mitglied gehobeneren rangs zu sein und ohne gleich $245 pro stunde zu zahlen.

ich wäre über jeden tipp oder jede vergleichbare erfahrung dankbar, und bei interesse kann ich ein auf das wesentliche beschränktes test programm hier posten.

[zeckensack]

IMO könnten die Threads dein Problem sein. Timeslices haben eine recht grobe Auflösung. Hardware-Interrupts sind viel präziser.

Ich weiß jetzt nicht mehr genau wie das funktioniert (bin noch auf Stand DirectSound5 und reichlich angestaubt), aber du kannst ein Callback registrieren, daß den Puffer genau dann auffüllt wenn es nötig ist, und wirst die (IMO) für diesen Anwendungsfall überflüssigen Threads los. Das ist AFAIR eine eher schmutzige Angelegenheit, weil man dann leider wieder mit der Win32-API in Kontakt kommt (WaitForMultipleObjects oder sowas ...), dürfte aber wesentlich sauberer funzen.

[Chris Lux]

unten nochmal ;)

[Chris Lux]

schau dir den code bitte mal an, denn die threads machen nicht mehr als MsgWaitForMultipleObjects(..). vor allem das es im softwaremodus funktioniert ist das seltsame. kannst es ja testen in dem du in der createSecBuf(..) das DSBCAPS_LOCHARDWARE durch DSBCAPS_LOCSOFTWARE ersetzt oder in der systemsteuerung unter multimedia zeuch den hardwarebeschleunigungs slider auf emulation schiebst. also bei den threads sehe ich das problem nicht mehr da ich da genug rumprobiert habe.

p.s. der code ist nur ein quick-hack um mein problem aus dem gesammten system mal rauszubekommen, also bitte nicht so kritisch den code beäugen, denn der ist nur rausgerissen und zusammengeschnippelt auf das wesentliche. die wave dateien, die du dann lädst sollten hier unbedingt grösser sein als der angelegte buffer, sonst gibts probleme (nur so;)).

danke nochmal für hilfe, ich kann erst morgen wieder an arbeit hier her schaunen.

edit: schick mir bitte mal ne pm mit deiner email, für den code (is n bissi mehr ..20kb)

[zeckensack]

Originally posted by Hans Ohlo
schau dir den code bitte mal an, denn die threads machen nicht mehr als MsgWaitForMultipleObjects(..).Ich kenne mich da nicht genau genug mit Threading unter Windows aus, aber müssen die Threads nicht erst warten bis sie 'an der Reihe sind', bevor sie überhaupt Nachrichten empfangen???

Versuch es bitte mal ohne Threads :)
edit: schick mir bitte mal ne pm mit deiner email, für den code (is n bissi mehr ..20kb) Awww, bitte nicht. Ich glaube kaum daß ich der richtige dafür bin.

Aber wenn du darauf bestehst:
ashopa at gmx dot de

[Demirug]

Der absolute Direct Sound Experte bin ich nun auch nicht, aber ein bischen kenne ich mich damit schon aus. Und im Bezug auf Threads habe ich schon eine ganze Menge gemacht.

@zeckensack: Das mit der Callbackfunktion geht nicht mehr. Es wurde so geändert das ein Event gefeuert wird.

@Hans Ohlo: Warum mehrer Threads in Verbindung mit MsgWaitForMultipleObjects???

Das macht keinen Sinn den bei deinen Threads handelt es sich sicher um Workerthreads die gar keine MSG Verarbeitung haben. Da du des weiteren pro Buffer sicher nur ein Handle benutzt wäre auch die Verwendung von WaitForSingleObject sicherlich die bessere Wahl.

Ich würde die Threads mal mit ein paar Traces versehen welche ausgeben zu welchem Zeitpunkt welcher Buffer(QueryPerformanceCounter) mit welchen Daten gefüllt wird. Möglicherweise ist ein deiner Logik noch ein Fehler der dazu führt das bei einzelnen Buffer Teile übersprungen werden können.

Aber abgesehen davon habe ich diesen abgehackten Sound auch schon bei anderen Programmen bemerkt sobald man Hardware Beschleunigung nutzt ob das aber nun in Verbindung mit Streaming Buffers steht weis ich nicht.

[Chris Lux]

Also zuerst hatte ich einen Thread, nur dazu kommt das wenn MsgWaitFormMultipleObjects einen (von sagen wir 3) Events fängt und bearbeitet können in der zeit zum nächsten MsgWaitForMultipleObjects Events verloren gehen. um dies zu umgehen habe ich für jeden streambuffer einen thread, was nicht zu mehr last führt, sonder zu mehr sicherheit was die events angeht. dazu kommt das ich eben mehrere threads schon als einen lösungsansatz eingebaut habe (was sichtlich nix gebracht hat).

@demirug:
das in der logik was nicht stimmt schliesse ich echt nach 3 tagen extremstes debuggen aus (auch da es im softwaremixing modus perfekt läuft)... habe sogar am rechner gebastelt um irgendwelche konflikte zu vermeiden, dazu die halbe abteilung hier verrückt gemacht. es ist einfach nix zu wollen. vor allem kann man ja microsoft keine frage stellen, da ich auf deren support seiten nur kostenpflichtige arten gefunden habe um mit denen in kontakt zu treten (am _krassesten_ fand ich 245$ pro stunde, wenn man anruft)

naja danke trotzdem für rat ;)

p.s. das mit den verlorenen events habe ich getestet in einer testumgebung, selbst wenn man versucht diese events zu puffern gehen welche verloren, wenn sie sehr nahe aufeinander folgen

p.p.s. ich nutze MsgWaitForMultipleObjects um den Thread durch eine WM_QUIT message _sauber_ beenden zu können. viel mehr passiert ja auch nich bei MsgWai... im gegensatz zu WaitFor...

[Demirug]

Die Idee mit den Traces hatte ich nur weil ich aus leidvoller Erfahrung weis das gerade bei Dingen wo es um Timeing geht der Debugger oft nicht wirklich weiter hilft.

Software und Hardwaremixing ist nun mal leider etwas unterschiedlich.

Beim Hardwaremixing müssen die Events ja von der Hardware getriggert werden und da könnte es im Vergleich zum Softwaremixing durchaus etwas länger dauern bis das Event bei deinem Programm ankommt.

Hast du das Problem eigentlich mal mit verschiedenen Soundkarten getestet?



"p.p.s. ich nutze MsgWaitForMultipleObjects um den Thread durch eine WM_QUIT message _sauber_ beenden zu können. viel mehr passiert ja auch nich bei MsgWai... im gegensatz zu WaitFor..."

OK das Problem lösse ich immer etwas anders.

[Chris Lux]

Originally posted by Demirug Software und Hardwaremixing ist nun mal leider etwas unterschiedlich.

Beim Hardwaremixing müssen die Events ja von der Hardware getriggert werden und da könnte es im Vergleich zum Softwaremixing durchaus etwas länger dauern bis das Event bei deinem Programm ankommt.

Hast du das Problem eigentlich mal mit verschiedenen Soundkarten getestet?


jap, mit verschiedenen karten getestet, leider waren alle 3 von creative, dass ich nicht sagen kann ob es an ihnen liegt. auf das hw mixing bin ich gekommen als ich es auf verschiedenen rechnern getestet habe mit onboard soundkarten, diese konnten alle kein hw mixing und es lief wunderbar. wenn die events verzögert ankommen würden, würde das nix machen, da ich hinter dem playcursor schreibe. klingen tut es als würden sie zu früh kommen. dem entgegenzuwirken habe ich auch schon mehrere sachen probiert. aber um es wieder zu sagen es passiert nur ab mehr als einem stream und das nur in hardware. habe auch schon geschaut ob es die Lock() operationen sind (also wenn auf mehr als einen hw buffer lock gemacht wird) aber das wars auch nicht (getestet durch blockieren der threads wenn einer gerade sein notify behandelt). selbst im sw modus erzeugt mein modul kaum mehr als 20% last auf dem prozessor, das ich somit auch ausschliessen kann das zu wenig zeit für die threads übrig ist...