Wave Soundausgabe Java 1.4.2 contra 1.5 Final

[Stefan1200]

Hi leuts,

ich hab da ein Problem ;-).
Und zwar verwende ich in meinen Spielen immer Wave Dateien für die Soundausgabe.
Nun ist mir besonders bei meinem Schiffe versenken aufgefallen, das zwar unter Java 1.4.1 und 1.4.2 alle Sound Samples abgespielt werden, aber unter Java 1.5 (oder 5) nur noch zwei Samples, die mein Kumpel neu erstellt hat.
An meinem Source kann es nicht liegen, weil wenn ich ein anderen Sample verwende, spielt auch Java 5 den Sound ab. Außerdem habe ich gestern auch noch die simple Applet AudioClip ausprobiert, die hat die gleichen Probleme.

Woran liegt das?
Supportet Sun nicht mehr alle Wave Typen?
Ich habe gestern noch versucht, die Samples umzuwandeln, klappte leider auch nicht.
Habt Ihr da auch Probleme? Ist das einfach nur ein Bug in Java 5, den vielleicht die 1.5.1 nicht mehr hat?

 

[Stefan1200]

Nachtrag:

Bei den Samples wird auch beim Versuch ein FloatControl zu instanzieren folgende Exception geworfen:

java.lang.IllegalArgumentException: Unsupported control type: Pan
at com.sun.media.sound.AbstractLine.getControl(Unknown Source)
at JBAudioPlay.playSampleFile(JBattleShips.java:3743)
at JBAudioPlay.run(JBattleShips.java:3705)

Unter Java 1.4.2 und 1.4.1 läuft es einwandfrei.

 

[Stefan1200]

Hat echt keiner eine Idee?
Könnte es noch ein Bug in Java 5 sein?
Oder doch ein Fehler in meinem Source? Obwohl, dann müsste ja AudioClip funzen.

 

[battleking]

Schon mal probiert die Exception Abzufangen und dann aber einfach weiter im Program zu machen?
Vielleicht kommen die Sounds ja dann.

(Nur ne dumme Idee :wink: )

Gruß

 

[Stefan1200]

Habe ich glaube schon versucht, werde ich aber noch mal testen.

Aber AudioClip geht ja auch nicht, oder kommt der wegen der Exception in Probleme?

 

[Mac Systems]

Mahlzeit,

In welcher Samplerate liegen denn deine Sounds vor ?

Stay Tuned
jens

 

[Stefan1200]

WAVE, PCM, 16 bit, 44100 Hz, Länge ca. eine-zwei Sekunden.
Mono und Stereo, wobei es Probleme sowohl mit Mono, als auch mit Stereo Samples gibt.

Folgende Abfrage gibt false zurück, falls ich dieses ignoriere und trotzdem weiter mache, gibt es eine Exception:

clip.isControlSupported(FloatControl.Type.PAN)

Java RE 1.5.0_01 hat dieses Problem leider immer noch, ist also noch nicht gefixt worden von Sun.

@battleking: Geht leider auch nicht, er spielt nichts ab, auch wenn ich den folgenden Source auslasse:

FloatControl gainControl = (FloatControl) clip.getControl(FloatControl.Type.MASTER_GAIN);
gainControl.setValue(gain);

 

[Stefan1200]

Ich habe das Problem genauer einkreisen können.
Und zwar schein Java seit 1.5.0 Probleme zu haben, wenn die Samples nur ca. eine Sekunde lang sind. Fragt mich nicht warum, aber wenn ich einige Sekunden stille anfüge, funzt das Sample plötzlich in Java 1.5.0. ...Nur war das nicht so gerade mein Gedanke, als ich überlegt habe, meine Spiele größer zu machen ;-).

Hat jemand eine Idee, wie ich das lösen könnte?

 

[Guest]

 clip.isControlSupported(FloatControl.Type.PAN)

Das lief bei mir auch noch nie, unter <1.4.2 hatte eich damit probleme, musste immer über den MasterGain gehen.

PS. Happy new Year

 

[Mac Systems]

Scheint ein echter Showstopper zu sein, Midi rennt auch nicht mehr verlässlich.
In 5.0 scheint der Soundkarten Buffer erst ab einer sekunde anzulaufen für PCM daten
da hilft nur ein thread der die daten in den Buffer schreibt und am ende halt nochmals
extra stille anfügt. Das könnte man ja mal testen bei verschiedenen Sampleraten,
wie 22050 HZ anstatt 44011 HZ, damit sollte ein Thread der das überwacht das doppelte an daten in den Buffer
schreiben müssen damit man was hört.

-jens

 

[Gast]

Hallo.
Wie beschrieben, ab JRE1.5 FINAL

