whiteshepherd wrote:I've coded for pascal. But I have never coded java before. I can read that link and give it a try. However you said OpenMax is not working? Plus there is a bug in the current sound setup? Should I try and look for examples in JOAL? Just looking for a little direction to start?
first step, fix the game:
You may start by test run the JOAL examples and see if they playback sound for you ok.
JOAL uses the OpenAL-soft sound library that in turn passes the sound samples down to ALSA or PulseAudio. If JOAL playback ok for you then you may start look at the JOAL example source code and then change the DQ.java source to use the same logic.
- JOAL raspberry pi test example
second step, help improve hardware acceleration on the pi:
OpenAL-soft is a suitable library to improve, if we add a OpenMAX IL binding to OpenAL-soft then all applications using openal will be able to take advantage of hardware acceleration for sound playback.
final step, help debug the current java sound setup:
I belive there is some bug somewhere in the audio stack that gets exposed when running droid quest that cause the application to lock up, its hard to say if it is in the ALSA driver or inside OpenJDK itself. My feeling is that it is a multithreading issue that triggering a deadlock and the cpu keeps spinning waiting for the lock to clear. Finding the root cause may be tricky. Fixing this will help all java users to playback sound swiftly on the pi.
alternative final step to fix java sound, implement a JOAL back-end:
Java sound is modular, its configuration is loaded from the sound.properties stored inside the JRE/JDK. On the Debian/Rasbian system this configuration file is stored in /etc/java-7-openjdk/sound.properties writing a new back-end starts by providing a new class that implements the interfaces used by javax.sound.sampled.*