Remove timing jitter during startup of audio
This fixes a regression introduced recently, that increased timing jitter
during the startup of the FastMixer and AudioTrack callback threads.
The regression was to make requestPriority() asynchronous as a way to
avoid an apparent priority inversion in system_server. This means that
the target thread could run briefly with the initial priority, before
the new priority takes effect.
This change removes the startup jitter for FastMixer, by making the
requestPriority() synchronous again for that case. It doesn't matter
that this restores the priority inversion involving normal mixer thread,
because it happens during startup of both threads.
The change also removes the startup jitter for the AudioTrack callback
thread, by having the target thread check whether the requestPriority()
has completed yet. If not, the target thread blocks with a timeout
until the priority boost finishes.
Finally, we now log an error message if the expected priority boost
doesn't happen.
Bug: 8698989
Change-Id: Id590e9a274b70ec1ba85b44a585ee37a22e41cbc
diff --git a/services/audioflinger/SchedulingPolicyService.cpp b/services/audioflinger/SchedulingPolicyService.cpp
index 59cc99a..36e62e9 100644
--- a/services/audioflinger/SchedulingPolicyService.cpp
+++ b/services/audioflinger/SchedulingPolicyService.cpp
@@ -25,7 +25,7 @@
static const String16 _scheduling_policy("scheduling_policy");
static Mutex sMutex;
-int requestPriority(pid_t pid, pid_t tid, int32_t prio)
+int requestPriority(pid_t pid, pid_t tid, int32_t prio, bool asynchronous)
{
// FIXME merge duplicated code related to service lookup, caching, and error recovery
sp<ISchedulingPolicyService> sps;
@@ -46,7 +46,7 @@
}
sleep(1);
}
- return sps->requestPriority(pid, tid, prio);
+ return sps->requestPriority(pid, tid, prio, asynchronous);
}
} // namespace android