Failed to load file 'combobreak.wav'.

[rodrigezBCL]

Version: 0.9.0
Build date: 2015-05-17 19:41
OS: Linux (i386)
JRE: 1.7.0_79
Error: Failed to load file 'combobreak.wav'.
Stack trace:

java.lang.IllegalArgumentException: Invalid format
    at org.classpath.icedtea.pulseaudio.PulseAudioDataLine.createStream(PulseAudioDataLine.java:142)
    at org.classpath.icedtea.pulseaudio.PulseAudioDataLine.open(PulseAudioDataLine.java:99)
    at org.classpath.icedtea.pulseaudio.PulseAudioDataLine.open(PulseAudioDataLine.java:283)
    at org.classpath.icedtea.pulseaudio.PulseAudioClip.open(PulseAudioClip.java:402)
    at itdelatrisu.opsu.audio.MultiClip.getClip(MultiClip.java:164)
    at itdelatrisu.opsu.audio.MultiClip.<init>(MultiClip.java:94)
    at itdelatrisu.opsu.audio.SoundController.loadClip(SoundController.java:117)
    at itdelatrisu.opsu.audio.SoundController.loadClip(SoundController.java:90)
    at itdelatrisu.opsu.audio.SoundController.init(SoundController.java:207)
    at itdelatrisu.opsu.states.Splash$1.run(Splash.java:109)

[itdelatrisu]

Can you upload or link to the files that are causing the errors?

[rodrigezBCL]

I just put the setting "Disable all sound effects" to No and a get all .wav effects failed to load. Putting on Yes it don't happen maybe it's my Linux sound driver

[Bigpet]

That sound file is a 8-bit 11025Hz mono wav file and it seems like icedtea just uses pulseaudio directly to do the audio output and the pulse documentation says that it should support 8-bit PCM and sample rates anywhere from 1Hz to 192000Hz.

I tried to run it with icedtea on my Ubuntu lappy and I actually get a different exception (line unavailable).

I do wonder though @itdelatrisu , should we maybe just convert all sound samples to 44100Hz 16-bit stereo PCM? Having them all be different seems kind of weird and the re-sampled sounds would only be around 2-3 times the size they currently are.

[Bigpet]

Never mind it doesn't actually seem to be a format issue. Somehow OpenJDK has an issue with the Audio System classes.

Seems like using OracleJRE will be a temporary solution. I'm going to see if I can't find some more info on the OpenJDK issue.

edit: Eh, I'm going to give up searching for a solution to get this to run on OpenJDK for now since the GStreamer thing may circumvent this issue anyway later and this problem seems to be have been plaguing other project for more than 3 years now. But please do report if it still doesn't work with OracleJRE.

[Bigpet]

Work around without installing OracleJRE:

edit /etc/java-openjdk-7/sound.properties (you probably need super user priviledges to change that file)
from this:

javax.sound.sampled.Clip=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
javax.sound.sampled.Port=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
javax.sound.sampled.SourceDataLine=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
javax.sound.sampled.TargetDataLine=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider

#javax.sound.sampled.Clip=com.sun.media.sound.DirectAudioDeviceProvider
#javax.sound.sampled.Port=com.sun.media.sound.PortMixerProvider
#javax.sound.sampled.SourceDataLine=com.sun.media.sound.DirectAudioDeviceProvider
#javax.sound.sampled.TargetDataLine=com.sun.media.sound.DirectAudioDeviceProvider

to this:

#javax.sound.sampled.Clip=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
#javax.sound.sampled.Port=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
#javax.sound.sampled.SourceDataLine=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
#javax.sound.sampled.TargetDataLine=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider

javax.sound.sampled.Clip=com.sun.media.sound.DirectAudioDeviceProvider
javax.sound.sampled.Port=com.sun.media.sound.PortMixerProvider
javax.sound.sampled.SourceDataLine=com.sun.media.sound.DirectAudioDeviceProvider
javax.sound.sampled.TargetDataLine=com.sun.media.sound.DirectAudioDeviceProvider

But it should be noted that there was a reason why the default backend was replaced with pulseaudio. The latency and consistency in the latency is beyond terrible this way (for me at least).

[itdelatrisu]

@Bigpet: Thanks for looking into the issue. Any suggestions on how I should handle this, then? x.x

[Bigpet]

Well the primary issue is that that SoundController and Multiclip go off the logical assumption that if an AudioFormat is declared as supported that you would be able to open a Clip with such a format if you got it with AudioSystem.getClip().

However the documentation for that API does not actually guarantee that if Clip could possibly support that format that a Clip obtained from AudioSystem.getClip has to support it.

So the options as I see them are:

• refer to this workaround and wait for some better sound system to be used
• re-implement the functionality of Clip that you need and just use Lines to output Audio (might still not solve the issue since it could still result in the "line unvailable" exceptions)
• search the SoundSystem mixers and skip the ones that have "pulse" in their name (leads to the same terribly unpredictable lag in soundeffects as the workaround)

But I might also be missing something here.