Crashes beim Abspielen von Sounds unter Win98

[0xdeadbeef]

Ist diesbezüglich etwas bekannt??? Zwei meiner "Beta-Tester" (so 'ne Art) berichten davon, daß ihr Rechner sporadisch einfriert, wenn von meinem Spiel Sound abgespielt wird. Beide haben Win98. Tritt offensichtlich auf, wenn sehr viele kurze Sounds in kurzer Zeit abgespielt werden sollen. Unter XP gibt es keinerlei Probleme, muß also ein Problem der JRE unter 98 sein...
Ideen?

 

[sebastian4gold]

Hallo!
Ich habe eine Raumklang Demo geschrieben, die ungefähr 200 Objekte darstellt, von dem jedes das selbe Lied abspielt (eine 6MB Datei) und sich bewegt.
Außerdem habe ich eine Hall-Engine eingebaut.

So. Ich habe auch Win 98 (SE). Mit SAGENHAFTEN 128 MB Ram.
Beim Testen habe ich auch immer Eclipse im Hintergrund laufen.
Nichts ist eingefrohren.
Ich glaube es liegt nicht am Sound.

So jetzt du.

Gruß
Sebastian

______________________________________________________________
Wenn du willst, kann ich dir das Prog schicken, du testest es bei deinen "Testern" und dann kannst du ja sehen ob es am Sound liegt, oder am Spiel.
Vielleich solltest du auch in betracht ziehen, mit welcher Java Version sie die Demo testen.

 

[0xdeadbeef]

Na ja, ich spiele sehr viele sehr kurze Sounds ab (u.U. 'zig pro Sekunde) und bekanntlich hatten ja diverse JREs der letzten Zeit (alle 1.4er und die ersten 4 1.5er) auch unter XP Probleme mit kurzen Sounds.
Ich spiele nebenbei bemerkt auch Musik (MOD) ab, die funktioniert aber anders (eine Line statt dauernd neuer Clips) und scheint keine Probleme zu machen.
Daß also gewisse Soundanwendungen keine Probleme machen, sagt absolut nichts darüber aus, ob es unter Win98 (bekannte) Probleme mit JavaSound gibt.
Es gibt davon abgesehen unzählige Einträge zum Thema "Freezes unter Win98 mit Bezug auf Sound" in der Sun Bug Database. Allerdings ist das durchsuchen hunderter Einträge etwas mühselig, zumal die meisten als "nicht reproduzierbar" geschlossen wurden - was aber ja auch nichts heißt.

 

[sebastian4gold]

Wie wäre es dann damit:

Probier doch einfach eimal lange (so 30 sik) Musik aus. Ist ja erst einmal egal, ob das dann im Spiel sich (auf "gut" Deutsch) scheiße anhört. Wenn´s dann arbeitet, dann kannst du 100%ig sagen es liegt daran und dann kannst du auch nichts machen.
Wenn allerdings bei langen Songs die Rechner sich auf aufhängen, dann ließe sich durchaus etwas machen.
Probier das mit den langen Songs aus, dann berichte uns. (sofern du nicht pech hast, und man nichts machen kann.)

Alternativ Vorschlag. Wenn es mit Java nicht geht, kannst du ja eine JNI basierende Sound Lib bei Sourceforge suchen, die du einbindest. Dann wäre das Prob auch gelöst.

Gruß
Seba

 

[0xdeadbeef]

Naja, meine Lösung wäre im Augenblick: Sound ausschalten oder kein 8 Jahre altes Betriebssystem benutzen.

Aber um es nochmal klar zu machen: ich suche (noch) nicht nach Lösungen, sondern primär erstmal nach Erfahrungen zum Thema.

 

[warnimal]

guten morgen oxdeadbeef...

wir testen auf allen mögliche hardwarekonfigurationen (man glaubt net was für kisten in diversen büros von kunden stehen :autsch: )... unter anderem auch auf rechnern die <800Mhz und < 256 MB RAM und Win98SE installiert haben

dabei hat sich gezeigt dass solche saurier speziell sie wenn alte creativ-labs-ähnliche(!???)-soundkarten installiert haben bei applets die unter JSE1.3 oder älter sind:

1.sound entweder gar net spielen
2.das applet einfriert
3.oder der loadingprozess endlos dauert...bis hin zum einfrieren des Browsers...

was mich noch interessieren würde: was für ein soundformat verwendest denn?
bzw...wie ists denn gesampelt?

wir haben einen grossteil solcher probleme damit abgestellt dass wir nur mehr sounds abspielen die im *.au format mit 8bit 8kHz mono erstellt worden sind...


war, ohne einhalt...

 

[0xdeadbeef]

Meine Soundfiles sind alle sehr kleine (und kurze) 8bit-Mono-WAV-Files mit Samplingraten <= 8kHz, die ich als Clip abspiele.
Einzige Ausnahme bildet ein 8bit -44kHz-Monosound, den ich quasi synthetisiere (einfaches Pitchshifting). Auch der wird aber als Clip abgespielt. Das entsprechende AudioFormat ist wie folgt definiert:
pitchFormat = new AudioFormat( 44100, 8, 1, false, false);

Parallel läuft eine Musikausgabe mit einer Stereo-Line und 44kHz Samplingfrequenz. Die scheint - soweit man das sagen kann - unproblematisch zu sein.

Nach den wenig hilfreichen Kommentaren meiner freiwilligen Tester schließe ich, daß die Sounds alle geladen und abgespielt werden, daß es aber speziell bei wiederholtem Abspielen des synthetisierten Sounds zu spontanen Freezes (des gesamten System) kommt.

 

[warnimal]

hm...

kommts gleich bei der ersten wiederholung des abspielvorgangs dazu?
irgendwie hört sich das an als würden die files immer wieder neu in den arbeitsspeicher gelegt werden der dann natürlich irgendwann einmal überlastet ist...

magst net den gesamten code (was audio betrifft) posten damit wir es einmal durchschauen können?

war, schönes we wünschend...

 

[0xdeadbeef]

kommts gleich bei der ersten wiederholung des abspielvorgangs dazu?

Wohl nicht.

irgendwie hört sich das an als würden die files immer wieder neu in den arbeitsspeicher gelegt werden der dann natürlich irgendwann einmal überlastet ist...

Nein, die Files werden nur einmal geladen. Auf meiner Seite wird pro Abspielvorgang keinerlei Speicher angelegt.
Die einzige implizite Allokierung ist das "getLine" mit dem ich mir eine Line vom Mixer hole.

magst net den gesamten code (was audio betrifft) posten damit wir es einmal durchschauen können?

Ich hatte meine Soundklasse schon mal hier gepostet, auch da hat sich am Ende herausgestellt, daß es ein Fehler in der JVM war (kurze Sounds wurden vor der 1.5_05 unter Windows nicht korrekt abgespielt). Ich kann das gerne nochmal machen, aber das Ergebnis wird das gleiche sein.

 

[0xdeadbeef]

Nebenbei ist mir aufgefallen, daß ein per Clip gespielter Sound anscheinend Windows-Speicher belegt, der nicht mehr freigegeben wird (falls man dem Task-Manager glauben mag), obwohl der Heap nicht wächst.
Siehe auch:
http://www.java-forum.org/de/viewtopic.php?t=28584

Ob das ein Memory-Leak der JVM oder exzessives Caching ist, sei mal dahingestellt.

Als workaround sehe ich nur, "richtige" DataLines zu benutzen anstelle von Clips, weil ich über die die Kontrolle behalte. Das würde das gesamte Soundsystem aber extrem verkomplizieren. Außerdem tritt der gleiche Effekt (nicht mehr freigegebenes Windows-RAM, obwohl der Heap stagniert) auch mit BufferedImages auf.

 

[0xdeadbeef]

Ah, ok, habe zumindest für das Freigeben von Windows-Ressourcen eine Lösung gefunden.
Obwohl ich bisher eigentlich davon ausgegangen bin, daß man einen Clip nicht mehr explizit schließen muß, ist das anscheinend doch nötig.

Habe mir also einen LineListener geschrieben:

class ClipListener implements LineListener {
	public void update(LineEvent event) {
		LineEvent.Type type = event.getType();
		if (type == LineEvent.Type.STOP) {
			Clip c = (Clip)event.getLine();
			c.flush();
			c.close();
		}
	}
}

Und starte die Line wie folgt:

Clip c = (Clip)mixers[mixerIdx].getLine(info[num]);
c.open(format[num],soundBuffer[num],0,soundBuffer[num].length);
c.addLineListener(clipListener);
c.start();

Vielleicht behebt das ja auch die Probleme unter Win98?

 

[byte]

Außerdem tritt der gleiche Effekt (nicht mehr freigegebenes Windows-RAM, obwohl der Heap stagniert) auch mit BufferedImages auf.

Interessant! Das erklärt ein Problem, was ich kürzlich hatte. Ich musste sehr viele Bilder zusammenfügen. Also immer etwa 50-500 Bilder (schmale Streifen) einlesen, zu einem Bild zusammenfügen und wieder abspeichern. Ich habe extra darauf geachtet, dass immer nur soviele Objekte im Speicher liegen, wie auch tatsächlich benötigt werden. Und trotzdem kommt es zu einer OutOfMemoryException, wenn man das ganze über ein Verzeichnis mit sehr vielen Bildern (10.000+) ausführen möchte. Obwohl trotzdem immer nur 50-500 Bilder gleichzeitig eingelesen und zusammengefügt werden, ist irgendwann Schicht im Schacht.

Gibts da was Offizielles zu dem Thema? Also ist es als Bug bekannt?

PS: Das hilft Dir jetzt bei Deinem Problem natürlich nicht weiter. Da kann ich Dir auch leider nicht weiterhelfen. :roll:

 

[0xdeadbeef]

Das mit den BufferedImages ziehe ich teilweise wieder zurück. War vermutlich eine Fehlinterpretation.

Für Deinen Fall: hast Du schon mal versucht, für nicht mehr explizit benutzte Bilder die eventuell im Cache befindlichen Informationen per flush() zu löschen?