[
https://issues.apache.org/jira/browse/CB-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Flavin updated CB-1599:
---------------------------
Attachment: graycol.gif
I thought I provided a detailed explanation and fix and that would be
enough. I think that creating a test case will be complicated. It will
help the system if the issue is fixed.
Bob Flavin Research Staff Member, IBM Research
From: "Joe Bowser (JIRA)" <[email protected]>
To: Robert Flavin/Watson/IBM@IBMUS
Date: 04/10/2013 01:38 PM
Subject: [jira] [Resolved] (CB-1599) successCallback not called after
stopRecording, duplicate AudioPlayer objects created
[
https://issues.apache.org/jira/browse/CB-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bowser resolved CB-1599.
----------------------------
Resolution: Later
I wish I could mark "Abandoned" on this. If you want this fixed, and can
help with it, please re-open this bug and provide a use case!
objects created
-------------------------------------------------------------------------------------
called.
'mediaObj.startRecord() are dispatched by androidExec (prompt) to new
threads on the java side and are not synchronized. Thus
org.apache.cordova.AudioHandler.execute for action='create', calls new
AudioPlayer(). Asynchronously, ...AudioHandler.execute for
action='startAudioRecording' calls AudioHandler.startAudioRecording(),
which gets a null from this.players.get(id) which causes the if statement
to call new AudioRecorder which creates a second instance of AudioRecorder
for that id.
remains in MEDIA_NONE.
it may get the instance of AudioPlayer that is in MEDIA_NONE. This
prevents AudioPlayer.stopRecording() from calling this.recorder.stop() and
this.setState(STATE.MEDIA_STOPPED) because that AudioPlayer instance is in
STATE MEDIA_NONE. Thus AudioPlayer.setState doesn't call the
handler.sendJavascript to call the javascript Media.onStatus method that
would call the statusCallback and the successCallback.
prevents 'create' and 'startRecordingAudio from running at the same time
and that 'create' should use the same code that startRecodingAudio does:
startRecordingAudio thread executes before the 'create' thread.
synchronization as well.
never called (after stopRecord)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
> successCallback not called after stopRecording, duplicate AudioPlayer objects
> created
> -------------------------------------------------------------------------------------
>
> Key: CB-1599
> URL: https://issues.apache.org/jira/browse/CB-1599
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, CordovaJS
> Affects Versions: 2.1.0, 2.2.0, 2.3.0, 2.4.0
> Environment: Android 2.3?
> Reporter: Bob Flavin
> Assignee: Joe Bowser
> Attachments: AudioHandler.java, graycol.gif
>
>
> A successCallback is not called sometimes after stopRecording() is called.
> The problem is that javascript cordova calls to 'new Media()' and
> 'mediaObj.startRecord() are dispatched by androidExec (prompt) to new threads
> on the java side and are not synchronized. Thus
> org.apache.cordova.AudioHandler.execute for action='create', calls new
> AudioPlayer(). Asynchronously, ...AudioHandler.execute for
> action='startAudioRecording' calls AudioHandler.startAudioRecording(), which
> gets a null from this.players.get(id) which causes the if statement to call
> new AudioRecorder which creates a second instance of AudioRecorder for that
> id.
> public void startRecordingAudio(String id, String file) {
> AudioPlayer audio = this.players.get(id);
> if ( audio == null) {
> audio = new AudioPlayer(this, id, file);
> this.players.put(id, audio);
> }
> audio.startRecording(file);
> }
> One instance of AudioPlayer goes into STATE MEDIA_RUNNING the other remains
> in MEDIA_NONE.
> When the javascript calls mediaObj.stopRecord() (and mediaObj.release()) it
> may get the instance of AudioPlayer that is in MEDIA_NONE. This prevents
> AudioPlayer.stopRecording() from calling this.recorder.stop() and
> this.setState(STATE.MEDIA_STOPPED) because that AudioPlayer instance is in
> STATE MEDIA_NONE. Thus AudioPlayer.setState doesn't call the
> handler.sendJavascript to call the javascript Media.onStatus method that
> would call the statusCallback and the successCallback.
> I think that the AudioHandler should have a synchronized block that prevents
> 'create' and 'startRecordingAudio from running at the same time and that
> 'create' should use the same code that startRecodingAudio does:
> AudioPlayer audio = this.players.get(id);
> if ( audio == null) {
> audio = new AudioPlayer(this, id, file);
> this.players.put(id, audio);
> }
> to prevent creating a second AudioPlayer instance if the startRecordingAudio
> thread executes before the 'create' thread.
> There may be other actions in AudioHandler.execute that need this
> synchronization as well.
> One effect of this problem is that the javascript successCallback is never
> called (after stopRecord)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