bei java.sun.com bekannt unter den
bug ids: 6186076, 5070730, 5085008
scheinen von meiner sicht aus die selbe ursache zu haben

das macht tausende von existierenden programmen verkrüppelt bis nutzlos.
sun sollte den jre zurückziehen, bis er geht. bis sie nachbessern, werden viele bereits den defekten jre haben, und die meisten werden nicht so schnell updaten, das kenn man ja.

ich hab wochen an arbeit verloren, zumindest von meinen jre1.5 kunden...

stinksauer

euch trotzdem nette grüße
Paul

 

[Gast]

Eine Ergänzung:

Der Fehler tritt bei mir _nicht_ auf, wenn ein unkomprimiertes JAR verwendet wird, z.b. mit zip und Kompressionsstufe 0 gepackt.
So lässt sich das Problem unter Einsatz von Speicherplatz/Bandbreite umgehen.
Es scheint eine analogie zu geben: Komprimierte Bilddateien, z.b. PNG, werden u.U. ebenfalls nicht gelesen, wenn das JAR komprimiert ist.


mfg
Paul

 

[Illuvatar]

Hm... ich lese meinen Sound nicht aus einem Jar, aber wenn er < 1Sekunde ist, tut er nicht. Also... war wohl auch nix

 

[Gast]

Hallo.
Nach einem Jahr Pflege und nun harten Nachbesserungen sollte diese Soundengine recht annehmbar sein, denke ich.
Sie ist sehr simpel (nur eine Methode aufzurufen), macht polyphonie, load-on-demand und caching...

...und vor allem: lief auf meinem System JRE 1.4 - 1.5 Applet sowie Application

nehmts euch hier:
http://hirnsohle.de/test/Sounder.java
macht damit, was ihr wollt.

mfg
Paul

 

[Stefan1200]

Hmm, Java 5 scheint noch weitere Sound Probleme zuhaben:
Bug #6188860

Probleme mit 8 Bit Samples...

Nachtrag:
Das traurige an der ganzen Geschichte ist nur, das die Bugs schon seit 8 Monaten bekannt sind...

 

[Stefan1200]

So, endgültig habe ich nun herausgefunden, mit welchen Wave Dateien Java 5 nun noch klar kommt:

- Wave Dateien müssen mindestens eine Länge von 1,4 Sekunden haben.
- Wave Dateien müssen in Stereo vorliegen.
- Wave Dateien müssen 16 Bit sein, 8 Bit geht nicht.

Wenn man diese drei Regeln beachtet, klappt es auch mit Java 5.

 

[Illuvatar]

Zum ersten Punkt: Es müssen mindestens 1,0 Sekunden sein (bei mir zumindest).

 

[Illuvatar]

JUCHU Da hab ich grad ne SCHÖNE Mail gekriegt!

You are receiving this notification because the state(s) of the bug(s) that you voted on have been updated.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5070730
Old State: In progress, bug New State: Closed, fixed

 

[codeseg]

You are receiving this notification because the state(s) of the bug(s) that you voted on have been updated.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5070730
Old State: In progress, bug New State: Closed, fixed

Ok, das zentrale Dingens ist wohl "If delay is added to the testcase it works on 1.5.0." Das sieht mir nach einer Race-Condition im Laufzeitsystem aus, ist schon klar, ob es einen dauerhaften Patchgibt (Version 1.5.0_02? ;-) ) oder sind fortan alle Programme ggf. versionsabhängig um jenes ominöse Delay zu erweitern?

Tschö, cs:

 

[Gast]

bei mir gehen nichtmal sound über einer sekunde! was ist da los?

 

[Stefan1200]

bei mir gehen nichtmal sound über einer sekunde! was ist da los?

Hast du alles beachtet, was oben steht? (Stereo, 16 bit, 1.0-1.4 Sekunden länge)

 

[Gast]

ja

 

[dronus]

Ich möcht nicht unhöflich erscheinen, aber da es keine reaktion gab melde ich mich nochmal ich nochmal:

http://hirnsohle.de/test/Sounder.java

geht, zumindest auf meinen Rechnern, egal ob kuz oder lang, Applet oder Application.

 

[codeseg]

Ich möcht nicht unhöflich erscheinen, aber da es keine reaktion gab melde ich mich nochmal ich nochmal:

http://hirnsohle.de/test/Sounder.java

geht, zumindest auf meinen Rechnern, egal ob kuz oder lang, Applet oder Application.

Ich habe Deinen Code noch nicht getestet, weil ich wissen will, warum die Soße nicht geht, wenn ich ein Out-of-the-box-JRE benutze. Es ist spezifiziert, es ist dokumentiert und muß daher funktionieren. Geht es nicht, liegt trotz aller noch so schöner Workarounds Murx vor, der behoben werden muß.

