I’m using AL_PITCH as well and so I was happy that it was implemented.
I tested the music pausing - yep, when I paused my game 10 times, there was one time when the music didn’t resume, but on the next pause/resume it started playing again.
Regarding the home (start) button functionality - according to MS documentation it shouldn’t close the app (like the back button), but should push it to the background:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/dn148258(v=vs.105).aspx
>> I’m using AL_PITCH as well and so I was happy that it was implemented.
I’m glad AL_PITCH is working for you.
>> I tested the music pausing - yep, when I paused my game 10 times, there was one time when the music didn’t resume, but on the next pause/resume it started playing again.
I’m starting to think that this might be a core Corona issue that might happen on other platforms based on what I’m seeing in our code. I’ve seen a similar bug report on iOS and Android in the past. If you suspend/resume several times on iOS or Android, does the streaming music sometimes stop too?
>> according to MS documentation it shouldn’t close the app (like the back button), but should push it to the background:
But it will. Microsoft does not guarantee that the app will be resumed when returning to your app after pressing the Start button. They threaten that the device might decide to “tombstone” it. To prove it, put break points in your “App.xaml.cs” file’s Constructor, Deactivated, and Closing event handlers and launch your app. Notice that when you press the Start/Home button, it’ll Deactivate as expected, but when you go back into your app, it’ll break in your App class’ constructor. This proves that the Application was terminated and being re-created when re-launched. The same behavior can be observed with a WP8 app made with Microsoft’s project templates. It’s not caused by our Corona library.
Microsoft documents this here under the “Deactivated” section…
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff817008(v=vs.105).aspx
In my experience, this tombstoning behavior always happens when pressing the Start button. I’ve yet to see a WP8 device resume an app afterwards, but I wonder if it might have something to do with how much RAM is available on the device. The Lumia 920 that I typically test with is considered a low memory device.
I’ll work on this later. The XAML events we’re currently depending on to raise system events in Lua work in all cases *except* for the Start/Home button. So, we’ll just have to hook into other events to get it working right. Just another to-do item on the list. We’ll get to it. 
One more thing app pressing the Start/Home button. I figured out what’s going on. If you press the Start/Home button and then tap on your app from the app listing, it will *always* restart your app. However, if you hold down the Back button to bring up the “Fast App Switcher” and tap on your app from there, then it will resume.
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj735579(v=vs.105).aspx
I remember figuring that out a while ago and I guess I forgot how it works again because I’m used to Android’s behavior. 
I remember other WP8 app developers complaining to Microsoft about this, asking them to change the behavior to be more like Android on 8.1.
Pressing the Back button after pressing the Start/Home button will resume your app too.
Oh! I didn’t even know about the “fast app switcher” to be honest Yep - it works like you say. It’s resuming the app instead of relaunching it. Thanks for the info.
Regarding the music pause/resume on iOS - I haven’t noticed this behaviour, but maybe it’s just not as frequent as on WP8. Can’t say.
>> Yep - it works like you say. It’s resuming the app instead of relaunching it. Thanks for the info.
No problem! Honestly, I keeping forgetting that this is how WP8 works too because I’m so used to Android’s behavior.
>> Regarding the music pause/resume on iOS - I haven’t noticed this behavior
Okay. Fair enough. I do know that we have some old closed out bugs on this on Android and iOS. I’ll dig into how this issue was resolved on those platforms later.
In the meantime (and if you don’t mind), you should be able to work-around this issue by calling audio.pause() on your streaming music upon “applicationSuspend” and then upon “applicationResume” call audio.play(). That’s how Corona developers used to worked-around this on iOS and Android in the past.
Other than that, how is everything else working out for you on WP8?
Oh and in regards to 60 FPS. I’m still struggling to achieve this. It’s proving to be quite difficult to do this on WP8. Every solution I’ve tried has had some kind of negative impact on something else.
At this point, I’m thinking that if I can’t come up with a reasonable solution by the end of today, then I should punt on this issue and starting working on that Native/Lua bridge instead and the other nagging issues (like timers elapsing too soon, audio not resuming, etc.). That way I’m not blocking you from implementing in-app purchase and other tasks. Does that sound reasonable at the moment?
I agree, I think it would be the best decision for now. But could you include the improvement you already achieved in the next update?
But there’s sth more - I’ve just tried to upload a test xap package made with CoronaCards to my MS dev center but the package didn’t pass the validation:
1028: The native API api-ms-win-core-debug-l1-1-1.dll:OutputDebugStringA() isn’t allowed in assembly CoronaLabs.Corona.Component.dll. Update it and then try again.
1028: The native API api-ms-win-core-localization-l1-2-0.dll:FormatMessageA() isn’t allowed in assembly lua.dll. Update it and then try again.
1028: The native API api-ms-win-core-synch-l1-2-0.dll:CreateMutexExA() isn’t allowed in assembly almixer.dll. Update it and then try again.
Should I make a build in a specific way to skip these APIs, or it’s on your side to remove it?
It’s on my side to remove. I didn’t realize ASCII version of those functions were not allowed on the app store. Interesting since those functions are publicly available. Anyways, I’ll change them over to Unicode wide character version next week. Thanks for bringing this up.
Oh and yes, I’ll add the other timer improvements I talked about before.
Here’s a current update on the 60 FPS issue so far. I can only get it to render at 60 FPS if I do absolutely nothing on the main UI thread. As soon as I do anything interesting on the main UI thread (or perhaps any thread?), even if only by a 3-4 milliseconds, it seems to have a negative impact on the Direct3D rendering thread and I can only get about 40-45 FPS. Even if I happen to do everything with the 16 millisecond timeframe needed for 60 FPS, the rendering thread still skips a frame on every few frames. That’s incredibly frustrating and it makes it sound like 60 FPS might be impossible with a XAML based app… at least on the phone I’m testing with.
The alternative solution that I was talking to you about before was to update Corona and its physics on-time 60 times a second and render when I can (because the rendering thread appears to be lazy and is out of my control). With this approach, I can update Corona on-time 60 times a second, but only render 40 times a second. So, from a Lua and physics standpoint everything appears to be running at 60 FPS, but the display will only render at 40 FPS. Still better than 30 FPS, but it’s still not truly 60 FPS.
Is it better if you don’t use physics at all?
@Joshua, I meant the improvements to fps that you made. If there are no visible slow downs now then maybe 40fps would appear smooth enough for our needs, at least for now. I’d be happy to test it.
The main issue in my game is that the physics frame-rate slow downs are getting bigger after time. It looks that after every following level load I have worse physics performance.
I though that it might be caused by a memory leak, but I checked and I have only 2-5kb leaks so it shouldn’t be an issue. When I load the first level, physics response is decent, some slow downs appear, but nothing serious. But after I load the level several times - the slow downs are getting more and more visible. I even tried to call physics.stop() and remove all scenes before loading the next level but it doesn’t help the performance.
I don’t have this issue with the same code on iOS, only on WP8, and I’m curious if the changes that you already made to the physic speed calculations would help to solve that issue.
Without physics, such as our “Graphics\Fishies” sample app, I’m seeing about 5-10 frame improvement. So, it renders at about 45-50 FPS. Interesting since the other app I was testing only adds about 1-2 millisecond overhead with physics, well within the 16 millisecond time period needed for 60 FPS.
45…50 is really good!
Yeah, it’s 45-50 rendered and I’m updating Corona/physics 60 times a second. Seems to be the best compromise. Especially if your physics system is framerate based, which it is by default. It just kind of irks me that I can’t get this phone I’m testing with to render faster. Especially since I’m easily updating/rendering everything within 16 milliseconds.
Can you send me your binary somehow so I can test it and measure FPS on my Lumia 625?
I don’t know if it’s possible.
>> The main issue in my game is that the physics frame-rate slow downs are getting bigger after time.
Olaf, that definitely sounds like a memory leak. I don’t think the framerate improvements that I’m making will help with that.
I’m not seeing any leaks with the apps I’m running at the moment… or Visual Studio isn’t detecting the ones you are seeing. Would you be willing to send your project to us so that we can try it for ourselves?
Also, I do know that tomorrow’s daily build will contain some memory leak fixes for all platforms. There were some minor memory leaks involving rendering geometry via display.newLine(), newCircle(), newRect(), newRoundedRect(), and newPolygon(). It was a minor leak, but they would accumulate over time if you create/destroy these often. I’ll get a hold of those fixes and include them in our next WP8 build for you guys next week.
Lerg, would you mind waiting until next week?
I don’t a nice means of packaging everything up right now.
Plus, I’ll see about finishing implementing what since it *is* an improvement.
Sure, no hurry.
Joshua,
OK, you were right - I had one particle update enterFrame listener that I didn’t remove before exiting scene. Oops…
Now everything runs fast after several level updates. My bad. There still are frame-rate slow downs, but they don’t increase in time.
Anyway, thanks for your help.