[SOLVED] Playing Audio from AudioBuffer in AudioNode causes JRE to die

Troubleshooting sound
1

Hey,
as the title already reveals, I am having trouble playing Sound from an AudioBuffer.

Whenever i call play on the AudioNode that has the AudioBuffer set as source, the JVM adopts with the following messsage:

A fatal error has been detected by the Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffedf48de2e, pid=6236, tid=9388

JRE version: OpenJDK Runtime Environment (11.0.6+8) (build 11.0.6+8-b520.43)

Java VM: OpenJDK 64-Bit Server VM (11.0.6+8-b520.43, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)

Problematic frame:

C [OpenAL.dll+0x4de2e]

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();
    audioBuffer.setupFormat(SoundPacket.defaultFormat.getChannels(),
            SoundPacket.defaultFormat.getSampleSizeInBits(), (int)SoundPacket.defaultFormat.getSampleRate());

    audioBuffer.updateData(readSampleFile());

    audioNode = new AudioNode(audioBuffer, new AudioKey("test"));
    audioNode.setLooping(false);
    audioNode.setPositional(false);
    audioNode.play();

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?

Thanks in Advance :slight_smile:

1 Like
2

Do not know about this issue but regarding

You might be able to use “UrlLocator” or “HttpZipLocator” and play audio through the network using the AudioNode.

And here is an example of how to use them:

3

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.

4

You can try several jre and jme combinations, it’s likely that we updated openAL at some point. You can also try jmePhonon.

Probably you are hitting a bug in OpenAL, which is hard for us to tell/fix, if it’s not fixable by an update.
But as the others point out, trying to work around it is probably the best/easiest wa

5

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 :wink:

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 :confused:

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…

BTW: how can I mark this solved?

1 Like
6

Ah so your Buffer was garbage collected before it could be played!
It would be awesome if you could report this at GitHub - jMonkeyEngine/jmonkeyengine: A complete 3D game development suite written purely in Java.
To mark your thread as solved, just edit the title and add [SOLVED] in the beginning

1 Like
7

Exactly!
I will report it, I could also implement it, if thats possible/allowed…
Aah, ok, thought about editing the title, but also that there must bes some flag/title…

2 Likes
8

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).

2 Likes
9

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…

10

Contribution is always allowed/wanted :slight_smile:
Only for complicated or big changes a discussion here is desired.

Btw: Does ByteBuffer (Java Platform SE 7 ) help? But I guess paul is more knowledged there.

1 Like
11

isDirect() is what I was going to suggest also. It didn’t exist back when this code was originally written.

But maybe he’s saying that it supports other buffers than ByteBuffer?

12

probably you’re right, all buffers passed to the method are created by com.jme3.util.BufferAllocator, but I am not sure yet… I will check, and maybe make a change request tomorrow.

There are probably other places where this could be applied also…

1 Like