I've been working on a simple AudioMixer. The class combines audio data from various sources into a single SourceDataLine. It works pretty well, and I posted an example as an Applet in order to get more feedback.
One of the classes I wrote to use with this AudioMixer is modelled after (to some extent) a JavaSound "Clip." With my ClipTrack, a short audio file can be loaded into memory, and played back. I put in the ability to retrigger and play back the data in an overlapping fashion, and to play the data back at different speeds. A single sound effects file (gunshot3.wav) is the source file for the ClipTrack used in my demo, and the top five buttons on the demo all make use of it.
My problem is this. One person (of several that have run the Applet with no problem) has written back to report an I/O exception when using this applet. During the start, he gets an Exception. The message points to the code line where I read in the audio data.
The message indicates a "mark/reset not supported" condition:
Here is the starting portion of the error message.
I am at a loss as to why this might not work, and as to how to trouble shoot. I can't generate the error. Only one person gets it (so far). I put a question to him as to his Java version (he might have moved up to Java 7, I'm using the latest version of 6).
Why would a method of reading in .wav files that has worked in the past suddenly stop working in some cases? Is there something different, for example, about Java 7 where InputFile's that previously were fine (in terms of mark/reset capability) are now not supporting this? Is there another way to bring in an audio file resource that is considered a best practice?
I have no specific knowledge about this problem, or audio in applets in general, but I'm not surprised that mark/reset doesn't work with resources obtained through the ClassLoader mechanism. (Actually, I'm sort of surprised it works at all, at least some of the time :-)
Assuming that the audio file is publicly accessible through HTTP, try AudioSystem.getAudioInputStream(URL) instead of the InputStream version you're using now. Looking at the javax.sound.sampled.spi.AudioFileReader javadocs (which is the class being used underneath), only the InputStream variant talks about mark/reset problems, not the URL version.
posted 8 years ago
I changed things around to the URL form.
I've posted the new Applet, and am waiting for the fellow with Java 7 to give it a try.
When I get his reply, I'll either call this "solved" or have a new question for you!
I'm still waiting for feedback from the fellow who got the error. I'm hoping the form I used avoids the mark/reset requirements, and that it works OK for him.
I was avoiding the form you mention because I'm including the sound file as a jarred resource. Are you suggesting I should rethink this approach?
If a file is included in a jar (as a "resource"), I assume it is part of the initial download of the applet into the client, and that subsequent references to the resource occur in memory.
But if I seperate out the resource file to its own url, then it is not part of the jar download (and the applet can start quicker, as it doesn't have to wait for the resource data to be downloaded). But subsequently, the reference to the resource file will require streaming (which can occur in a background thread).
Are you suggesting I should rethink this approach?
Only if you can't get it to work any other way :-) You're right about the initial vs. subsequent access, that would be a downside.
posted 8 years ago
I just took another look at the .spi documentation you linked. I was wondering how you learned that these were underlying AudioSystem. I didn't see a reference to them in AudioSystem api documentation itself. The tutorials section on the .spi explains what is going on, but it is also somewhat over my head. :-(
I'm still waiting for confirmation that the URL form will work. If there are any JAVA 7 users, it would be really great to have you try the Applet and report back! The link is in the first post.
It seems there is an official "bug report" on this question, with a reference number of 7095006 in the database.