Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve audio recording configuration #2752

Merged
merged 14 commits into from May 7, 2024

Conversation

avazirna
Copy link
Contributor

@avazirna avazirna commented Apr 26, 2024

Summary

This PR was motivated by an issue with the Audio Recording feature in which the resulting recording had no sound. The issue was replicated by recording audio with CommCare and another voice recorder app at the same time, it was noticed that navigating away from CommCare would cause the recording to go silent. A few options were entertained as potential solutions, but ultimately taking advantage of some recording configuration elements introduced in the latest versions of Android, proved to be sufficient to ensure that CommCare audio recording feature is handled with higher priority by the system.
While it was possible to replicate the issue, it's important to note that the actual conditions in which the issue occurred could not be established as access to the list of apps in the affected devices were not possible.

The actual replication steps are:

  1. Install a voice recording app, such as this, or make sure there is one installed in the device
  2. Using CommCare 2.53.1 or below, initiate an audio recording
  3. Navigate away to the app installed in number 1 and start recording there too
  4. Go back to CommCare, stop the recording and save
  5. Play the recording in CommCare and confirm whether during the period away from CommCare, the recording didn't capture any sound.

Ticket: https://dimagi.atlassian.net/browse/SAAS-15417

Product Description

There are a couple change visible to the user:

  • CommCare now checks if there is an ongoing recording before initiating a new one, and informs the user with the necessary message when that's the case:
  • During the recording, the user is advised not to leave CommCare:
  • From Android 10, if during a recording, users initiate a new recording in a different app, causing the recording in CommCare to stop capturing sound, CommCare will post a notification and pause the recording. Tapping on this notification, will take the user back to CommCare and resume the recording.

Safety Assurance

  • I have confidence that this PR will not introduce a regression for the reasons below
  • Do we need to enhance manual QA test coverage ? If yes, "QA Note" label is set correctly

Safety story

These changes were successfully tested on Android 9, 10, 11 and 12.

QA Note: Test for bug fix and add a test in QA plan to test for simultaneous recordings.

@avazirna avazirna marked this pull request as ready for review April 26, 2024 10:38
@shubham1g5 shubham1g5 added this to the 2.54 milestone Apr 29, 2024
Copy link
Contributor

@shubham1g5 shubham1g5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple general comments -

  1. Can we add a Jira link and repro steps in the PR description to help anyone coming across this PR in future.

  2. We also discussed setting up the audio config callback and pause recording on our side if we get `isClientSilenced() as true to handle situations in which user navigates away from CC recording and start a new recording. Curious if there is a reason so that we decided to not implement it ?

Comment on lines 208 to 212
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
recorder.setAudioSource(MediaRecorder.AudioSource.VOICE_COMMUNICATION);
} else {
recorder.setAudioSource(MediaRecorder.AudioSource.MIC);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should test that the recording with source set to VOICE_COMMUNICATION are playable in browser (instead of download) on HQ.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any updates here ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I tested it and it plays normally.

@avazirna
Copy link
Contributor Author

Curious if there is a reason so that we decided to not implement it ?
I'm indecisive about it. I did implement it but during tests, the changes to the configuration seemed sufficient to ensure that CC continues recording even though other apps are trying to record (the other apps get not sound). However, I don't have certainty about whether the third-party apps that I used have the same configuration, so maybe better to include. What do you think?

@shubham1g5
Copy link
Contributor

I would think that we should include it as it seems to be the most fullproof solution to have empty recordings (callback works irrespective of Android version ?)

@avazirna
Copy link
Contributor Author

avazirna commented May 1, 2024

callback works irrespective of Android version ?

From Android 7.1. But the tricky part is in assessing when the recording has gone silent, isClientSilenced () was introduced in Android 10. For versions prior to 10, I was considering using getMaxAmplitude() but I wasn't able to thoroughly test its reliability. Any thoughts?

@avazirna avazirna requested a review from shubham1g5 May 2, 2024 08:35
Copy link
Contributor

@shubham1g5 shubham1g5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For versions prior to 10, I was considering using getMaxAmplitude() but I wasn't able to thoroughly test its reliability. Any thoughts?

I think the only way to check will be to test it out. Have you been facing difficulties testing ?

@avazirna
Copy link
Contributor Author

avazirna commented May 3, 2024

I think the only way to check will be to test it out. Have you been facing difficulties testing ?

The testing was successful. The tricky part is in having certainty that 0 (zero) amplitude always means that the recording has gone silent and not that maybe that there is no sound to record, i.e. people stopped talking and there is no background noise.

@shubham1g5
Copy link
Contributor

people stopped talking and there is no background noise.

Are you getting a 0 output from the method in this case ?

@avazirna
Copy link
Contributor Author

avazirna commented May 3, 2024

people stopped talking and there is no background noise.

Are you getting a 0 output from the method in this case ?

Not necessarily, which gives me 80% confidence that this option should work fine, so happy to push this out and have QA confirm that that's the case. Agree?

@shubham1g5
Copy link
Contributor

Not necessarily, which gives me 80% confidence that this option should work fine, so happy to push this out and have QA confirm that that's the case. Agree?

Sounds good to me.

@avazirna avazirna requested a review from shubham1g5 May 5, 2024 21:29

try {
Thread.sleep(500);
} catch (InterruptedException e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't feel right to me. If we don't think recorder.getMaxAmplitude(), lets not use it at all instead of hacking something ambiguous here. I would suggest that we only do a one time check on recorder.getMaxAmplitude() and treat it as reliable unless we find otherwise

@avazirna avazirna force-pushed the handle-recording-configuration-changes branch from da57e51 to 93e8e8f Compare May 6, 2024 11:54
Copy link
Contributor

@shubham1g5 shubham1g5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good :)

@avazirna
Copy link
Contributor Author

avazirna commented May 6, 2024

@damagatchi retest this please

2 similar comments
@avazirna
Copy link
Contributor Author

avazirna commented May 7, 2024

@damagatchi retest this please

@avazirna
Copy link
Contributor Author

avazirna commented May 7, 2024

@damagatchi retest this please

@avazirna avazirna merged commit c440c43 into master May 7, 2024
4 of 7 checks passed
@avazirna avazirna deleted the handle-recording-configuration-changes branch May 7, 2024 21:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants