I'm trying to stream audio from the phone's mike over GPRS in Java, for a Series 60 phone (6600). I have seen that nothing gets output from the audio capture unless commit() is called on the RecordControl.
So as a workaround, I am trying to set up a double-buffering scheme: I record a small chunk of sound (e.g. 1 s), commit it, and send it over to the network while the next chunk of sound is being recorded.
To avoid a gap in recording, I need to know with finer grain what exactly are the dynamics of some MMAPI calls and whether certain calls are blocking.
* Does ((RecordControl)rc).commit() wait until the entire recording has been write()'d to the OutputStream, or does it return as soon as the recording has been scheduled to be written? I am afraid that if I wait for commit() to be completed, then I will have a lapse before the next recording.
* Can I have two Players on "capture://audio" with one in the recording state while the other one is stopped with its RecordControl doing a commit()?
* If so, can I start one Player pA on "capture://audio" and then another one pB also on "capture://audio" *before* pA is stopped, so that pB would pick up the recording right when the resource is made available i.e. when pA enters the stopped state?
I'd basically like to know if I can do
Player pA = Manager.createPlayer("capture://audio");
Player pB = Manager.createPlayer("capture://audio");
pA. realize(); pB.realize();
RecordControl rcA = (RecordControl)pA.getControl("RecordControl");
RecordControl rcB = (RecordControl)pB.getControl("RecordControl");
pB.start(); // starting to record on player pB before pA is stopped
pA.start(); // starting to record on player pA before pB is stopped
I would also like to know if there are some recording formats available which don't have header information (raw recordings) since repeating the headers for each second of sound would add quite a bit of overhead.