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.

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)

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

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)

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?

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.

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.