I didn't mean to insult your intelligence, but I can't even count how many times that question has been asked from folks using stereo files.  Is this problem happening with every file or just particular ones?  Could you post a link to one of the audio files that is having the problem?  If the sound is mono and the source position is not virtually the same as the listener position, and the attenuation model is not ATTENUATION_NONE, then there must be a bug in my code somewhere.  It will be easier to track down the cause with a file that experiences the problem (none of my files are doing this).

Make sure your file is mono, not stereo.  Stereo files should be used for ambient sources, like background music, crickets, etc, and mono files should be used for point sources.

Sorry, I totally forgot to port this to Android (I was going to after I ported my animated GIF texture project).   It will be very simple to port (just plugging in Bitmap's instead of BufferedImage's).  I'll look into this sometime next week.  Obviously the JMF video controller probably won't work on Android (not sure what alternatives to JMF are available on Android for accessing video frames)

When the file is not compiled into the JAR, you must use the loadSound method (the version that takes a URL instance & a String identifier).  This is usually called when initializing the application, or loading a scene or game level.  The identifier should look like a filename (ending in .wav for example) because that is how the library knows which codec to use.  Then calls to quickPlay will use that identifier in place of the filename parameter.  When you are done with the sample, you can call unloadSound if you want to free the memory it is using (such as when transitioning between game levels that have a different set of sound effects)

Couldn't you just create a model of the axis, load and add it to the world, and then translate it to directly in front of the camera any time the camera moves or rotates?  Getting it in front of the camera should be a matter of a couple vector subtractions and a translate.  As long as you don't rotate the Object3D, the axis should always be pointing in the correct direction, so if it's translated to in front of the camera where you can see it, it should provide the spatial context you need.

Oh, good!  I had a feeling it was related to the dumb way I coded that demo app.

Try this version of the demo.  It doesn't block the onCreate thread, so we can at least rule that out as the source of the problem.

Does the strange thing that was played sound like one or more drum beats plus sleigh bells, or clicking, or screeching (or something else)?  I know that seems like an irrelevant question, but it might help me decide where to start focusing my attention.  Each of those would indicate a separate problem:
1) If you heard one or more drum beats, it probably means the sound began playing correctly before the app crashed
2) If you hear clicking, it probably means there was a problem connecting to the audio device
3) If you hear screeching, it probably means a problem processing the audio data (endian issue, etc)

Not yet, I've been putting out a lot of brush fires with several of my projects for the past couple weeks.. I may have too many projects going at once, haha.  It is definitely in the queue 

Thanks, I haven't tested it on any other devices besides my DroidX yet, so that's not a huge surprise to me.

From the log, the problem seems to begin here:

08-29 21:47:34.519: VERBOSE/AudioHardware(115): openMixer_l() mMixerOpenCnt: 0
08-29 21:47:34.519: VERBOSE/AudioHardware(115): open playback normal
08-29 21:47:34.519: VERBOSE/AudioHardware(115): write() wakeup setting route SPK
08-29 21:47:34.562: WARN/AudioFlinger(115): write blocked for 109 msecs, 2 delayed writes, thread 0xcb58

And it then times out, with the following:
08-29 21:48:03.218: INFO/InputDispatcher(189): Application is not responding: AppWindowToken{408acb20 token=HistoryRecord{407cf6c0 paulscode.android.sound.demo/.ALAndroidDemo}}.  5002.5ms since event, 5001.1ms since wait started
08-29 21:48:03.218: INFO/WindowManager(189): Input event dispatching timed out sending to application AppWindowToken{408acb20 token=HistoryRecord{407cf6c0 paulscode.android.sound.demo/.ALAndroidDemo}}
08-29 21:48:03.265: INFO/Process(189): Sending signal. PID: 3425 SIG: 3
08-29 21:48:03.265: INFO/dalvikvm(3425): threadid=4: reacting to signal 3
08-29 21:48:03.269: INFO/dalvikvm(3425): Wrote stack traces to '/data/anr/traces.txt'

The first thing I'd like to rule out is the OS being too "smart" for its own good.  It might just be detecting that the "onCreate" thread is blocking, and shutting down the app.  Let me rewrite the demo a little less "hackish".

If that's not the problem, I'm guessing from where the problem starts that it's something related to the hardware mixer.  Is anything else playing audio at the same time you run the demo?  Try rebooting your phone and then running the demo again to see if it is still silent.

Also, which version of Android are you running on your phone?

The log also indicates that stack traces are being saved to /data/anr/traces.txt.  Could you could upload that output somewhere I could take a look at it?

LibraryJOAL, Version update

JOAL library plug-in

- Fixed JOAL package name from the old net.java.games.joal to the new com.jogamp.openal.

Sorry, I've been tracking down a problem with another one of my projects.  I'm back to working on this one again.  I'll post an update once I figure out what's causing my problem.  I'm going to start with the working decoder, and work my way back to what I have now, to try and figure out where things break.

I've been diagnosing the problem a bit.  It looks to be the exact same behavior that I was getting with decoding the compressed files, now happening when decoding uncompressed files.  To rule out any file reading as the cause, I've even read the file contents entirely with Java, and passed the encoded data to the native library to decode, but I still get the same behavior.  This is really perplexing, because the latter case is virtually identical to what I did in the ALAN demo, and it worked fine there (same file and everything).  I'll continue trying to track down what has changed.  I'd guess it is most likely a pointer or memory allocation issue.  Apparently I've gotten too dependent on Java and forgotten how to use c/c++

Unfortunately, I seem to have broken something - Tremolo is crashing after decoding ten or so blocks of data.  I have to go to work tonight, so I won't be able to fix it until tomorrow afternoon.  I apologize for the delay.

Sure, I'll post what I have so far.  Let me clean it up a bit first.. I'll upload it shortly.