I don't have a computer with Windows on it here, just a netbook with Ubuntu (I'm currently on TDY and won't be back home until mid September).  Could you send me the test file?

I haven't had a problem with CodecWAV before (although most people including myself are using the .ogg format).  What kind of behavior do you get (screeching, no audio, etc)?  Could you post a link to a broken .wav file so I can run some tests to see if there is anything obvious I can fix?

For editors, I mainly use Audacity (although admittedly don't think I've ever used it to create .wav files, so it may have the same issue).  The code for CodecWAV is quite simple, so I guess I just figured it was good to go after testing it on a few .wav files I had sitting around on my computer (assumptions do tend to get me into trouble )

The initial release of SoundSystemAE will only have one codec (CodecTremolo, for .ogg files).  The reason for this is that I've redesigned the Codec and Library infrastructure in order to optimize performance on Android.  One of these optimizations was to give both the Library and Codec plug-ins a native component.  The two are linked by passing some integers through SoundSystemAE at startup.  These integers represent native function pointers.  Library and Codec reconstruct these pointers to communicate directly with each other at the native level, rather than sending buffers through the JNI to Java and then back through JNI to native (if you do any profiling on the ALAN demo I posted yesterday, you'll see how badly that affects performance).

That being said, the ICodec interface still has the "read()" and "readAll()" methods which are used by SoundSystemAE whenever a Codec doesn't have a native component.  So the PC version Codecs should be fairly easy to port over to the Android version (if you do that, though, you'd probably want to set the buffer sizes fairly high to reduce the amount of traffic moving from Java to native).

I am still working out the kinks with the Android version of my 3D Sound System.  In the mean time, I thought some folks might find this part of the library useful by itself.  This is my port of native OpenAL to Android with a simple Java interface.  It will basically allow you to add OpenAL to your projects without having to play around with c/c++ and JNI.  If optimization is a big concern for your project but you still need 3D sound, removing the overhead of SoundSystem and accessing OpenAL directly could be a good option.  This library should work on all Android versions back to 1.5 (although I've only actually tested it on my own phone).

The Java interface for this port is probably closer to JOAL rather than LWJGL's interface.  There are a few differences from JOAL, however (mainly in the methods that take array/ buffer parameters, the way the context is created and destroyed, and the lack of a direct interface to ALC with device and context objects Java-side).  That being said, code written for JOAL or LWJGL is pretty simple to make work with my interface (it's all OpenAL when you get right down to the nuts and bolts, after all).

Everything is accessed statically through the class paulscode.android.sound.ALAN.  Before creating any sources and what-not, first connect with the Android audio device and create an AL context by calling:
ALAN.create();
From there, you can access whatever AL functions you need through ALAN.  For example:
        int[] ALBufferIDs = new int[BUFFER_COUNT];
        int[] source = new int[1];
        int[] state = new int[1];
        ALAN.alGenSources( 1, source );
        ALAN.alGenBuffers( BUFFER_COUNT, ALBufferIDs );
        ALAN.alBufferData( ALBufferIDs[i], format, buffer, buffer.length, rate );
        ALAN.alSourceQueueBuffers( source[0], c, ALBufferIDs );
        ALAN.alSourceQueueBuffers( source[0], c, ALBufferIDs );
        ALAN.alSourcePlay( source[0] );
        ALAN.alGetSourcei( source[0], ALAN.AL_SOURCE_STATE, state );
        if( state[0] != ALAN.AL_PLAYING )
            whatever();

And when you're finished, destroy the AL context and disconnect from the Android audio device by calling:
ALAN.destroy();
In case you haven't caught on, ALAN isn't a personal name like some AI alias - it's just an abbreviated form of  "OpenAL for Android" (fewer keystrokes than OpenALAndroid).  On a humorous note, I was actually forced to rename a hundred or so references to my project's original title "Android OpenAL", which I was horrified to realize became "ANAL" when abbreviated.  THAT was a real pain in the butt

