I am triggering short sounds dynamically from the library for a game (Specifically Air for Android). When the user clicks a button the sound can take up to 600ms to actually play.
I have set it for any silence before the actual sound by calling the sound like so:
private var channel:SoundChannel = new SoundChannel();
private var buttonClickSound:Sound = new button_click();
public function buttonDownClick() {
channel = buttonClickSound.play(63);
}
Still getting a ridiculous amount of latency.
Things I have tried:
converting MP3 to wav
placing Sound Clip in the timeline
calling Sound Clip from urlLoader
All return the same results. I know there are threads here that talk about this but none have offered a real solution that I can find. Is there no way to cache the sound or store it in a buffer?
Thanks for looking.
Important update
The flash CS5 AIR for android functionality was never out of beta. And sadly as adobe is famous for, the functionality has been discontinued for flash CS5 so that the full working/updated version will become a selling feature for CS6 or CS5.5. I have many, many feelings about this as a customer who has spent literally MANY THOUSANDS of dollars on adobe products but I'll keep this about information and not my burning rage towards adobe feelings. For proof of this see:
http://labs.adobe.com/technologies/flashpro_extensionforair/
So it is most likely that this is one of many bugs left unfixed in AIR for android in CS5. This is not a surprise, as when I bought CS4 master collection which promised AIR 1.5, even AIR 1.5 was left broken and all bug fixes were rolled into 2.0, which was only available for CS5. One of the biggest bugs they never fixed in CS4 AIR 1.5 was a major, crippling bug in webkit which nearly rendered any use of webkit in AIR non-functional. In fact when I worked for Webkinz.com, a major project was completely thrown out the window and I was actually ridiculed for proposing using AIR, touting all it's amazingness and then left looking like an idiot in front of all my peers when these bugs appeared. Literally I'm not kidding the head of my 180+ developer division centered me out in a meeting around a gigantic table with every major player in that company.
Anyway perhaps my update did bleed into somewhat of a rant but it's good information I think and a good lesson to be learned, which is always assume the worst with Adobe products. Fortunately, as mentioned in my answer, it's not a dead end and there are ways around their "business model."
Original Answer
It's a bug in AIR for Android:
http://forums.adobe.com/thread/753977
That post is dated, but I've seen several more around the same time frame and enough that I'd call it a fact. Have you updated flash CS5? ( Go to Help->Updates). To be honest I don't even know if they have patched/addressed this bug yet but your best bet of finding out is to grab the very latest Flex SDK and try manually packaging your SWF into an APK using it. Instructions:
http://help.adobe.com/en_US/air/build/WS901d38e593cd1bac25d3d8c712b2d86751e-8000.html#WS901d38e593cd1bac25d3d8c712b2d86751e-7ffb
More detailed/tutorial-like instructions:
http://thulasiramsoft.wordpress.com/2011/01/16/build-apps-for-android-using-as3-without-a-device-using-flex-air/
If this is a bug this is where you're going to see the fix appear first. Try packaging your SWF into an APK manually using the above methods and ensure you've updated the AIR for android on the device to AIR 2.6 (latest, just go to the market to update). This will either fix the problem or eliminate it as a possibility both on the compiler and runtime side.
Sound latency is a bug in Flash exporting to AIR.
Easy way around is to make some background music playing, then sound device doesn't go to sleep. If you don't want music you can make some silent sound playing forever. This solves the problem with sound delay for other short sounds.
[Embed(source="sfx.mp3")]
const snd_sfx:Class;
const sfx:Sound = new snd_sfx();
const SilentSoundTransform:SoundTransform = new SoundTransform(0);
function playSoundSilentlyEndlessly(evt:Event = null):void
{
sfx.play(0, 1000, SilentSoundTransform).addEventListener(Event.SOUND_COMPLETE, playSoundSilentlyEndlessly, false, 0, true); // plays the sound with volume 0 endlessly
}
playSoundSilentlyEndlessly();
Related
I have developed a system, in AS3 for Android, where one video after another plays, but after letting them run for an hour or two, the videos show between cut or slow. That happens when I run it on an android with device, but that does not happen on my PC. I have used the "dispose()" of the NetStream and set the NETSTREAM to NULL. Could someone tell me what's wrong? I've also set hardware acceleration to "DIRECT" and RENDER MODE to "AUTO". Oh, I also use System.gc();
At some point of development of my new game, I stumbled upon a problem which lead me to discovery of Adobe Scout. The problem occurred after some time of gameplay when the game started lagging more and more heavily up to the point when the whole application crashed. I did some profiling with Scout, and here's what I found: most, if not every heavy memory load is caused by gotoAndPlay() function (if I understand the data presented by the profiler correctly). This function always seemed and even felt like an easy task for Flash, but turns out it's not? Or is it caused by using text labels instead of frame numbers? I am currently looking for possible workarounds to use this method less, and while I do, it would be infinitely helpful to hear thoughts or possible options from people who are aware of this issue.
Hi I'm creating an adobe AIR application..Its working fine ,But I want to make my application without performance issues..How to Check Adobe AIR applications performance ?Is there any tools available?
Take a look at Adobe Scout
"Adobe Scout is the next-generation profiling tool for Adobe Flash Player and AIR."
When building any flash application you define the application FPS. If the real FPS (flash can skip frames under high load) is lower than the defined FPS- you have troubles. You can check the FPS by vast variety of FPS meters here.
If your real FPS coinsides with the defined one - it is great, but try rising the defined FPS value up to 120 (which is max) and check out the real value, it is hardly be higher than 60 during animations, but the higher you can get - the better your application is. With this approach you can eliminate or at least point out "slow code".
ADD: It also worth mentioning that if the defined FPS value is 24, and the application is in stable state (the amount of animation, animation complexity and computational complexity stay more or less the same) the real value will "float" across some value, let's say 23 FPS with the spread of 1-2 (i.e. 22.7, 23.5, 23.9, 23.1, etc). And the mean value will be always lower than the defined FPS value.
Try to check memory usage. I would start trying to launch Flash Builder profiler remotely while your app is running live on the device and check out memory utilization. Refer this
Try to check redraw regions. Note that MovieClips that are not visible (e.g. throbbers) are still redrawing unless the are stopped. So if you see some region redraws without sencible reason - try to figure out why. The ideal case is to call stop() and visible=false or remove from stage the unused animations.
ADD: Redraw regions indicator is a part of Debug version of Flash Player. You can enable it through the context menu of the debug version of Flash Player.
UPDATE: I added some details to my answer as I see the interest to the Adobe Flash Perfomance issue. I don't remember the exact acticle, but I found a lot of usefull advices on the Abode's site, now I see that the number of such articles there increased.
Also I didn't know about the Adobe Scout before, but it sounds promising. I'll definately try it soon.
I'm currently working on a dynamic MP3 player in AS3. The player will also support continuous (in length) radio streams.
Because my player will include a 'seek' bar, I allow the user to seek through the Sound object's data. Now I know that with a continuous stream, data being stored on the users RAM will never stop, as downloading will never stop on a continuous stream. This means, after a few hours of streaming, allot of RAM is being used by my app. I've tested the app on my own machine, running a very high spec, and the app crashes in my browser. When i say the app crashes, I mean the whole of Flash, meaning I have to restart my browser in order to use Flash again. I know my app is the cause as Flash has never crashed in the past. It only does it when my app has been streaming for 2+ hours.
So what I want to do is only allow the user to cache up to an hours worth of audio. After an hour, I want to clear the first half of the sound objects data, meaning that only the most recent half hours audio is stored and available for seeking.
So I have my stream:
var soundObj:Sound = new Sound();
soundObj.load(new URLRequest('stream.mp3'));
//ect ect
and sound is where the data is stored. So my question: How would I clear the first 30 mins of audio from that object?
Perhaps the Sound class is not meant to reliably play "unlimited" MP3 files, which seems to be your case. It is made to play normal MP3 "songs". Two hours of MP3 sound can easily accumulate to be larger than 200 megabytes of data.
But there is a good solution - use NetConnection and NetStream classes to stream audio instead. There are many tutorials out there. You will also be able to stream your MP3s, just a bit differently - a central server will be involved, which will transcode these MP3s on the fly, delivering it to you in a true "streaming" manner. One of such servers is Adobe Flash Media Server, an overpriced piece of work from Adobe. A lot of free and open-source alternatives exist which will work fine for your purposes - Red5, nginx-rtmp to name a few, that I have tested myself.
I'm the developer of ShellShock Live, a free online artillery game:
http://www.newgrounds.com/portal/view/564049
Everything has been running smoothly, but every once in a while for a period of 4 hours or so, hundreds of "VerifyError: Error #1026" will show up in my error log. Then, they will stop.
I looked into VerifyError and found that "The VerifyError class represents an error that occurs when a malformed or corrupted SWF file is encountered." The SWF on Newgrounds is just small loader SWF that loads the full game SWF from another site, so there must be a problem there. I'm stumped, because the game will run fine for days, and then just start getting these errors out of the blue, after no changes to either SWF.
ShellShock has hundreds of players online at any given moment, so I would like to fix this ASAP. Any help would be appreciated! Thank you!
I know the original post is a couple of years old but since I've just spent many days trying to work around a similar issue, and since this thread does not contain what I believe is the correct explanation I'll post the conclusions of my own investigation here, for anyone else to use:
The VerifyError events are almost certainly being logged because the loader SWF on NewGrounds targets a lower Flash Player version than that of the game SWF that causes this error.
The Flash Player on the user's system will accept the NewGrounds SWF loader because it targets a version equal to or lower than the version installed. After that, an external SWF that targets a higher Flash Player version can be loaded without any complaint from the Flash Player, unless it tries to access unavailable features in that Flash Player, and then it will throw the VerifyError.
The sporadic nature of this problem, in 4-hour surges, is likely related to the different penetration of later Flash Player versions in different parts of the world (and hence different time zones). During very active periods of casual gaming (weekends and evenings?) in countries with low penetration of recent Flash Player versions you will likely see batches of these VerifyErrors logged.
The bad news is that after many days of trying to find a workaround for this very problem we have been unable to find any way to catch the VerifyError. It does not even get caught by an UncaughtErrorEvent handler!
The only thing I can suggest that might help in your case (not mine, unfortunately) is to determine the target version of the NewGrounds loader SWF (check the 4th byte in the SWF) then do one of the following :
Compile your game to target the same version of Flash Player as the loader targets. That way you can be sure that if the NewGrounds loader SWF is successfully loaded into the user's Flash Player your SWF will also work in that version without problem, or
In the initialization code of your game, check the Capabilities.version to determine the Flash Player version installed on the user's system and use that to branch control so that advanced Flash Player features are only used in appropriate Flash Player versions.
In my case I have access to the loader code, but not the code of the thousands of SWFs it loads. Since the external SWFs are stenciled into copies of the loader SWF as ByteArrays I can check the SWF's Flash Player target version byte (byteArray[3]), and compare it to the installed Flash Player 'major.minor' version obtain from Capabilities.version, but since SWF Flash Player target version bytes are (currently) incremented with every minor version increment of the Flash Player, it is impossible to map the SWF target byte (byteArray[3]) to future Flash Player 'major.minor' versions, until we know what the maximum minor version number of the current Flash Player will be.
Hope anyone else encountering this will have better luck than we did.
I think it may be a flash player error, try disabling any graphics acceleration or caching. It may be helpful to figure our what graphic card they are using.
Have you made changes to your socket server? Are you using like smarfoxserver?
I had this error in a very small project with cs3 flash9. So I was able to track this error down.
NOTE: this error is emitted incorrectly. The reason the error was emitted in my project was NOT because of a faulty swf because I do not import any swf into my project.
REASON:
I had a code line written like this:
_mc.my_counter && _mc.my_counter--;
SOLUTION:
I changed the line to this:
if(_mc.my_counter) _mc.my_counter--;
... and the verify error message was gone as fast as it appeared. Looks like this is a real as3 bug.