Re: AudioQueueProcessingTap causes skipping when screen turns off (iOS)
Re: AudioQueueProcessingTap causes skipping when screen turns off (iOS)
- Subject: Re: AudioQueueProcessingTap causes skipping when screen turns off (iOS)
- From: Martin Man <email@hidden>
- Date: Mon, 08 Oct 2018 13:12:39 +0200
Hi Tomas,
Never tried with the tap, but make sure to properly configure the maximum
number of frames per slice to support any audio stuff when screen is locked.
Here is the excerpt from the docs, google for the property to find more
> By default, the kAudioUnitProperty_MaximumFramesPerSlice property is set to a
> value of 1024, which is not sufficient when the screen locks and the display
> sleeps. If your app plays audio with the screen locked, you must increase the
> value of this property unless audio input is active. Do as follows:
>
> • If audio input is active, you do not need to set a value for the
> kAudioUnitProperty_MaximumFramesPerSlice property.
>
> • If audio input is not active, set this property to a value of 4096.
Hope it helps,
Martin
> On 7 Oct 2018, at 22:51, Tamás Zahola <email@hidden> wrote:
>
> Hi,
>
> I have an iOS audio player app built on Audio Queue Services [1], that
> incorporates an equalizer using the n-band EQ from AudioToolbox
> (kAudioUnitSubType_NBandEQ).
>
> I’ve received complaints about playback starting to stutter for certain files
> when the device is locked (or if the screen turns off automatically). First I
> thought the stuttering was caused by doing something inappropriate in the
> processing tap’s real-time callback, but I couldn’t find anything suspicious…
> Also, I’ve found that the stuttering/skipping occurs ONLY if the following
> hold:
>
> - the AudioQueue is configured with a sample rate of 48khz
> - the audio is playing through headphones
> - the screen is off/locked
>
> After further experiments, it turned out that it doesn’t matter what I do in
> the processing tap’s callback, the problem persists even if the processing
> tap is the „empty":
>
> static void ProcessingTapCallback(void * inClientData,
> AudioQueueProcessingTapRef inAQTap,
> UInt32 inNumberFrames,
> AudioTimeStamp * ioTimeStamp,
> AudioQueueProcessingTapFlags * ioFlags,
> UInt32 * outNumberFrames,
> AudioBufferList * ioData) {
> OSStatus status = AudioQueueProcessingTapGetSourceAudio(inAQTap,
> inNumberFrames, ioTimeStamp, ioFlags, outNumberFrames, ioData);
> NSCAssert(status == noErr && inNumberFrames == *outNumberFrames, @"%d vs
> %d", (int)inNumberFrames, (int)*outNumberFrames);
> }
>
> The assert on the last line never fails, so the buffer should always be
> completely filled. (inNumberFrames is 4096 by the way)
>
> I’ve found an old QA writeup [2] that discusses AUGraph behaviour when the
> screen is locked: the system increases the "maximum frames per slice”
> property to 88ms (4096 samples at 44.1khz). However, the maximum frames per
> slice returned by AudioQueueProcessingTapNew is already 4096, so there should
> be no mismatch here…
>
> I’ve created a minimal demonstration project here:
> https://github.com/tzahola/AudioQueueProcessingTapSample
> <https://github.com/tzahola/AudioQueueProcessingTapSample>
> By default it plays a 48khz AIFF file, which will stutter if the screen is
> off and you're using headphones. If you unlock the device, or unplug the
> headphones, or change „piano_48k” to „piano_44.1k” (in ViewController.mm),
> then there will be no stutter… (needless to say, it works perfectly without
> the processing tap, too)
>
> Can anybody shed some light on why this might be happening, and how to
> circumvent it? The documentation on Audio Queue processing taps is a bit
> scarce...
>
> [1]
> https://developer.apple.com/documentation/audiotoolbox/audio_queue_services
> <https://developer.apple.com/documentation/audiotoolbox/audio_queue_services>
> [2] https://developer.apple.com/library/archive/qa/qa1606/_index.html
> <https://developer.apple.com/library/archive/qa/qa1606/_index.html>
>
> Best regards,
> Tamás Zahola
> _______________________________________________
> 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
_______________________________________________
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