mark/reset not supported on getResourceAsStream

[Phil Freihofner]

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.

AudioMixerDemoApplet

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.

		AudioInputStream ais = AudioSystem.getAudioInputStream(
				AudioMixer.class.getResourceAsStream(fileName));

The message indicates a "mark/reset not supported" condition:

Here is the starting portion of the error message.

java.io.IOException: mark/reset not supported
	at java.io.InputStream.reset(Unknown Source)
	at com.sun.media.sound.SoftMidiAudioFileReader.getAudioInputStream(Unknown Source)
	at javax.sound.sampled.AudioSystem.getAudioInputStream(Unknown Source)
	at com.adonax.pfaudio.ClipTrack.<init>(ClipTrack.java:79)
	at com.adonax.pfaudio.warApplet.WarGUI.<init>(WarGUI.java:86)

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?

[Tim Moores]

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.

[Phil Freihofner]

Thank you!
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!

URL url = AudioMixer.class.getResource(fileName);
		
AudioInputStream ais = 
	AudioSystem.getAudioInputStream(url);

[Tim Moores]

Err, no, that wasn't what I meant. More like this:

URL url = new URL("http://my.server.com/my/path/my_wav_file.wav")

[Phil Freihofner]

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).

Is this correct?

[Tim Moores]

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.

[Phil Freihofner]

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.

[Tim Moores]

I had a look at the Java source code of the AudioSystem class. You can find that in a file called "src.zip" which should be somewhere in your JDK installation directory.

[Phil Freihofner]

The Java 7 user who reported the problem just let me know that the applet now works!

Thank you again, Tim, for your help. Your suggestion did the trick. Thanks also for the pointer about looking at the source for dependencies!

I'm going to let the folks who filed the bug report on this know!

Let's see, can I figure out how to mark this as solved?