I'm using a ScriptProcessorNode in order to record audio from a MediaStream/MediaStreamNode. Any time a UI operation blocks the main thread a little bit (like drawing on a canvas), the audio result is jittery at those specific moments.
It seems like AudioWorker is eventually going to be implemented, which I think would solve my problem, but as of now, what is the solution?
Cheers!
Use MediaRecorder API to record rather than ScriptProcessor, is my only advice.
Related
A.
First of all, I'm using FMOD v. 1.10.02 w/ Resonance Audio.
When using the Soundfield in FMOD I get weird beeps and squeaky noises when rotating my HMD. I've put the R.A. Soundfield effect on the master of an event and the Resonance Audio Listener on the Group master of my ambisonics.
This makes the Soundfield effect unusable and therefor - no ambisonics for me :( Is this only happening for me?
Best regards,
Frederik
OK, so I found out that the Soundfield behaves weird when the audiofile has a lot of low frequencies, removing some of them with an eq did the trick and the small beeps is now gone. Instead of removing this post, I'll leave it here - maybe this can be helpful for others ;)
I'm looking for help with a performance issue in an Objective-C based iOS app.
I have an iOS application that captures the screen's contents using CALayer's renderInContext method. It attempts to capture enough screen frames to create a video using AVFoundation. The screen recording is then combined with other elements for research purposes on usability. While the screen is being captured, the app may also be displaying the contents of a UIWebView, going out over the network to fetch data, etc... The content of the Web view is not under my control - it is arbitrary content from the Web.
This setup is working but as you might imagine, it's not buttery smooth. Since the layer must be rendered on the main thread, there's more UI contention than I'd like. What I'd like to do is to have a setup where the responsiveness of the UI is prioritized over the screen capture. For instance, if the user is scrolling the Web view, I'd rather drop frames on the recording than have a terrible scrolling experience.
I've experimented with several techniques, from dispatch_source coalescing to submitting the frame capture requests as blocks to the main queue to CADisplayLink. So far they all seem to perform about the same. The frame capture is currently being triggered in the drawRect of the screen's main view.
What I'm asking here is: given the above, what techniques would you suggest I try to achieve my goals? I realize the answer may be that there is no great answer... but I'd like to try anything, however wacky it might sound.
NOTE: Whatever techniques need to be App Store friendly. Can't use something like the CoreSurface hack that Display Recorder used/uses.
Thanks for your help!
"Since the layer must be rendered on the main thread" this is not true, as long as you don't touch UIKit.
Please see https://stackoverflow.com/a/12844171/136305
Maybe you can record at half resolution to speed up things, if that fits the requirements?
Can any one help me to seek at particular time in AVQueuePlayer?
I have use this controller to play video in iPhone because i need to play two video at the same time.
But my problem is to navigate in video and jump to at particular time, I am not able to do that.
I Know the method the That is [controller seekToTime:(CMTime)] But it is not moving the video at exact position of the video.
Does any one know the solution?
This is stated in the documentation for seekToTime::
The time seeked to may differ from the specified time for efficiency. For sample accurate seeking see seekToTime:toleranceBefore:toleranceAfter:.
So try using seekToTime:toleranceBefore:toleranceAfter: instead, specifying a low or zero tolerance. You may also want to specify true for AVURLAssetPreferPreciseDurationAndTimingKey when creating any AVURLAssets you may be using.
Update... I ended up doing hackery and not being especially pleased with the results--the snap-through-black between movies may or may not show, and because I was bad and didn't inquire as to the load status etc it's possible to get many things confused.
But for straight looping an AVQueuePlayer assetItem it works to set a boundaryTime observer and use that to rewind the assetItem. My stuff is only a few seconds long so the seekToTime is pretty seamless, I don't know what it'll do seeking on a longer asset. looping an assetItem in AVQueuePlayer
Is that an very cost-intensive function that sucky my performance away under my feet? I guess they used that one for the waggling buttons on the home screen + core animation. I just want to know before I start wasting my time ;)
Seems unlikely that it'd be much of a performance problem - it works out to something like a Cosine, a Sine, and a few multiplications. Don't call it thousands of times a second, and you'll be fine.
Very (very) little. This is also something you can easily measure yourself; see the following URLs for examples/information on implementing high-resolution timing:
http://developer.apple.com/qa/qa2004/qa1398.html
http://code.google.com/p/plinstrument/source/browse/trunk/Source/PLInstrumentTime.h
http://code.google.com/p/plinstrument/source/browse/trunk/Source/PLInstrumentTime.m
http://code.google.com/p/plinstrument/
Like with everything, it depends on how and how much you use it. It's used all the time in game development, which the iPhone is very well suited for. CoreAnimation is also very fast. If you're worried about it, my suggestion is to take one of the Apple-provided sample apps and run it through Instruments to preform some of your own benchmarks to see if they are acceptable for your needs.
All CGAffineTransformMakeRotation() does is fill in the matrix for a regular old CGAffineTransform. If you think you can fill (or pre-fill) the matrix faster yourself, then go for it (I'd be really surprised if this wasn't super-optimized already).
Then when it comes time to do the actual work of applying the transform, I'm pretty sure the GPU is told to take care of it so it'll run fast and your main CPU shouldn't take too much of a hit.
If you're really worried about it, then do the transforms in 2D space on top of OpenGL to make sure it's hardware optimized.
I just want to know before I start wasting my time
Optimise the system not the individual lines. Who knows how many times your code will call the transform. Better to get the whole system working, profile it and then optimise the parts that are too slow.
Don't worry about individual calls that people tell you are slow. Use this information as a pointer if your code is slow but always see how the operate in your code.
I'm programming an puzzle game for iPhone using openGL.
There Is one very weird "bug" ( I'm not sure what It is)... whenever I touch the screen a great number of times in a short period of time my app closes, without giving a warning or error.
What could be the cause ?, I guess It has something to do with the memory, but I would like to know.
Edit:
I also think this happens because I'm calling multiple functions every time the user touches the screen or moves his fingers.
Sounds like you're running out of memory.
A few quick tips that might help out:
Check your memory profile over time using Instruments. If you see a steady incline over time, it's likely to be a memory leak, or an inefficient algorithm that is allocating more memory than you need.
Use a static analyzer to help check for leaks, such as Clang.
Images and image-related files are particularly memory-hungry, so focus on efficiency for them. When you work with textures in OpenGL, use the PVRTC format, which offers awesome compression.
didReceiveMemoryWarning: is your friend - aka a good chance to throw out anything you don't absolutely need in memory. Better to be memory-efficient the whole time, though.
Try setting up an NSUncaughtExceptionHandler. You may also want to setup a signal handler.