Sieht außerdem nicht so aus, als ob das aktuelle Update von Sun irgendwie Verbesserungen am Sound bringt:
http://java.sun.com/j2se/1.5.0/ReleaseNotes.html#150_02

Aber - Probieren geht über Studieren - gestestet habe ich das ganz junge _02 noch nicht... :wink:

Gruß,
cs:

 

[dronus]

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5070730
taucht in der genannten fixed-Liste http://java.sun.com/j2se/1.5.0/ReleaseNotes.html#150_02
auf, und könnte ein weiteres "Synonym" des diskutierten Bugs sein.

Was im übrigen nervig, aber kein Bug ist:
der Standard-Mixer war in pre-1.5-Zeiten immer der Java-Software-Mixer, der platformunabhängig ist. Jetzt ist Standard ein nativer Server, z.B. unter Windows DirectSound. Dieser ist
1. kaputt, und produziert den bekannten Bug, (Benutzung des Soft.Mixers scheint dern Bug jedenfalls zu umgehen) und
2. unterstützt einige features nicht, z.B. führen die nützlichen mark() und reset()-Methoden zu Exceptions!
Das ist aber kein Bug: Diese Methoden, obschon durch den SW-Mixer bisher IMMER vorhanden, sind offiziell optional, und halt in Windows Direct Sound nicht vorhanden.
Solche Möglichkeiten müsste man theoretisch immer mit isXxxxxSupported() vom Mixer abfragen, was natürlich bisher einschliesslich mir kaum einer tat, da der SW-Mixer alles kann.
...
Leider gibt es keine "isCorrectPlayOfSamplesShorterThanOneSecondSupported()" Methode

Daher kann ich nur empfehlen, auf die HardwareBeschnlunigung zu verzichten (so wie es sounder.java tut) und damit platformunabhängigen funktionierenden Sound zu kriegen.
Sollte man dann irgendwann einen "ausgereiften" Hardware-Mixer vorfinden, kann man ja immernoch die Mixerauswahl modifizieren, und das Programm damit beschleunigen. Oder man schreibt den Mixer-Namen gleich in ein Config-File, wenn der Code konstant bleiben soll.

So weit, so schlecht :-/

mfg
Paul

 

[codeseg]

der Standard-Mixer war in pre-1.5-Zeiten immer der Java-Software-Mixer, der platformunabhängig ist. Jetzt ist Standard ein nativer Server, z.B. unter Windows DirectSound.

Ok... d.h. aktuell ist die Frage, ob Sound geht oder nicht eine Frage, wie gut das Gelumpse auf der jeweiligen Platform implementiert ist. Demzufolge wäre eine Aussage "Sound geht nicht" zu einer "Sound geht unter Windows nicht" geworden (sofern man nicht das hier beschriebene Verfahren, den Soft.Mixer, nutzt). Ich kann mich aktuell nicht erinnern, ob ich das ganze auch schon unter Linux getestet habe (wird nachge- oder wiederholt!), das Ergebnis ist dort ja nun nicht mehr vorhersagbar. Auch wenn das ganze mit negativem Vorzeichen behaftet ist: So richtig plattform-unabhängig ist das nicht mehr. :wink:

Oder man schreibt den Mixer-Namen gleich in ein Config-File, wenn der Code konstant bleiben soll.

Das hört sich nach der zu bevorzugenden Wahl an.

So weit, so schlecht

Aber hallo.

cs:
[/quote]

 

[stev.glasow]

Nachtrag:

Bei den Samples wird auch beim Versuch ein FloatControl zu instanzieren folgende Exception geworfen:

java.lang.IllegalArgumentException: Unsupported control type: Pan
at com.sun.media.sound.AbstractLine.getControl(Unknown Source)
at JBAudioPlay.playSampleFile(JBattleShips.java:3743)
at JBAudioPlay.run(JBattleShips.java:3705)

Unter Java 1.4.2 und 1.4.1 läuft es einwandfrei.

Das hatte ich wenn ich mir einen Controler für eine Dataline holen wollte, bei < 1.5 ging's bei >= 1.5 ging nicht (obige Exception). Nachdem ich einige Zeit gesucht hatte hab ich einfach mal das getControler(typ) nach dem Öffnen der DataLine aufgerufen (sonst war der Aufruf davor) und es ging - sprich ab der 1.5.0er muss man die Dataline erst öffnen bevor man sich irgendwelche Controler holen kann :autsch:

 

[dronus]

Oder man macht den guten alten Test wie bei DOS-Spielen

"Hören sie etwas ?"
[JA] [NEIN]

und bei NEIN Fallback zum Software-Mixer...