hey there!
when i load a WAV soundfile on my dev-workstation, the logoutput is:
Sep 14, 2007 12:08:03 PM com.jmex.audio.util.AudioLoader loadWAV
INFO: wav loaded - time: 1.7059411 channels: 2 rate: 44100 depth: 16
and on the target platform its
Sep 14, 2007 12:08:03 PM com.jmex.audio.util.AudioLoader loadWAV
INFO: wav loaded - time: 0.050668932 channels: 2 rate: 44100 depth: 16
–> its much shorter, and you hear it that way too, so its not a logging-bug.
any solutions?
Andy
nope, the .wav files are correct when you deploy the jars, extract them and play the sound files in a player of some kind. the URLs are also correct.
new: we setup ubuntu feisty fawn on the target machine and the same problem appears. that limits the error to the machine itself (maybe a driver/openAL problem)?
setting an audio player (mplayer and vlc tested) to use ALSA or OSS: in both cases all audio files are played correctly.
we're at the end of our whits, plz help. 
thanks,
Andy
Perhaps this is an endian issue or something of that sort? If it's the same file, it must be a platform dependent loader issue. What are the dev and target platforms?
dev: ubuntu 6.06
target: debian 4.0
jme: 0.11
the files play just fine with other applications like vlc or the integrated command line audio player on debian.
thanks,
Andy
Hmm, well either you are not loading the same file you think you are… or there is some kind of software bug in the wav loader. The only thing in that loader that could be different (since everything else is printing out and looks the same) is the byte array holding the wav. Perhaps on the other platform it is not flushing the data out fully. If you are using the cvs version of jME, try updating and retesting. I'll put some more information in the output.
hey there!
thank you for your help so far renanse! 
i've tested it and the bytearrays are shorter too:
Sep 18, 2007 12:14:03 PM com.jmex.audio.util.AudioLoader loadWAV
INFO: wav loaded - time: 1.7059411 channels: 2 rate: 44100 depth: 16 bytes: 300928
and on the target platform its
Sep 18, 2007 12:50:03 PM com.jmex.audio.util.AudioLoader loadWAV
INFO: wav loaded - time: 0.050668932 channels: 2 rate: 44100 depth: 16 bytes: 8938
the wave- and bytearray-lenghts do not correlate at all.
what to do now? :?
Andy
To me that suggests you have another version of the wav somewhere. Maybe add some debugging to the code to print out the exact URL it is using?
Anything else special about that machine? CPU maybe?
What really would be great is if you could debug WavInputStream, maybe by simply printing out values of things throughout the constructor on both the working and non-working machine. We could definitely see where it is going wrong there.
well now, the constructor is full of Syserrs and the output is surprising:
public WavInputStream(URL resource) throws IOException {
super(resource, -1);
dataIn = new DataInputStream(in);
// read "RIFF"
if (dataIn.readInt() != RIFFid)
throw (new IOException("Not a valid RIFF file"));
// read chunk size
int firstByte = (0x000000FF & dataIn.readByte());
int secondByte = (0x000000FF & dataIn.readByte());
int thirdByte = (0x000000FF & dataIn.readByte());
int fourthByte = (0x000000FF & dataIn.readByte());
System.err.println("firstByte: " + firstByte);
System.err.println("secondByte: " + secondByte);
System.err.println("thirdByte: " + thirdByte);
System.err.println("fourthByte: " + fourthByte);
fileSize = 8L + (firstByte << 0 | secondByte << 8 | thirdByte << 16 | fourthByte << 24) & 0xFFFFFFFFL;
System.err.println("fileSize: " + fileSize);
// read "WAVE"
if (dataIn.readInt() != WAVEid)
throw (new IOException("Not a valid WAVE file"));
headerSize += 12;
System.err.println("headerSize: " + headerSize);
// find the beg of the next audio chunk. This'll get the chunk with
// format info.
seekAudio();
setLength((fileSize - headerSize) * 8f / (getChannelCount() * getBitRate() * getDepth()));
System.err.println("Length set: " + (fileSize - headerSize) * 8f / (getChannelCount() * getBitRate() * getDepth()));
}
WORKS:
firstByte: 240
secondByte: 25
thirdByte: 41
fourthByte: 0
fileSize: 2693624
headerSize: 12
Length set: 15.269728
Sep 20, 2007 9:34:18 AM com.jmex.audio.util.AudioLoader loadWAV
INFO: wav loaded - time: 15.269728 channels: 2 rate: 44100 depth: 16 bytes: 2693580
DOESNT WORK:
firstByte: 240
secondByte: 25
thirdByte: 41
fourthByte: 0
fileSize: 2693624
headerSize: 12
Length set: 15.269728
Sep 20, 2007 9:34:18 AM com.jmex.audio.util.AudioLoader loadWAV
INFO: wav loaded - time: 0.45873016 channels: 2 rate: 44100 depth: 16 bytes: 8092
that means it loads correctly but afterwars something is messed up, right?
:| Andy
well then, turns out its not the target computer thats to blame. its the deployed version itself. the error occurs no matter where you run the application from the deployed version. start it out of eclipse and it works just fine.
ideas?
thanks,
Andy
hmm… What do those sysouts show when you run from webstart?
hey there!
I FOUND WHERE IT GOES WRONG! … but i still have no idea why 
I have manipulated AudioLoader.loadWAV() like that:
private static void loadWAV(AudioBuffer buffer, URL file) throws IOException {
ByteArrayOutputStream byteOut = new ByteArrayOutputStream(1024 * 256);
byteOut.reset();
byte copyBuffer[] = new byte[1024 * 4];
WavInputStream wavInput = new WavInputStream(file);
System.err.println("wavInput.getBitRate(): " + wavInput.getBitRate());
System.err.println("wavInput.getChannelCount(): " + wavInput.getChannelCount());
System.err.println("wavInput.getDepth(): " + wavInput.getDepth());
System.err.println("wavInput.getLength(): " + wavInput.getLength());
boolean done = false;
int bytesRead = -1;
int i = 0;
while (!done) {
i++;
bytesRead = wavInput.read(copyBuffer, 0, copyBuffer.length);
System.err.println("read " + bytesRead + " bytes");
byteOut.write(copyBuffer, 0, bytesRead);
done = (bytesRead != copyBuffer.length || bytesRead < 0);
if(bytesRead != copyBuffer.length) {
System.err.println("bytesRead != copyBuffer.length");
}
if(bytesRead < 0) {
System.err.println("bytesRead < 0");
}
}
wavInput.close();
System.err.println("" + i + " iterations");
int bytes = byteOut.size();
System.err.println("byteOut.size(): " + byteOut.size());
ByteBuffer data = BufferUtils.createByteBuffer(bytes);
data.put(byteOut.toByteArray());
byteOut.close();
data.rewind();
if (ByteOrder.nativeOrder() == ByteOrder.BIG_ENDIAN) {
System.err.println("native order is big endian");
ShortBuffer tmp2 = data.duplicate().order(ByteOrder.LITTLE_ENDIAN).asShortBuffer();
while (tmp2.hasRemaining())
data.putShort(tmp2.get());
data.rewind();
}
int channels = wavInput.getChannelCount();
int bitRate = wavInput.getBitRate();
int depth = wavInput.getDepth();
float time = bytes / (bitRate * channels * depth * .125f);
buffer.setup(data, channels, bitRate, time, depth);
logger.info("wav loaded - time: " + time + " channels: " + channels + " rate: " + bitRate + " depth: " + depth
+ " bytes: " + bytes);
// cleanup
data.clear();
data = null;
wavInput.close();
}
Starting it out of Eclipse:
wavInput.getBitRate(): 44100
wavInput.getChannelCount(): 2
wavInput.getDepth(): 16
wavInput.getLength(): 15.269728
read 4096 bytes
read 4096 bytes
...
read 4096 bytes
read 4096 bytes
read 2508 bytes
bytesRead != copyBuffer.length
658 iterations
byteOut.size(): 2693580
Sep 21, 2007 12:18:10 PM com.jmex.audio.util.AudioLoader loadWAV
INFO: wav loaded - time: 15.269728 channels: 2 rate: 44100 depth: 16 bytes: 2693580
Starting it out of the .jar
wavInput.getBitRate(): 44100
wavInput.getChannelCount(): 2
wavInput.getDepth(): 16
wavInput.getLength(): 15.269728
read 4096 bytes
read 3996 bytes
bytesRead != copyBuffer.length
2 iterations ///////////////// <<<<<<<<<<<<=============
byteOut.size(): 8092
Sep 21, 2007 12:16:41 PM com.jmex.audio.util.AudioLoader loadWAV
INFO: wav loaded - time: 0.045873016 channels: 2 rate: 44100 depth: 16 bytes: 8092
in the second iteration, it reads 100 bytes less than the copybuffers length, which causes the whole copy-operation to cancel.
y is that?
thanks,
andy
done = (bytesRead != copyBuffer.length || bytesRead < 0);
That's not the correct condition for terminating the read loop! It is allowed for InputStream.read to read only some bytes. There is no guarantee that the whole buffer is filled even if the stream contains more bytes. (see JavaDoc of InputStream.read)
The condition has to be changed to bytesRead < 0.
exactly, works 
i guess the reason is that reading from the .jar file is a bit slower and so the buffer doesnt get full.
will someone commit it to cvs? also: closing opened streams would be 'beautiful'
thanks,
Andy
fine
fixed in cvs
Cool, thanks irrisor