Anyway, here is a very basic app to demonstrate streaming an .ogg file:
ALAN Demo    (source code)

I normally drop in the source code to my projects, but you should be able to just unzip the above APK file, grab the contents of the "lib" folder, and paste them into your own project's "lib" folder.  If you prefer to compile the source code yourself, you can unzip the source code archive above and either run the following commands from the terminal/command prompt:
ndk-build
ant debug
ant installOr you can "create a new project from source" in Eclipse (requires the Android SDK and NDK to be installed, as well as the ADT plug-in and Sequoyah Android Native Code plugin from the update site plug-ins).  Once you've created the Eclipse project, just right-click on it in the left panel and navigate to "Android Tools->Add Native Support".

The above demo utilizes the Tremolo library for decoding the .ogg file.  It is a popular library for use on Android because it is extra light-weight and optimized for the ARM architecture, but there are plenty of other decoder libraries out there you could use if you have problems with that one.  In theory, you could even use any of a number of pure-Java audio decoders as well, including the ones included with my SoundSystem library.  I do not recommend copying the code from this demo - it very inefficient and meant only as a proof of concept.

One final note: OpenAL Android is licensed by the LGPL (since that is what OpenAL and Tremolo are licensed under).  While I normally shy away from this license, it actually meshes really well with Android apps, because the end user can use any of a number of free backup programs (such as ASTRO) to create a backup APK of your app.  From there, he can plug in a different version of the library into the APK, and simply reinstall it.  All you have to do is mention somewhere in your documentation where they can acquire the sourcecode for OpenAL Android (feel free to mention my website if you don't want to host the files yourself). Please let me know if you encounter any bugs (logcat output is always helpful).

does your sound system handle pitch-shifting? If not, that would be a very useful addition.

Yes it does.  Also has interface for doppler effect.

Weird, I can't find anything wrong with that second file you posted.  I have no idea why it has a screech at the end when played with CodecJOgg.  If you start having the same problem with other files, all I can suggest is to switch to CodecJOrbis or try another converter.

You're right, it does play correctly in VLC.  It is definitely a file/ codec compatibility issue then (although I don't feel too bad about my library not handling this file since 90% of other players don't seem to either).  I haven't had a chance to try CodecJorbis yet, so you might try it since it is typically compatible with a lot more files than CodecJOgg is.

-edit- glad to see you got it working.  There was another issue with the last frame of audio data in ogg files created in older versions of Audacity, and I was able to adapt CodecJOrbis to handle it, so I'll probably tinker around with that file some more to see if I can figure out what the issue is with the data right there at the beginning (probably just the first frame).  It would be nice to brag that my library can handle files that most other programs cannot

I can't reproduce the problem here.  What program are you using to convert the file?  Have you tried another program (such as Audacity)?  Please upload the actual ogg file you are having the problem with so I can see if there is something unique about that particular file's data that could be causing the weird behavior.

Which library plug-in has the problem(or do they both?)

You can get this from the Console output.  I assume you are using SoundSystemJPCT, but that doesn't tell me which library plug-in you are experiencing the problem for, because SoundSystemJPCT will either load the LWJGLOpenAL or JavaSound plug-in, depending on your OS and what components / drivers are installed.  Also, you might try using the CodecJOrbis plug-in to see if it also has the screeching behavior, since JOrbis has been around for a while and is well supported and more compatible than the JOgg codec plug-in which ships with SoundSystemJPCT.

--EDIT--
I decided to read back through this thread to figure out when it was that I experienced this screeching behavior before (3 years and 26 pages worth of history here).  I finally found it, but unfortunately, that earlier problem does not apply to your case, because it was related specifically to playing MIDI through a javascript interface I was working on at the time:

...
4) I was having problems with loud scratching sounds in some browsers the first time a sound is played.  To compensate, I had to make the javascript automatically play a silent MIDI file when it starts up.  This is completely transparent, but you are required to place the file "silence.mid" wherever the javascript is located.
...