[TIMOB-7410] Android: V8: Titanium.Media.Sound: play() fails when sound object is local to an event listener
| GitHub Issue | n/a |
|---|
| Type | Bug |
|---|
| Priority | Medium |
|---|
| Status | Closed |
|---|
| Resolution | Invalid |
|---|
| Resolution Date | 2012-02-08T14:31:40.000+0000 |
|---|
| Affected Version/s | Release 1.8.0.1, Release 1.8.1 |
|---|
| Fix Version/s | n/a |
|---|
| Components | Android |
|---|
| Labels | qe-and012312 |
|---|
| Reporter | Dustin Hyde |
|---|
| Assignee | Bill Dawson |
|---|
| Created | 2012-01-25T15:55:23.000+0000 |
|---|
| Updated | 2012-05-18T00:43:11.000+0000 |
|---|
Description
Android: V8: Titanium.Media.Sound: play() fails to play (6 times out of 10) and generates errors when called on an object created in the event listener doing the play() call. Log Attached.
In Rhino, sounds play correctly, but there are error messages. Log Attached.
In V8, if the sound object is stored in a higher scope, play() works as it does in Rhino.
Steps to Reproduce:
1. Run SoundTest app. Project Attached.
2. Press the sound buttons, read the console, listen to the sounds.
Expected Result:
Sounds should play every time a button is pressed and generate no error messages.
Actual Result:
Sounds rarely play and generate error messages.
Note: Test Case exists in /titanium_mobile_tests_internal/FeatureTest/Media/module_media > TIMOB-5330.
Note: Will investigate behavior on more devices in the future.
Attachments
I've been playing with this now for a while on 2 devices and 1 emulator: Device 1: Model: T-Mobile G-Slate Android: 3.1 Device 2: Model: HTC Desire Android: 2.2 Emulator: Android 2.2 I've been using our master branch (hash 6249fc07), and also 1.8.0.1 for comparison purposes. To me it seems like the behavior is already _much_ improved in master, and indeed there have been fairly recent Sound-related changes. However, it's still not "perfect", but the behavior is basically the same as what I see in a native (non-Titanium) Android application that I built for comparison purposes. With this test Titanium app (and my native Android app which follows the same idea), memory will fairly quickly run out and kill the media player. That's because this test app -- at least for Android -- is pretty crazy. Each time you click a button, an entirely new [Android MediaPlayer](http://developer.android.com/reference/android/media/MediaPlayer.html) instance is created and prepared (because our
createSoundis called each time), without any of the previous ones beingrelease'd. This is madness (in Android, anyway), and hopefully not a real-world way that someone is writing an app. If it works fine in iOS, then maybe iOS has a lighter-weight way (or simply better performing, less memory-eating way) of playing sounds: meaning, better than Android's MediaPlayer. In a real app, I would hope our Sound proxy instances would be re-used rather than re-created every time. Anyway: @DUSTIN, can you run some tests against master (1.9.0) and see if the behavior is indeed better, as I described? If so, I think you would probably want to close this. I've spent a long time examining our code and comparing it to a native Android app's similar code, and I don't believe we're doing anything different than would be expected.Tested with: SDK: 1.8.0.1 githash=fbdc96f, 1.9.0.v20120207171634 Android: V8 Studio: 1.0.8.201201262211 OS: Lion Devices Tested: iPhone4 5.0.1, Droid3 2.3.4, Nexus One 2.2.2 Results: The 1.9.0 behavior is similar/identical to the older 1.8.0.1 behavior. The sound object is not being used properly. Closing issue as invalid. Changed code to re-use sound objects, opening new issue for iOS/Android sound performance.