×

Discussion Board

Results 1 to 11 of 11
  1. #1
    Registered User
    Join Date
    May 2003
    Posts
    39

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

    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!

  2. #2
    Registered User
    Join Date
    May 2003
    Posts
    39
    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!

  3. #3
    Registered User
    Join Date
    Apr 2005
    Posts
    15
    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 !

  4. #4
    Registered User
    Join Date
    May 2003
    Posts
    39
    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.

  5. #5
    Registered User
    Join Date
    Apr 2005
    Posts
    15

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

    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?

  6. #6
    Registered User
    Join Date
    May 2003
    Posts
    39

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

    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.

  7. #7
    Registered User
    Join Date
    Aug 2005
    Location
    London
    Posts
    5

    Unhappy Re: deallocate() and close() on 6230i crashes the phone

    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!
    Ian Harper
    Lead Programmer
    [url]www.shadowlightgames.com[/url]

  8. #8
    Registered User
    Join Date
    Aug 2005
    Location
    London
    Posts
    5

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

    "drastically reducing application usage" - memory usage this is :-)
    Ian Harper
    Lead Programmer
    [url]www.shadowlightgames.com[/url]

  9. #9
    Registered User
    Join Date
    Aug 2005
    Location
    London
    Posts
    5

    Exclamation Re: deallocate() and close() on 6230i crashes the phone

    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.
    Ian Harper
    Lead Programmer
    [url]www.shadowlightgames.com[/url]

  10. #10
    Registered User
    Join Date
    Feb 2006
    Posts
    1

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

    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.

  11. #11
    Registered User
    Join Date
    May 2003
    Posts
    39

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

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×