Re: iPhone - RenderCallback not called when phone is locked
Re: iPhone - RenderCallback not called when phone is locked
- Subject: Re: iPhone - RenderCallback not called when phone is locked
- From: William Stewart <email@hidden>
- Date: Wed, 2 Dec 2009 14:45:06 -0800
Actually, the remoteIO is actually set up for the right size already, so the correction here is that the other audio units are actually the problem (just to be clear)
Glad we figured this out :)
Bill
On Dec 2, 2009, at 2:08 PM, John Morris wrote:
> Great! I have set the MaxFramesPerSlice property for the AURIO and mixer and it is working fine under screen lock now.
>
> Thanks!
>
> John Morris
> Evolution Interactive
>
> On Dec 2, 2009, at 1:37 PM, William Stewart wrote:
>
>> Ok, so we have tracked this down.
>>
>> With just output when the screen goes dark (what we call screen lock), the I/O size for the audio is changed from 22msec (1024 @ 44.1kHz) to 88msec (4096 samples @ 44.1kHz). We do this to conserve power (makes a difference to battery longevity) and there is no need for a more responsive, lower latency I/O because there is no user interaction with the screen locked.
>>
>> When we have input running we do NOT change the I/O size because that would cause a glitch in the input.
>>
>> Now, the bug is being caused by the fact that the remote I/O (and any other audio units you are using) have not been set up to deal with an I/O of 4K samples, so the request comes in to the remote I/O to provide 4K samples, and it returns an error, because its MaxFrames setting is less than that.
>>
>> You can easily fix this by making sure that ANY audio units you are using in this scenario are setting the MaxFramesPerSlice property to deal with a request for 4096 samples. That will fix the problem.
>>
>> Now, the default setting is set up for working in a "normal use case" (which the 1024 default is). As this property is used to determine allocations of internal buffers, my inclination is NOT to change his setting, but rather to have clients that are going to use audio units in this scenario, change this themselves. That way we don't allocate memory that is not needed.
>>
>> We'll also generate a tech note for this to explain it
>>
>> Thanks
>>
>> Bill
>>
>> On Nov 25, 2009, at 2:19 PM, email@hidden wrote:
>>
>>> Johns test project was targetting O.S 2.2.1, i have the same issue on O.S. 3.0 with the MediaPlayback category.
>>> however with the PlayAndRecord everything is fine.
>>>
>>> aran
>>>
>>> On , William Stewart <email@hidden> wrote:
>>>> MediaPlayback should do this as well and in our test cases it does. We are still investigating why John's case is failing.
>>>>
>>>>
>>>>
>>>> Play and Record is fine, but if you aren't doing input, you shouldn't use this category, media playback is what you should use
>>>>
>>>>
>>>>
>>>> Bill
>>>>
>>>>
>>>>
>>>> On Nov 25, 2009, at 8:36 AM, Wil Macaulay wrote:
>>>>
>>>>
>>>>
>>>>
>>>> The PlayAndRecord category does what you want.
>>>>
>>>>
>>>>
>>>> wil
>>>>
>>>>
>>>>
>>>> On Wed, Nov 25, 2009 at 11:34 AM, John Morris
>>>>
>>>> email@hidden> wrote:
>>>>
>>>>
>>>> Yeah, it is pretty easy to have it pause when the phone is locked. The trick I am trying to accomplish is having the sound continue to play while the iphone is locked. With the MediaPlayback category, you are supposed to be able to continue playing while the device is locked. But for some reason, when the device is locked, the AURenderCallback stops being called. I filed a bug on it (radar #7408577).
>>>>
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>> On Nov 25, 2009, at 2:42 AM, Aran Mulholland wrote:
>>>>
>>>>
>>>>
>>>>
>>>> hey john,
>>>>
>>>>
>>>>
>>>> had the same issue as you today so i got out your project and fixed it
>>>>
>>>> there. nice to work in a simple test case.
>>>>
>>>>
>>>>
>>>> how i worked around it was to start the audio with
>>>>
>>>> AudioOutputUnitStart(au_output); from the
>>>>
>>>>
>>>>
>>>> - (void) applicationDidBecomeActive:(UIApplication *)application method
>>>>
>>>>
>>>>
>>>> and stop it in the with AudioOutputUnitStop(au_output); in the
>>>>
>>>>
>>>>
>>>> - (void) applicationWillResignActive:(UIApplication *)application
>>>>
>>>>
>>>>
>>>> this way whenever the app becomes disabled due to lock the audio
>>>>
>>>> render stops and when it gets unlocked it begins playing again.
>>>>
>>>> In my other project i use AUGraphStop(graph); and AUGraphStart(graph);
>>>>
>>>> in a similiar fashion.
>>>>
>>>>
>>>>
>>>> dont know if this is the official party line, but it works for me
>>>>
>>>>
>>>>
>>>> Aran
>>>>
>>>>
>>>>
>>>> On Thu, Nov 19, 2009 at 8:17 AM, John Morris
>>>>
>>>> email@hidden> wrote:
>>>>
>>>>
>>>> Hmmm....I hacked up my code and inserted it into a new project (the OpenGL ES template). Same behavior. The meat and potatoes are in a file called audio.cpp.
>>>>
>>>>
>>>>
>>>> You can grab the test project here:
>>>>
>>>> http://evolutioninteractive.com/stuff/audiotest.zip>
>>>>
>>>>
>>>>
>>>> Someone mentioned that they saw similar issues related to doing too much work, so this test just outputs silence (a simple memset() with the kAudioUnitRenderAction_OutputIsSilence hint).
>>>>
>>>>
>>>>
>>>> So, what this app does is just dump a "." out to the console for each call into the RenderCallback. When you start up the app, it will start with the debug output (making big strings of periods). When you hit the lock button, the output will stop. When you unlock it, it will start up again. This is the crux of the problem. When the device locks, the sound keeps playing, but the RenderCallback isn't called to refresh the buffer, so it just keeps playing the same (last filled) buffer over and over. And this is with the category set to MediaPlayback.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> John Morris
>>>>
>>>> Evolution Interactive
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Nov 17, 2009, at 4:21 PM, John Morris wrote:
>>>>
>>>>
>>>>
>>>>
>>>> Hmmm....I hacked up my code and inserted it into a new project (the OpenGL ES template). Same behavior. I attached the test project. The meat and potatoes are in a file called audio.cpp.
>>>>
>>>>
>>>>
>>>> Someone mentioned that they saw similar issues related to doing too much work, so this sample just outputs silence (a simple memset() with the kAudioUnitRenderAction_OutputIsSilence hint).
>>>>
>>>>
>>>>
>>>> So, what this app does is just dump a "." out to the console for call into the RenderCallback. When you start up the app, it will start with the debug output (making big strings of periods). When you hit the lock button, the output will stop. When you unlock it, it will start up again. This is the crux of the problem. When the device locks, the sound keeps playing, but the RenderCallback isn't called to refresh the buffer, so it just keeps playing the same (last filled) buffer over and over. And this is with the category set to MediaPlayback.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> John Morris
>>>>
>>>> Evolution Interactive
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden