deallocate() and close() on 6230i crashes the phone

[killarkai]

I am aware that on the 6230i only one player can be in the prefetched state at a time, therefore, doing a deallocation is a MUST before playing another sound. However, calling either deallocate or close will freeze my game.

Note that I'm doing porting so I encountered this at the very end of my development schedule, that means everything is done before I added in sound.

I tried to write a simple app to do deallocating and playing, back and forth between two players, it does not pose such problems. It ONLY happens in my game, it does not cause the emulator nor any S60 devices to freeze.

Wonder if anyone out there encountered this weird problem? Any suggestions are great appreciated!

[killarkai]

I used writing messages to RMS to debug this problem, and found out prefetch() sometimes freezes the phone too. After a good few days of stripping down the code(and subsequently repatching), I found out the problem is solved by simply...

Replace the use of Canvas with GameCanvas!

Using Canvas in 6230i causes prefetch/deallocate to freeze, don't bother trying to build an app simply to play sounds to check though, because I found out in a small application, there is no such problem.

Keep this in mind always - use Canvas in your 6230i at your own risk!

[happyer]

Hi, I have the same problem with you. I can only play one midi, when I stop and deallocate it to play another one, the game freezed ! But in a simple app, No such problem! I guess the 6230i need more heap to play the second midi, but in a huge app the heap is very limited, while the simple app has enough heap to do that.
Because I am doing porting work, so I cann't easily replace Canvas with GameCanvas. If there is another way to solve this headachy problem ? (And I can't understand why the GameCanvas won't encounter this problem)
Thanks very much !

[killarkai]

I'm not aware of any other solution as for now... I'm doing porting work too, try to reason with your superiors to approve a change to Gamecanvas, theres not much code change needed.

[happyer]

I have replaced Canvas to GameCanvas, but the problem is still exist. I don't known why this method can help you but it doesn't work for me. It's just my luck?

[killarkai]

I have no idea why it worked for me.
To make my phone crash during sound play I just had to change GameCanvas To Canvas! It's that simple.

Good luck in searching for your solution, looks like you need Nokia's help... please post the solution if you found any.

[ianharper]

I am having the same problem as happyer. I have tracked it down to the player.stop() method, which appears block for 10 seconds, during which time the application is unresponsive.

I tried drastically reducing application usage, which I got down to 150kb (in the SonyEricsson K750i emulator anyway), but this did not improve the situation. I also tried swapping my GameCanvas for a nokia FullCanvas, but with no effect. Tried changing from Timer based processing to callSerially based processing, but no effect. I have also tried all ways of loading and prefeching the midi tracks, but again no effect. Also tried doing lots of gc() calls, and also doing none.

Oddly, some midi tracks in the application stop() without delays. I tried swaping the files around, but this made no difference to where the delays happened.

Often when several different midi tracks have been played in a row, or started and stopped repeatedly, the midi device seems to fail, and does not function correctly again until the phone is powered off and on again.

If anyone at Nokia can look into this, that would be great. I can provide full source on a confidential basis to help investigate the issue.

I need this fixed for a port I need done by tomorrow!

[ianharper]

"drastically reducing application usage" - memory usage this is :-)

[ianharper]

I have a partial resolution to the problem. i found that if the player is stopped from a system thread, specifically Canvas.keyPressed(), there is a 10 sec delay - but only on that thread. The solution was to queue up midi commands issued during key presses, and then execute them from the main user thread (the gameloop in my case). Interestingly, when the 10 sec delay happened during a keypress event, the main thread continues to run normally - the stall is not system wide.

unfortunately, this has not fixed all the 10 sec delays. i am left with 2 places where 10 sec delays always occur. bizarely, one of them is on a screen which can be skipped by pressing a key, or when an animation finishes playing: if a key is pressed, no delay occurs, but if left until the animation is complete, there is a 10 sec delay! both methods result in the same code being run, from the same thread, so should have identical behaviour - but apparently not.

in keyPressed() i simply set a boolean flag 'skip' to true. the main loop simply checks:
if ( skip || anim.isFinished() ) ... exit screen ...

I am at a complete loss as to explain how the behaviour is different when a key is pressed or not.

[tkloss]

Hi!

Are you calling stop() from a synchronized keyPressed() method?
Don't use the java keyword "synchronized" for keyPressed() on N6230 and N6230i, if you are calling sound methods in it.

[killarkai]

Almost one year after I first posted this, I found myself having to work on the Nokia6230i again, and again I face the same problem.

This time along, I realize that just omitting serviceRepaints() while using the original Canvas will solve the problem. I hope I didn't lead people astray with my original solution. Would be nice if someone can verify this.