[TIMOB-2177] Changing hardware in the middle of playback/recording may cause crash
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Low |
Status | Closed |
Resolution | Hold |
Resolution Date | 2011-04-15T03:12:50.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Backlog |
Components | iOS |
Labels | apple, bug, crash, hardware, ios, recording, sound |
Reporter | Stephen Tramer |
Assignee | Stephen Tramer |
Created | 2011-04-15T03:12:49.000+0000 |
Updated | 2017-03-03T07:02:36.000+0000 |
Description
Easiest to test on an iPod. With headphones+mic plugged in:
KS->Phone->Sound->Record
Begin Recording
After recording a message, yank the headphones (do NOT click the
'stop recording' button)
Click 'playback' (you will hear nothing, and the button will never
change from 'stop playback')
Plug headphones back in
Click 'record' again
CRASH
The first part of the bug (no playback) probably has something to do with how the recorder handles audio queues and whether or not it even saves the file produced by the recording. Second part of the bug is probably a session issue, where the audio session continues to try and use the previous hardware.
Surprise... this is an Apple bug.
Radar # 8933998. Will come up with a workaround for now that will not result in a crash.
Putting the ticket into the usual "hold/TBS" pattern for Apple bugs, but will still try and submit a slap patch to remove the crash.
(from [8ae839bfe83302d3197efdfddb97a2ff2efc4fc3]) [#2177] Workaround to prevent ugly crash on hardware availability change. We should be catching all of these C++-style exceptions and rebranding them, anyway... https://github.com/appcelerator/titanium_mobile/commit/8ae839bfe83302d3197efdfddb97a2ff2efc4fc3"> https://github.com/appcelerator/titanium_mobile/commit/8ae839bfe833...
Closing ticket due to time passed and irrelevance.