I have 4 wav files all designed to be played at the same time. I have created the 4 sound buffers and play them with the start function. All 4 sounds are played successfully but they are slightly out of sync with each other. I guess each call to start takes long enough for the subsequent call to be out of sync. Is there anyway I can force them to sync?
Thanks
Without seeing you code, these are the spontaneous ideas I have. Make sure to check the following:
Give the exact same start time to the start method (maybe save context.currentTime + a little bit in a var and pass it to the start method of each source node, don't pass context.currentTime to each source in a for loop or similar (the context time might update while that's executing, thus the time passed to each source is different)).
Make sure that the audio files are cut exactly the same in the beginning of the file. If you have 10 ms extra silence in one of the files, that file will always be 10ms off (unless you compensate for it in the code).
If none of that works/applies, please add some code to your question explaining what you're doing right now.
I use several Sound.loop , Sound.stop methods on one particular OGG file when I start and stop a level . It works fine for a while but as time advances it sometimes fails and I don't hear the sound anymore. LOGCAT:
AudioFlinger could not create track, status: -12
Error creating AudioTrack
It only happens on an older phone. How can I reset the sound memory system (sound pool) each time I restart the level so this doesn't happen?
I saved the ogg files to the minimum memory capacity in Audacity so I don't think this is the pb.
I had the exact same issue. My workaround was to use the Music class instead of Sound.
To initialize it:
Music note = Gdx.audio.newMusic(Gdx.files.internal("sounds/myfile.wav"));
note.setLooping(true);
Then just call .play() and .stop() as needed on the instance. Remember to call .dispose() when you no longer need it.
This worked for me and has the same practical effect than .loop() in a Sound instance.
I need to detect if video file is valid(and delete it if it is not). It is an air application.
For large files it can be accomplished by processing MediaPlayerState.PLAYBACK_ERROR state. No problems.
However, when there's an empty file like empty.mp4, it does not dispatch any PLAYBACK_ERROR.
Then I created a file singleChar.mp4 (with x letter inside), the behavior was exactly the same.
It goes through READY state without any problems. playing is true at that time (it is said in the documentation that it is true when it is playing or attempting to play, so this is also not reliable).
Then I suggested that it treats those files as valid ones with duration=0... No! Duration is not set, durationChange is not dispatched.
The best approach for now is to play() it, setTimeout for about 50ms and check duration when this timeout expires. At least it works in 50% cases. However, this is completely unreliable. Reliability may be improved by extending the delay, but I'd prefer to detect it quickly and handle silently before user will notice any problems.
Other possible approach is to check if the file is less than some size(maybe,100KB?), however, this is also another stupid unreliable approach.
So, is there a reliable way to detect if a file is a valid video file?
I would like to be able to
create a folder for the copied video frames
access the individual frames frome a .flv video file and/or .swf file
save these frames to the auto-created folder
I assume one would need to do this using Action Script 3 to scan through the .swf and .flv files and extract the frames.
Are there gudies on how to do this?
You need to know WHAT frames do you want to extract. For example:
extract 20 frames in regular interval from the video clip
extract frames at 15 seconds interval
extract frames at keyframes (scene changes)
I guess that you don't have to use as3 to extract frames, but can also create the script in some other language. Central piece to frame extraction could be ffmpeg, as described in this article.
If it is as3 solution i would do following
- make a loader which loads your fla/flv
- add enter frame event listener to it and on each frame draw loader object to buffer, if you ever done any loading and drawing, this will probably take you 10-20 minutes to set up.
This is pretty much the only straigt-forward solution if you're dealing with code-based animations, videos can be handled in different and easier ways i guess.
You will face the challenge of saving the output tho. Flash player can save images on your computer, however only by prompting you to save the file. You will need to use functions available only in Air player if you want to save anything without prompts.
My website is entirely flash based, it moves around a 3D model which was given to me as chunks of video that I've converted to FLV files. I'm using the FLVPlayback component to control the video inside of my program. While running memory checks using System.totalMemory I've noticed that whenever a video is loaded, it will eat up a chunk of memory and even when I remove all the event listeners from it(they are all weakly referenced), remove the component from its parent, stop the video and null the component instance, it still will not give that memory back.
This has been bothering me since I started working on this project because of the huge amount of video a user can potentially instantiate and load. Currently every video is loaded into a new FLVPlayback instance whenever it is required, but I have read that perhaps the best way to go about this problem is to simply have a global FLVPlayback instance and just reload the new video into the old instance, that way there would only be one FLVPlayback component in the application's memory.
Has anyone else run into this problem as well? Have you found a better solution than using a global instance that you just re-use for every new video?
I've never really liked the components, they're a bit dodgy. This particular problem seems to be common, and the somewhat annoying solution is, as you're suggesting, to only have one FLVPlayback and reuse that.
Here's a blog post about it
You can't help the memory problems much until Flash adds destructors and explicit object deletion, unfortunately. See this thread:
Unloading a ByteArray in Actionscript 3
There's a limit to how much memory Flash applets can use; the GC seems to fire upon reaching that limit. I've seen my memory-easy applets use as much as ~200MB, just because they run for hours on end and the GC doesn't want to kick in.
Oh, and I don't think using a single instance is an elegant solution, either. Currently I just write a dispose() function for my custom classes, waiting for some day when it can be turned into a proper destructor.
From what I gather after a lot of testing is that flash dynamically loads in libraries and components as needed but never garbage collects that data. For instance, if I have a website or an Air app that uses the FLVPlayback component, the actual component and libraries associated with it aren't loaded until a new FLVPlayback() instance is created. It will then load in the library and component into memory but you will never get that space back until the program / website is closed. That specific instance with the video inside of it will get garbage collected and release some memory as long as you remove listeners from it, take it off the stage, and set it to null.
Also, if you are doing individual videos, the VideoPlayer is much lighter weight, and cleans up nicer.
Thanks for the responses, the links to the other blog questions were helpful as well, I had read all of Grant Skinner's info on garbage collection too, but searching through those links and going back and re-reading what he had originally said about GC helped refresh the old noggin. In addition to nulling and re-instantiating that single FLVPlayback component, I also realized that I wasn't correctly unloading and destroying my Loader instances either, so I got them cleaned up and now the program is running much more efficiently. I would say the memory usage has improved by around 90% for the site.
#aib I will admit the single instance solution isn't elegant, but because flash just won't let go of those FLV files, I'm kind of stuck with it.
#grapefrukt I detest the flash components, they typically cause more grief than time saved, however in this case I had a lot of cue points and navigation stuff going on with the video files and the FLVPlayback component was the best solution I found. Of course I'm still fairly new to the ActionScript world so perhaps I over-looked something.
Unfortuantely, thats just the way flash handles it. Not particularly smart, but it works for most people.