Java VM: OpenJDK 64-Bit Server VM (11.0.6+8-b520.43, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
No core dump will be written. Minidumps are not enabled by default on client versions of Windows
An error report file with more information is saved as:…
When i load the sound (.wav file) directly in the sound node, everything works as expected.
(I need to use AudioBuffer, because in the end I want to be able to play Audio I already receive, decrypt and decompress via network…)
The minimal code fragment leading to the error is the following:
audioBuffer = new AudioBuffer();
audioNode = new AudioNode(audioBuffer, new AudioKey("test"));
ReadSampleFile returns a .wav file as ByteBuffer, and if i pass that directly to SoundNode i am able to hear it correctly. I tried to read the errorLog that is written, but I am not really able to comprehend much, and neither to attatch it to this thread…
Using JME3.3.0-stable and JVM11.0.6+8-b520.43
Is there anything wrong in my attempt to play the Audio, or may it be a bug in jme3/JVM, or a bad combination of jvm and ApenAl.dll?
Is it imperative that you stream audio? On the surface it sounds cool, in practice it’s probably not necessary.
It’s usually a much better idea to either download the sounds all at once, download the common sounds all at once, or download the sounds in packs. E.g. for certain areas or entities (dragon, vehicle, etc). This way you can also include a signature of some sort (maybe just a file with a random name you can compare for equality to determine if there’s a new pack available) and save on bandwidth continuously streaming the same files.
Just check if the signature exists, and if not download the pack, else play it.
Thank you for your answers, I cannot use the locators, beacuse I dont stream it from a URL, but using sockets.
The data is voice-chat, so preloading is no option either
After some digging in the WavLoader, and desperate diving in the OpenAL.dll i found the isse: For creating an AudioBuffer, a NativeBuffer (BufferUtils.createByteBuffer) instead of must be used instead of a HeapByteBuffer (simple ByteBuffer.wrap).
Of course i did no include the crucial part in my code where i allocated the buffer
I think AudioBuffer should force the use of a NativeBufffer in it’s API, to avoid that for future dev that might stumble upon this nasty error…
Note: when the audio code was written there was no easy way to check to see if a buffer was native or not.
I also don’t think it’s a GC issue… and if it is then native buffers can be GC’ed also and you could have the same problem. I think the native code simply requires native buffers and will access bad memory if given a heap buffer (that it then tries to blindly treat as native).
Ok, I neither could’t find a good way for checking the bufferType, as So many different kinds are supported… so this cannot be fixed? At least a hint in the javadoc would make a grate improvement I think…