Re: App slows down -after- it begins

Simon · Post by **Simon** » Fri Nov 14, 2014 1:32 am

Sorry to be a buttinski but.
What is the actual size (weight) of your wav files?
Do you have the tools to change them into .mp3's?
A tick/click sound should be less than 20 kb (err... imagine the "pong" bleep when the ball hits the paddle)

Ignore this post if irrelevant

Simon

rumplestiltskin · Post by **rumplestiltskin** » Fri Nov 14, 2014 4:57 am

Jacque,

I am now understanding why you are recommending this approach. I need to subtract what may be overhead time that LC or Android may be adding due to some inefficiencies.

I'm going to try a copy of my stack stripped of everything except the audio just in case there's something else going on. (I doubt it, though, as turning off the sound, programmatically, lets the app move the graphic and increment the counter field perfectly (or as accurately as I can measure).

- - - - - - - - - -

Simon,

My audio files are tiny; 4KB and 8KB. I've attached them to this post. I used .wav as they are as close to being uncompressed as possible.

Edit: The files don't seem to be attached. I've posted them here:
https://copy.com/IyooWT4IUBxbKfjn
and here:
https://copy.com/I71TNT2znAMREouI

jacque · Post by **jacque** » Fri Nov 14, 2014 5:08 am

That's right. Now if I'm wrong after all that, you'll kill me.

rumplestiltskin · Post by **rumplestiltskin** » Fri Nov 14, 2014 5:21 am

Jacque,

1. If I can quantify the delay (and it's consistent), then a little math will resolve it. I can either alter the timing programmatically in the manner you suggest -or- (and this might be easier) take the delay into account so if the user specifies 120 beats per minute, I add the delay % (ie, 120 * let's say 10% delay = 12 extra beats so I tell the app to use 132 bpm behind the scenes and end up with 120; my math may be wrong here but you get my drift).

2. If it's not consistent, then I'll have to improve the visual feedback to the point where an audio cue isn't necessary.

3. Maybe, just maybe, ART instead of Dalvik resolves this. (http://arstechnica.com/gadgets/2014/11/ ... -reviewed/.)

Ledigimate · Post by **Ledigimate** » Fri Nov 14, 2014 1:05 pm

If you'd like to try a different approach, the followig might work for you.

You could implement a timed handler that calls itself with a 5-millisecond interval, and in that handler you get ((the milliseconds - startMilliseconds) div bpmMilliseconds) and compare it to a variable that was initialized to 0, e.g. tBeatsElapsed. If it is greater than tBeatsElapsed, you update tBeatsElapsed to it and also send a playBeat message. In the playBeat handler you determine what sound to play and play it. This way your beats should stay in sync with the clock, regardless of the overhead. The timer handler would obviously check a variable e.g. theTimerIsEnabled, before calling itself.

I haven't tried it yet, but you may want to give it a shot.

Regards,

Gerrie

*BIG EDIT: I changed "mod" to "div"! That was an oopsie!

Ledigimate · Post by **Ledigimate** » Fri Nov 14, 2014 2:10 pm

Okay I've created a simple stack that demonstrates the method in my previous post. Have a look at the attached sample stack.

rumplestiltskin · Post by **rumplestiltskin** » Fri Nov 14, 2014 5:21 pm

Ledigimate,

Wow! Thanks for creating that bpm sample stack. That saved me a lot of time and effort for the testing.

I added my audio clip (the 4KB "Click.wav") in the manner spec'd by LC (using the Copy Files tab of the Standalone Application Settings window), added in the mobilePlaySoundOnChannel command in the "on playBeat" handler as you so kindly indicated, compiled, then transferred the app to my phone.

Here's the result: At 60 bpm, it's dead-on accurate; I had an audibly ticking clock next to me so I could compare the timing of the sounds. At 120 bpm or faster, the overall timing seemed to be accurate but, individually, there was a slight shift in the timing; you might hear a longer gap among a few clicks but it eventually seemed to "catch up" to the proper timing. Still, however, not accurate enough for this app's requirements.

{time passes} Just discovered how to enable ART (and turn off Dalvik) on my Nexus 5. Apparently, I don't have to wait for Lollipop (5.0) for this. The phone rebooted and is in the process of "optimizing" all the apps for ART. I'll report back once I run some more tests.

Barry

jacque · Post by **jacque** » Fri Nov 14, 2014 6:09 pm

If you plan to distribute the app you can't rely on users having ART enabled. Also, the overhead will not be consistent from one device to another, and may not even be consistent on the same device if Android is running certain background processes or doing maintenance.

If Ledigimate's method doesn't work out, try mine. It's been used successfully for clocks and other timekeeping tasks. There's no math involved outside of the line I posted

rumplestiltskin · Post by **rumplestiltskin** » Fri Nov 14, 2014 6:29 pm

Ledigimate,

Okay; ART really doesn't make a difference in the accuracy of either my app or yours. I even added two fields to your app so it would record the long time in the first field when I clicked "Start" and the long time in the second field when I clicked "Stop". I set the bpm to 180. Result: Accurate to the second after a one minute, 180 beat run but the individual timings of the audio (as perceived by my ears) were not "regular". Imagine a ticking clock whose ticks varied by some small percentage but, after one minute, did tick the required amount of times. My app, though, still slows down so the bpm heard is less than the bpm set. I know it's the audio causing the issue because, when I turn off the sound in the app, the motion of my graphic and the incrementing of the counter are spot-on.

So I have a fairly new phone with a relatively beefy CPU. I'm running Kitkat 4.4.4 with ART enabled instead of Dalvik. Dalvik used a just-in-time compiler whereas ART uses an ahead-of-time compiler so the compilation is done when the app is installed, not when it runs. ART is also allegedly free from the cruft of older Android OSes. However, I could only set the minimum Android version to 3.1 in LC's Standalone settings, nothing higher. I may have to update to the latest SDK to get 4.0 as the minimum (although I seem to recall there were some issues that prevented LC from creating an app due to some altered file locations within the SDK). I'll try it on my other Mac.

As my audio clips are so tiny (4K and 8K) and are as close to uncompressed as possible (.wav), I don't think I'm asking LC to do too much heavy lifting. This may simply be some inefficiency in LC in the code it provides to the Android device (or Android just sucks). Perhaps I can find a a friendly C++ programmer who'd like to try coding your sample app; then we can compare timings. I may also submit this as a bug for the LC techies to look at.

Gawd! I don't want to have to learn C++. As Lewis Black says: I'd rather poke out my eyes with a fork.

rumplestiltskin · Post by **rumplestiltskin** » Fri Nov 14, 2014 6:32 pm

Jacque,

Thanks. I'll give it a shot and report back.

Barry

jacque wrote:If you plan to distribute the app you can't rely on users having ART enabled. Also, the overhead will not be consistent from one device to another, and may not even be consistent on the same device if Android is running certain background processes or doing maintenance.

If Ledigimate's method doesn't work out, try mine. It's been used successfully for clocks and other timekeeping tasks. There's no math involved outside of the line I posted

jacque · Post by **jacque** » Fri Nov 14, 2014 8:15 pm

One other thing you can add that might help. Import your .wav files directly into the stack to eliminate the delay involved in reading them from disk. You'll still need to account for the overhead in setting up the playback mechanisms, but the more intensive disk read will be eliminated.

PS: Please don't poke out your eyes.

rumplestiltskin · Post by **rumplestiltskin** » Fri Nov 14, 2014 10:00 pm

Jacque,

In a post in March 2012, you advised against embedding audio for mobile:

http://forums.livecode.com/viewtopic.ph ... oid#p54055

Has that now changed? I ask because it doesn't work in my stack.

Edit: I'm on Android.

jacque · Post by **jacque** » Fri Nov 14, 2014 10:06 pm

Oops, you're right. Sorry. My brain was stuck in desktop mode.

rumplestiltskin · Post by **rumplestiltskin** » Fri Nov 14, 2014 11:31 pm

I'm posting Ledigimate's stack with a couple of mods compiled for Android; you may find it here: https://copy.com/Ah3u7cETCNFypPmJ . I've signed it "for development only" so it should install on any Android device you have that's running v3.1 or newer. (You'll also need to set your device to install apps from sources other than the Play Store.) My audio "click" wav file is now down to .01 second in length so one would think the length ("richness" or lack thereof) should be an issue. The audio file is 280 bytes (yes, bytes) in size.

The posted file is zip'd. It contains the stack, the audio file, and the apk ready for installation in Android.

I've added two fields to Ledigimate's stack; one is filled with the long time when pushing the "Start" button, the other is filled with the long time when pushing the "Stop" button. If you spec 180 bpm and let the app count up to 180 beats, the elapsed time is exactly 1 minute so whatever math Ledigimate used is, overall, keeping time as best it can. However, when listening to the clicks during the run, you can hear how their occurrence slows down and speeds up. At 280 bytes, I just can't believe my audio file is the cause of this problem. I'm leaning toward some inefficiency in LiveCode's engine for Android.

I'm going to file a bug report and see what comes of it.

Barry

Simon · Post by **Simon** » Sat Nov 15, 2014 1:50 am

Hi Barry,
The mobilePlaySoundOnChannel does work better but I had to increase the length of Click.wav to 0.5 sec to get it to work.
There is some error in the preOpenCard, haven't debugged it but put this in

Code: Select all

on errorDialog pExecutionError, pParseError
answer "An error occurred on line: " & item 2 of line 1 of pExecutionError & cr & pExecutionError
end errorDialog

very handy when working with mobile.

And I think this helped

Code: Select all

on openCard
   put url("binFile:" & specialFolderPath ("engine") & "/Click.wav") into url("binFile:" & specialFolderPath ("documents") & "/Click.wav")
end openCard

then play the "documents" folder.
Not sure if it really did help my ears are getting tired of listening to it.

Simon