蓝牙音乐和导航语音播放混音卡顿问题

最近发现公司自研的智能车载设备上存在一个问题：手机通过蓝牙连接车机，在手机上播放音乐车机上发声然后跟车机上的导航语音播报一起混音播出的时候会出现卡顿的现象；但是在车机上播放音乐和导航混音就正常。另外需要说明的是播放音乐使用的是Music流，导航使用的是Alarm流

通过 adb shell dumpsys media.audio_flinger 工具对比查看两种场景下实时的音频流信息（截取其中一个回放线程中的音频流信息如下）：

Output thread 0xe6c833c0 type 0 (MIXER):
  Thread name: AudioOut_1D
  I/O handle: 29
  TID: 935
  Standby: yes
  Sample rate: 48000 Hz
  HAL frame count: 1920
  HAL format: 0x1 (pcm16)
  HAL buffer size: 7680 bytes
  Channel count: 2
  Channel mask: 0x00000003 (front-left, front-right)
  Processing format: 0x1 (pcm16)
  Processing frame size: 4 bytes
  Pending config events: none
  Output device: 0x20000 (LINE)
  Input device: 0 (NONE)
  Audio source: 0 (default)
  Normal frame count: 1920
  Last write occurred (msecs): 1087537
  Total writes: 4905
  Delayed writes: 0
  Blocked in write: no
  Suspend count: 0
  Sink buffer : 0xe73da000
  Mixer buffer: 0xe83d8000
  Effect buffer: 0xe73dc000
  Fast track availMask=0xfe
  Standby delay ns=3000000000
  AudioStreamOut: 0xe83c82a0 flags 0x8 (DEEP_BUFFER)
  Frames written: 9417600
  Suspended frames: 0
  Hal stream dump:
  Thread throttle time (msecs): 106
  AudioMixer tracks: 0x00000003
  Master mono: off
  FastMixer not initialized
  Stream volumes in dB: 0:-11, 1:-10, 2:-10, 3:0, 4:-10, 5:-10, 6:0, 7:-10, 8:-10, 9:-96, 10:0, 11:0, 12:0
  Normal mixer raw underrun counters: partial=0 empty=0
  2 Tracks of which 0 are active
    Name Active Client Type      Fmt Chn mask Session fCount S F SRate  L dB  R dB    Server Main buf  Aux Buf Flags UndFrmCnt
       1     no   3190    3 00000001 00000003      97   7088 I 0 22050     0     0  00000000 0xe73da000 0x0 0x000         0 
       0     no   3190    3 00000001 00000003      89   7072 P 3 44100     0     0  004FF80C 0xe73da000 0x0 0x600      1768 
  0 Effect Chains

进一步简化对比可以看到：

车机上播音乐和导航    不卡顿    
    导航语音是     AudioStreamOut: 0xea0c8150 flags 0x6 (PRIMARY|FAST)
    后台音乐是     AudioStreamOut: 0xea0c82a0 flags 0x8 (DEEP_BUFFER)
手机上播音乐和车机上播导航     卡顿
    导航语音和后台音乐都是   AudioStreamOut: 0xea0c8150 flags 0x6 (PRIMARY|FAST)

蓝牙连接上手机后Music流走的输出流通道和导航的Alarm流走的输出流通道是同一个；车机上的Music流和导航的Alarm流走的是不同的输出流通道，也即是虽然两种场景下音乐的流都是Music流但是属性是不一样的，导致了最终系统选择的输出流通道不一致。

分析蓝牙底层的服务，看看蓝牙播放音乐时构建的AudioTrack对象跟平时播放音乐的有什么不同之处

void *BtifAvrcpAudioTrackCreate(int trackFreq, int channelType)
{
    LOG_VERBOSE(LOG_TAG, "%s Track.cpp: btCreateTrack freq %d  channel %d ",
                     __func__, trackFreq, channelType);
    sp<android::AudioTrack> track =
        new android::AudioTrack(AUDIO_STREAM_MUSIC, trackFreq, AUDIO_FORMAT_PCM_16_BIT,
                                channelType, (size_t) 0 /*frameCount*/,
                                (audio_output_flags_t)AUDIO_OUTPUT_FLAG_FAST,
                                NULL /*callback_t*/, NULL /*void* user*/, 0 /*notificationFrames*/,
                                AUDIO_SESSION_ALLOCATE, android::AudioTrack::TRANSFER_SYNC);//！！！注意AUDIO_OUTPUT_FLAG_FAST属性
    assert(track != NULL);

    BtifAvrcpAudioTrack *trackHolder = new BtifAvrcpAudioTrack;
    assert(trackHolder != NULL);
    trackHolder->track = track;

    if (trackHolder->track->initCheck() != 0)
    {
        return nullptr;
    }

#if (defined(DUMP_PCM_DATA) && (DUMP_PCM_DATA == TRUE))
    outputPcmSampleFile = fopen(outputFilename, "ab");
#endif
    trackHolder->track->setVolume(1, 1);
    return (void *)trackHolder;
}

调试的经验表明车机端音乐类应用在底层给出的属性一般是 AUDIO_OUTPUT_FLAG_DEEP_BUFFER ，这里给定的是 AUDIO_OUTPUT_FLAG_FAST，所以导致了这里的Music流走了跟Alarm流同一个输出流通道，当导航的Alarm音频流过来以后，音频路由发生了改变，先关闭了当前的输出流通道然后再开启才导致的卡顿问题，最后解决方案也很简单，将蓝牙这里的AUDIO_OUTPUT_FLAG_FAST属性修改为AUDIO_OUTPUT_FLAG_DEEP_BUFFER 属性即可，卡顿现象也随即消失。