慢动作视频不能播放问题

问题原因分析:

这个问题的原因是audiotrack的setPlaybackRate函数调用isSampleRateSpeedAllowed_l去判断采样率是否满足需要的最小值，通过跟log发现计算出来的最小值（minFrameCount）大于mFrameCount，而mFrameCount是获取audio hal层的一个latency去计算sample rate，这个播放在hal层走的是offload模式。这个模式获取到的latency有问题导致framework计算出来的sample rate小于hal层所需要的最小值。一个修改方案是把vendor.audio.offload.track.enable这个prop改为false，也就是不走pcm的offload模式，走deep-buffer模式。这样获取的latency就是正确的，也就能解决这个问题。但是也会有影响，就是改变播放的这个流程。还有一种修改就是更改hal层的latency值，这个latency通过跟代码发现是hardware/qcom/audio/hal/audio_extn/utils.c中的PCM_OFFLOAD_PLAYBACK_LATENCY的值，而这个值又是通过PCM_OFFLOAD_BUFFER_DURATION计算得来，问题就在于8974的芯片这个值是80，而8916是40。也就解释了sdm632的手机没有问题但是sdm710的手机有问题。
对比htc手机默认走的就是deep-buffer，通过查代码发现当有第三方音效存在的情况下就不走offload模式（htc集成了Nokia音效）。查看播放模式的代码是AudioPolicyManager的getOutputForAttr开始，最后跟踪到

if ((*flags & (AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD|AUDIO_OUTPUT_FLAG_DIRECT)) &&
                ((*flags & AUDIO_OUTPUT_FLAG_VOIP_RX) ? 0 : mEffects.isNonOffloadableEffectEnabled() || mMasterMono)) {
        ALOGD("non offloadable effect is enabled, try with non direct output");
        goto non_direct_output;
    }

修改方案是involid掉track后回重新创建一个新的deep-buffer track

diff --git a/media/libaudioclient/AudioTrack.cpp b/media/libaudioclient/AudioTrack.cpp
index b0cb83a..380c047 100644
--- a/media/libaudioclient/AudioTrack.cpp
+++ b/media/libaudioclient/AudioTrack.cpp
@@ -1064,7 +1064,9 @@ status_t AudioTrack::setPlaybackRate(const AudioPlaybackRate &playbackRate)
     if (!isSampleRateSpeedAllowed_l(effectiveRate, effectiveSpeed)) {
         ALOGW("setPlaybackRate(%f, %f) failed (buffer size)",
                 playbackRate.mSpeed, playbackRate.mPitch);
- return BAD_VALUE;
+ //return BAD_VALUE;
+ ALOGD("extra code: invalidate track-offloaded track on setPlaybackRate");
+ android_atomic_or(CBLK_INVALID, &mCblk->mFlags);
     }