Recording from Pull stream? ClassCastException thrown.

Question

I have a custom pullbufferstream and datasource that I wrote. It works quite well when just listening to the audio. Now I'm trying to set it up so that I can record and listen at the same time. So like, with a push buffer stream, I created a cloneable version of the DataSource using the Manager functions, created a clone of it, created a processor using the clone, then attempted to put the processor in the "configure" state so I could set some options before recording. At the configure() call, I get the following:
java.lang.ClassCastException
at com.ibm.media.protocol.CloneableSourceStreamAdapter$PushBufferStreamSlave.getFormat(CloneableSourceStreamAdapter.java:330)
at com.sun.media.parser.RawBufferParser$FrameTrack.<init>(RawBufferParser.java:197)
at com.sun.media.parser.RawBufferParser.open(RawBufferParser.java:84)
at com.sun.media.BasicSourceModule.doRealize(BasicSourceModule.java:172)
at com.sun.media.PlaybackEngine.doConfigure1(PlaybackEngine.java:229)
at com.sun.media.ProcessEngine.doConfigure(ProcessEngine.java:43)
at com.sun.media.ConfigureWorkThread.process(BasicController.java:1370)
at com.sun.media.StateTransitionWorkThread.run(BasicController.java:1339
The first thing I noticed is that it's trying to do stuff using a PushBufferStream, when the original DataSource and Stream are both pull versions. The code that causes this looks like:
DataSource cloneDS = ((SourceCloneable)dataSource).createClone();
recordProcessor = Manager.createProcessor(cloneDS);
recordProcessor.configure();
Pretty simple. Anyone have any ideas?

Answer 1

I've been digging through the JMF code trying to find this, and doing a lot of searching into why this happens. First thing I noticed in searching is that a LOT of people have a problem where a processor might not come out of the configure() call. I'm willing to bet that most of these people are having the same problem, but just aren't catching the exception to see it. Too bad none of these posts have any solution or suggestions on how to get around it.
So now onto the tracing I've been doing. Sure enough, JMF tries to typecast a PullBufferStream into a PushBufferStream in CloneableSourceStreamAdapter. The strange thing is that it does the exact same typecast a couple calls earlier (RawBufferParser:94), but since it's already been casted and stored as a SourceStream it doesn't complain (or so it seems). It looks like it all goes back to the actual clone call. The cloning uses something called com.ibm.media.protocol.CloneablePullBufferDataSource, which is a subclass of SuperCloneableDataSource. For some reason, this seems to think that it's ok to use a PushBufferStreamAdapter in place of the PullBufferStream that it's getting data from. A long chain of calls ensues, and we end up in the getFormat call. The type source stream it tries to use is none other than my custom PullBufferStream type, and then it tries to type cast that to a PushBuffer one. This all makes no sense to me why they can't just use a Parser/Processor that uses PullBuffers.
A list of things I've tried just to rule some out:
1. Creating a realized processor instead of a regular one. Results are the same.
2. Creating the datasink I'm trying to get to directly instead of through a processor. Results are the same.
3. Lots and lots of print statements inside of the JMF code just to figure out what's going on.