Re: App slows down -after- it begins

The place to discuss anything and everything about running your LiveCode on Android

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7393
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: App slows down -after- it begins

Post by jacque » Sat Nov 15, 2014 3:53 am

There is some error in the preOpenCard,
The first line inside the "if" clause should be: set the rect of this stack to the screenrect <--
Only it's not necessary because on mobile the stack is always set to the screenrect.

I haven't actually run this in Android yet but I'm thinking that the overhead of updating the field text is bogging down the timing. Updating fields is about the slowest thing you can do in LiveCode. Also, the unquoted literal in the field name will make it slower too.

Edit later: I did some timing tests and the field update is measureable but probably not significant. The lag is something else, but I'm not convinced yet it's a bug.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

rumplestiltskin
Posts: 223
Joined: Wed Jun 21, 2006 7:33 pm
Contact:

Re: App slows down -after- it begins

Post by rumplestiltskin » Sat Nov 15, 2014 4:55 am

Simon,

Thanks for the "screenrect" correction. Funny thing; it never errored on my phone.

I have another app (that I wrote; the one you are playing with is from Ledigimate) that has no corrections for any delays encountered from click to click. So, when you run it at, let's say, 180 beats per minute, it begins to slow down after maybe 20 clicks. I have a huge text field; there's a counter that cycles from 1 up to 3, 4, 5, 7 or 9 depending on the signature the user selects. The field displays the number at 255 points in size. There's also a button that switches off the sound (exits the playSound handler without playing anything). When that's set to "no sound", the app runs perfectly. Timing is flawless AFAICT.

Why would increasing the length of the audio file result in an improvement? I would think it would, if anything, make it worse as there's more to load and more to play. As my sound is 1/100 of a second, the irregular inter-click spacing has to be caused by the Android engine.

I also see I made a slight mistype in my last post. I was commenting on the small size of the wav file and wrote it "should be an issue"; I actually should have written "it should not be an issue".

I posted a bug report: http://quality.runrev.com/show_bug.cgi?id=14030

Edit: If you'd like my app (stack and/or Android app), let me know. It's done with the Community edition 7.01

Simon
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3901
Joined: Sat Mar 24, 2007 2:54 am

Re: App slows down -after- it begins

Post by Simon » Sat Nov 15, 2014 5:15 am

Why would increasing the length of the audio file result in an improvement?
Not quite what I meant.
I needed to increase the length to get mobilePlaySoundOnChannel to work, which was more consistent.
Or do you see mobilePlaySoundOnChannel working with your original Click.wav?
Thanks for the "screenrect" correction
That was Jacque :)
Funny thing; it never errored on my phone.
No you wouldn't see an error, it fails silently. That is why I posted that error code.
I have a huge text field
Yeah, that was something Jacque just mentioned... Really slow operation when you update it.

Simon
I used to be a newbie but then I learned how to spell teh correctly and now I'm a noob!

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7393
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: App slows down -after- it begins

Post by jacque » Sat Nov 15, 2014 7:15 am

I just loaded the apk you posted into my Nexus 7. I'm not sure if this is good news or bad, but it runs fine here. I set it for 60 bpm and watched the only clock I have with a second hand and they stayed in sync (now whether my clock is accurate is another story, but at least they both ran at the same speed.) I let it run about a minute without seeing any loss of synchronization. The results you're seeing could be due to differences across devices, like what's running in the background, the type of CPU, which radios are on, etc. If you feel like testing that theory, you could try turning off everything on your phone (put it in airplane mode and quit all other running apps) and see if you get a different result. That won't fix the problem but it may tell you what it is.

