Does it load the entire file at a time? Or does it act lazy and load a chunk at a time? I'm primarily interested in knowing how much memory my audio uses.
From what I understand of it, it buffers the file and you can have even more control over this process by using Audio Queues. Most implementations of OpenAL will load the entire file all at once which can be pretty intensive.
You can pre-buffer using prepareToPlay but honestly, I've never had any noticeable lag using wav's, caff's or mp4's. Calling the play method has to pre-buffer the audio anyways.
In all of my uses of AVAudioPlayer, it normally only causes a temporary jump in memory allocation. As long as you release the player after it is finished, memory isn't a problem. I've played as many as 15 sounds at once and never had issue.
More info on audio: http://developer.apple.com/iphone/library/documentation/iphone/conceptual/iphoneosprogrammingguide/AudioandVideoTechnologies/AudioandVideoTechnologies.html
Related
I want to play very long audio files of up to an hour. AVAudioPlayer seems to be the easiest solution. But is it also efficient or does it load the whole file into memory before playing?
Apple's doc for AVAudioPlayer say:
An instance of the AVAudioPlayer class, called an audio player,
provides playback of audio data from a file or memory.
Applerecommends that you use this class for audio playback unless you are
playing audio captured from a network stream or require very low I/O
latency.
I'm making a game for iOS platform and i want to use openAL for playing audio effects in the game (except the background music). I want to have for example 20-30 sounds with duration of 1-3 seconds each. Because i want these sounds to be played with no delay i have to load from file, decompress and store in the memory. But decompressed audio (as i understand) uses a lot of memory. So am I on the right way? Or there is another way ? Thanks
Loading sounds does incur a delay, and can cause the rest of the app to jitter. For best performance you definitely want to preload sound effects.
Memory use is a concern, but as long as you're not loading too much audio data into memory at a time, you'll be OK.
44KHz mono audio data will occupy 88,000 bytes per second when uncompressed. Stereo is double that, but usually for sound effects you don't want stereo anyway. So if you had 30 sounds loaded, each of 3 second duration, you'd have 90 seconds of sound using 7.5MB of memory. You can of course halve that memory usage by using a 22050 Hz source before compressing it to AAC (which preserves the source sample rate).
What I do is maintain a cache of audio buffers that I can flush when the app starts to use too much memory like so: https://github.com/kstenerud/ObjectAL-for-iPhone/blob/master/ObjectAL/ObjectAL/OALSimpleAudio.m#L441
For the lowest latency sound effects, you will want to play uncompressed audio already in memory. 2 or 3 MBytes is not a lot of memory to allocate for low latency sound effects.
I am developing a game for the iPhone and iPad using cocos2d, and I need to be able to play a sound exactly when another one completes.
I have a soundtrack that is chopped up in smaller pieces, and there are no room for the tinyest gap between playback when one finishes and one starts.
Btw. I cannot glue the sounds together into a single file and just play that since the order of the files will be rearranged runtime.
How can I achieve this?
With CocosDenshion you can register a delegate with
[[CDAudioManager sharedManager] setBackgroundMusicCompletionListener:self
selector:#selector(musicDidFinish)];
CDAudioManager class reference
This delegate will be called whenever the background music ends. This of course only works if you play your sound files as background music (with the playBackgroundMusic method).
If that doesn't work for you, have a look at ObjectAL. You'll have more options and greater flexibility. For example, with ALSource you can queue multiple ALBuffer objects which represent sound files. That means whenever the source's buffer count decreases to 1 you just queue the next buffer to achieve uninterrupted, sequential playback of multiple sound files (any format).
Because ObjectAL is so awesome (well, I think so :) ) it's included and ready to use in Kobold2D.
You can use a single Audio Queue or the RemoteIO Audio Unit, and just fill the callback buffers with raw/PCM audio samples from any file in any order.
I need to play sounds (~5 seconds each) throughout my iphone application. When they're triggered, they need to play immediately.
For the moment I'm using AudioServices and (as you probably know) the first time you play a sound it lags, then every time there after it's perfect. Is there some code available that's clever enough to preload an AudioServices sound (by playing it silently maybe?). I've read adjusting the system volume programmatically will get your app rejected, so that's not an option. Seems AudioServices isn't made for volume correction from what I can see.
I've looked into OpenAL and while feasible seems a little over kill. AVAudioPlayer seems like a little bit of a better option, I'm using that for background music at present. Extending my music player to handle a 'sound board' might be my last resort.
On the topic of OpenAL, does anyone know of a place with a decent (app store friendly) OpenAL wrapper for the iPhone?
Thanks in advance
Finch could be perfect for you. It’s a tiny wrapper around OpenAL with very low latency and simple API. See also all SO questions tagged ‘Finch’.
If you use an AVAudioPlayer, you can call prepareToPlay when you initialize the object to reduce the delay between calling play and having the audio start.
I'm working on a project which is using Audio Toolbox for recording and playback of PCM data, and I'm having trouble with playback. In the simulator, I can record and play audio just fine, using a custom class to handle storing and sourcing PCM bytes for the recording and playback buffers as needed. On device (iPhone (3.0.1) and iPod 2G (3.1.2)) recording works fine, the audio files produced are correct, but in-app playback stutters, like it's only playing part of each playback buffer. My buffers are one second long, and I've got 3 buffers, which are preloaded before playback starts; stuttering occurs during those first 3 seconds as well, which I think rules out a latency problem.
I've written Audio Toolbox code before that worked, and I'm not doing anything strange here except that I'm using my own class to source PCM data instead of AudioFileReadBytes()
I know the data that comes out of my source is good, because it plays right in the sim, and it writes to disk as a correct audio file
I've played around with sample rates a bit; I'm normally using 11025Hz sampling to cut down on file size (it's all voice, so it sounds fine). at 44100Hz, but with the same size of buffers, I get the same stuttering problem, but the audio segments come a lot faster, about 4 times faster. That's why I think it's only playing part of each buffer.
The only reason I can conceive that it would only play part of each buffer is a latency problem... like the audio toolbox code is running out of full buffers while I'm still filling an empty one. But that would cause it to play the preloaded buffers correctly, and then start stuttering, and that doesn't happen, it stutters the whole way through
I've tried humongous buffers, like 10MB buffers, and I just get silence and a single stutter of audio at the end of playback. I've also tried preloading more buffers than normal, like 10 seconds worth of audio, and it behaves the same.
The audio session is being set with AVAudioSession, not the Audio Toolbox calls, and it's being set to the Playback category for playback
I have no idea how to try and attack this problem, it makes no sense to me that it works fine on the simulator but not the device.
Code for the playing callback and the set up for the audio queue services: http://pastebin.com/mfaa546c
It turns out that the use of NSData's GetBytes:length: was causing the problem. The buffer filled with that method was playing incorrectly. However, doing a memcpy from that buffer to another buffer would prevent the problem.