AudioQueueProcessingTap causes skipping when screen turns off (iOS)
AudioQueueProcessingTap causes skipping when screen turns off (iOS)
- Subject: AudioQueueProcessingTap causes skipping when screen turns off (iOS)
- From: Tamás Zahola <email@hidden>
- Date: Sun, 07 Oct 2018 22:51:39 +0200
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