I thought about using a native player instead of the "play" command, which should cut down on overhead. A player only needs to load the file once, and after that it's prepared and ready to go. You could try that if nothing else works. I tinkered with it a bit but couldn't get the click sound to play. That may be the same problem Simon had with mobilePlaySoundOnChannel. (My old Archos tablet running Android 2.3 couldn't play any sound less than half a second long. But that was a long time ago.)
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

rumplestiltskin
Posts: 223
Joined: Wed Jun 21, 2006 7:33 pm
Contact:

Re: App slows down -after- it begins

Post by rumplestiltskin » Sat Nov 15, 2014 4:13 pm

If the sound doesn't play, the app will be dead-on accurate. Its when the sound actually plays that the problem appears.

Barry

Edit: Try it at 180 BPM.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7393
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: App slows down -after- it begins

Post by jacque » Sat Nov 15, 2014 11:21 pm

rumplestiltskin wrote:If the sound doesn't play, the app will be dead-on accurate. Its when the sound actually plays that the problem appears.
Right, but not playing a sound at all has no overhead, and trying to play one that won't load correctly still does. Anyway, try the script below. Replace the entire script of the card in the example stack with this:

Code: Select all

global startMilliseconds, bpmMilliseconds, theTimerIsEnabled, beatsElapsed

local sPlayerID
local sBeatMark -- time of last beat in ms


on openCard
  setupPlayer
end openCard

on timerCheck
  if not theTimerIsEnabled then exit timerCheck
  if beatsElapsed = 0 then put startMilliseconds into sBeatMark
  playBeat
  put sBeatMark + bpmMilliseconds into tTargetTime
  put tTargetTime - the milliseconds into tTimeLeft
  send timerCheck to me in tTimeLeft milliseconds
  put tTargetTime into sBeatMark
end timerCheck

on playBeat
  mobileControlSet sPlayerID,"currenttime","0"
  mobileControlDo sPlayerID, "play"
  add 1 to beatsElapsed
  set the text of field "lblBeatsElapsed" to beatsElapsed
end playBeat

on closeStack
  put false into theTimerIsEnabled
  if the environment = "mobile" and sPlayerID is in mobileControls() then
    mobileControlDelete sPlayerID
  end if
end closeStack

on setupPlayer
  if the environment <> "mobile" then exit setupPlayer
  mobileControlCreate "player"
  put the result into sPlayerID
  mobileControlSet sPlayerID, "visible", false
  mobileControlSet sPlayerID, "filename", specialFolderPath("engine") & "/click.mp3"
end setupPlayer
This uses a native player, which has the advantage of preloading before any counting begins. That eliminates the overhead of retrieving a file from disk several times per second.

The timerCheck handler keeps track of the milliseconds when the last beat occurred, stored in sBeatMark. After it plays the sound, it calculates the target time for the next beat and subtracts the overhead from that to determine when the next "send" command should happen. The timerCheck calcs could be collapsed into a single line of code, but I left it this way for clarity.

The playBeat handler triggers sound playback immediately before doing any field updates, to prevent LC's slower field management from introducing any lag. Once playback begins, there's time to update the field text before the next beat is due.

Finally, I had to replace your click sound with one of my own that is 1 second long. The original audio file was too tiny to trigger any activity in the player. (Mine failed to play once too, but I quit the app and reopened it, and it worked.) The length of the sound file doesn't matter here because the script resets the starting time to zero before each playback, and the audio is already loaded so there's no overhead. You could add a couple of seconds of silence to the end of the sound to ensure it plays (which I would do,) which won't matter because playback will never get that far. I think Android is optimized for mp3, so try that format.

My physical clock runs a little slow so I'm not certain this script is entirely accurate, and once you get up to 3 beats per second it's hard to tell whether you're in synch or not by eyeballing it. But this sounded pretty regular to my ear.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

rumplestiltskin
Posts: 223
Joined: Wed Jun 21, 2006 7:33 pm
Contact:

Re: App slows down -after- it begins

Post by rumplestiltskin » Sun Nov 16, 2014 4:15 am

Jucque,
Thanks for your work on this. I'm out of town for the weekend but will try your suggestion as soon as I return late tomorrow.

Regards,
Barry

rumplestiltskin
Posts: 223
Joined: Wed Jun 21, 2006 7:33 pm
Contact:

Re: App slows down -after- it begins

Post by rumplestiltskin » Mon Nov 17, 2014 8:45 pm

Jacque,

I replaced the code in the card script as you recommended but, upon compilation and installation of the apk in my Nexus 5, I get no sound. I then replaced the sound with a longer sound (I made it 1 second in length) saved as an mp3. I altered the code so it would be calling the correctly named file. No sound.

There's more testing I'll need to do but I just wanted to get some sort of response back to you to let you know I am trying.

Barry

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7393
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: App slows down -after- it begins

Post by jacque » Mon Nov 17, 2014 11:21 pm

Here's the one I was testing with. It didn't always play either, which is why I thought making a little longer might help. But most of the time it worked. I'll enclose the test stack too.
Attachments
beatsPerMinute.livecode.zip
(3.88 KiB) Downloaded 253 times
click.mp3.zip
(7.61 KiB) Downloaded 239 times
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

rumplestiltskin
Posts: 223
Joined: Wed Jun 21, 2006 7:33 pm
Contact:

Re: App slows down -after- it begins

Post by rumplestiltskin » Tue Nov 18, 2014 4:21 am

Jacque,

Your app is m-u-c-h better! Two or three times (only) during a 180 bpm run could I detect a very slight variation from a regular cadence. My stack, on the other hand, is just awful; bad click timings at least 20 or 30 times.

I did file a bug report: http://quality.runrev.com/show_bug.cgi?id=14030 and submitted Simon's stack and my original stack (which had no allowances for delays and, at 180 bpm, finished those 180 beats in a number of seconds considerably longer than one minute).

I've installed a couple of other metronome apps on my Nexus and every one was able to run at top speed (180-300bpm) with no problems; so I'm leaning toward some inefficiencies in LiveCode's implementation of crafting Android code.

I'm going to back off any more development that requires some seriously precise timings of audio playback until I hear back from LC's people regarding my bug report. They're doing some examination of it all right now. As I have no deadline for deploying, I'll work on other things and just be happy that you and Simon (and others) thought enough of this issue to lend not only moral support but sweat and code, as well. Many thanks! I am racking up a debt of many beers. I hope to buy a few rounds for everyone eventually.

Barry

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7393
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: App slows down -after- it begins

Post by jacque » Tue Nov 18, 2014 9:56 pm

I just read Hanson's reply and it looks like he came to the same conclusion we did here: playback has a lot of overhead. I think it's a little easier to load and replay a player than to juggle two sound channels, but either way should work. The short delays you noticed when you ran my example stack may not be fixable. If the OS is doing something in the background then LiveCode won't have a chance to respond to the next "send" until it regains control. That should only be an issue though at higher beats per second.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

strongbow
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 146
Joined: Mon Jul 31, 2006 1:39 am
Contact:

Re: App slows down -after- it begins

Post by strongbow » Wed Nov 19, 2014 9:36 am

I have a metronome app on the store and it works ok - though only for iOS at this stage. It's called BeatSpeak. Am using multiple sound channels and preloading them. Also using a timing scheme similar to what Jacque suggested.

I did port it over to Android just to see how easy it was and if it'd work ok, and also had some problems initially but I seem to remember that there was a setting somewhere that made quite a difference. Try perhaps switching on "idle timer" in the Standalone settings (though I'm not totally sure that was it!!). HTH!

Cheers, Alan

Post Reply