learnframework的博客

车载模拟器因为有个特性和手机模拟器不一样，执行emualtor命令，车载模拟器会有热启动，就是可以秒启动上次模拟器，而不需要每次开机重启节省时间，但是这个热启动车载模拟器问题比较多，经常造成编译代码后不更新，或者容易模拟器整体冻屏等情况，所以建议大家每次启动使用恢复出厂设置命令，虽然麻烦一点但是能保证每次从头启动。基于上面学员们对车载模拟器的迫切多屏多音区的需求，这里进行马哥也进行系统中源码的调研，搜索，实践等终于给大家找到了解决办法。上图就可以看出车载多屏的出现，有驾驶舱，副驾驶舱，乘客舱等。

大家在查看dumpsys CarAudioService的输出时候，有一些输出可能不明白相关的含义，大家这个时候可以考虑去对应的源码中查询dump方法，找到对应变量方式来帮助理解整个CarAudioService，其实很多时候大家学习某个模块是否学通了，学懂了也可以尝试去看看这个模块的dump，看看你是否的狂都可以看得懂了。车载部分其实有自己的类型来表示当前的播放是什么类型的声音，车载中这些类型就是AudioContext，比如music，navigation等，其实是一个整数而已。

车载Audio其实本质上就是在原来手机那一套audio基础上额外进行了扩展，如扩展了CarAudioService，所以在做车载音频子系统开发调试时候不仅仅需要使用手机音频开发调试命令如：dumpsys media.audio_flinger, dumpsys media.audio_policy, dumpsys audio等命令，还需要使用针对车机音频独享的一些音频调试命令也非常的重要，下面重点将介绍车机音频调试常用的一些命令。主要介绍一下音频管理的相关命令。

所以只需要3个Criterion中只要有一个比如AUDIO_USAGE_MEDIA匹配上了，那么最后的结果都是matchedPositiveRules == presentPositiveRules，因为3个Criterion都是同一种类型的RULE_MATCH_ATTRIBUTE_USAGE。isCriterionMatched就是真正匹配的方法，它的实现也很简单，就是对track的usage，uid，userid与AudioMixMatchCriterion进行比对，只要比对上了就返回true。

一般是系统App定义构造好AudioPolicy即AudioMix对象，然后通过AudioManager接口跨进程到system_server的AudioService，AudioService通过AudioSystem向AudioPolicyManager中注册AudioPolicy数据时，AudioSystem就会将Java层的数据结构转换成C++层的数据结构,注意只需要转换传递核心的AudioMix对象既可以。排除的意思是指Device1不支持USAGE_MEDIA类型的声音播放。

audio课程中虽然有相关的实战案例让系统内录声音时候speaker也发出声音的情况，不过当时是有修改AudioPolicyManager中获取device中额外添加上speaker这个device，但是学员这里是要求不要修改系统源码就可以实现，所以这种现成的方案就不适用了。这个其实比较好实现，大概思路就是可以搞出两个AudioRecord，一个AudioRecord实现内录考虑REMOTE_SUBMIX，另一个mic声音也可以采用AudioRecord进行录制。上面学员的需求提出后，其实学习过。

在拒绝交互中，传入的请求一律会遭到拒绝。因此，对一个音频区的请求不会考虑其他音频区中的焦点持有者，也不会导致其他音频区中的焦点持有者失去焦点。如果在已有一项延迟请求的情况下，又发出另一项延迟请求，则最初发送的延迟请求将收到 AUDIOFOCUS_LOSS 更改事件，新发送的请求将收到 AUDIOFOCUS_REQUEST_DELAYED 的同步响应。因此，无论 HAL 是否被授予音频焦点，都应播放紧急声音或对保障安全至关重要的声音，即使 HAL 失去音频焦点，也应继续在适当的情况下播放这些声音。

更多实战干货，请关注下面“千里马学框架”

***/try {/***/try {解释如下：主要负责返回当前活跃的playback的相关信息主要负责返回当前活跃的录音trace的相关信息使用demo进行调用相关的api。

但是数据buf不足正常那就不足，正常我们想象就一直等待数据满足了后再进行thread_write写入数据到hal，那这样只是说数据要过一会才播放，能理解听到的效果一卡一卡，但是AudioTrack发送过来的数据应该是是按照顺序写入应该是要正常的，没有数据就不进行写入，这样来看那么MixerThread导出的wav文件也应该要正常？我们知道，在Audio模块中数据采用的是生产者-消费者模式，生产者负责生产数据，消费者用于消费数据，针对AudioTrack和AudioRecord，其对应的角色不同；

其实在audio的开发中另一个命令dumpsys audio 也是非常常见的的，特别是在音频焦点，音量调节部分的调试，音频设备连接等等，那么下面就重点聊一下dumpsys audio这个命令。因为输出的信息很多，我们只对重要的，常用的几个部分进行讲解，比如音频音量相关，音频焦点相关，其他部分大家也完全可以自己去AudioService的dump方法中追一些既可以。Event日志详细记录了音量变化的操作记录，经常可以用于音量不知道被谁改变的一个依据，比如是音量键操作还是说设置的音量条滑动操作。

上面可以看出在threadLoop中会有判断是否有Active的Track，没有就进行 mWaitWorkCV.wait等待，而上面的start方法刚好也有塞入mActiveTracks中然后进行唤醒。这里有需要看看创建CREATE_AUDIO_PATCH的方法createAudioPatchCommand被谁调用的。那么接下来问题又是到底谁发了这个CREATE_AUDIO_PATCH这个command呢？所以上面分析的代码认为是start方法最后的mWaitWorkCV唤醒是不对的。

上面代码就是AudioTrack在创建过程中 AudioTrack::createTrack_l()方法中的mediametrics的日志打印，其实可以看得出这个mediametrics日志打印还很详细，AudioTrack创建时候需要的相关属性和参数都有，但是这个日志打印也不是我们普通的ALOGE这种，直接使用adb logcat可以看到。所以一般比较建议使用–prefix X，这里X可以认为是一直日志的过滤，比如你只需要audiotrack相关记录，就使用audio.track。

Futex按英文翻译过来就是快速用户空间互斥体。Futex是一种用户态和内核态混合的同步机制。首先，同步的进程间通过mmap共享一段内存，futex变量就位于这段共享的内存中且操作是原子的，当进程尝试进入互斥区或者退出互斥区的时候，先去查看共享内存中的futex变量，如果没有竞争发生，则只修改futex,而不 用再执行系统调用了。当通过访问futex变量告诉进程有竞争发生，则还是得执行系统调用去完成相应的处理(wait 或者 wake up)。

如果它决定传递该请求，则会使用 IAudioTrack 工厂方法 IAudioFlinger::createTrack() 的 track_flags_t 参数的 TRACK_FAST 位来实现。客户端可以选择性地在 AudioTrack C++ 构造函数或 AudioTrack::set() 的 audio_output_flags_t 参数中设置位 AUDIO_OUTPUT_FLAG_FAST。尤其是，快速混音器看不到 Binder 级别的操作，但它确实会访问客户端的共享存储器控制块。

当然两者之间还是有紧密的联系的，MediaPlayer在framework层还是会创建AudioTrack，把解码后的PCM数流传递给AudioTrack，注意这里的AudioTrack不是app进程创建的，而是MediaPlayer对应的服务端mediaserver进程创建的AudioTrack，AudioTrack再传递给AudioFlinger进行混音，然后才传递给硬件播放，所以是MediaPlaye内部r包含了AudioTrack。虽然都可以播放声音，但两者还是有很大的区别的。

当您的应用需要输出音频时，它需要请求获得音频焦点，获得焦点后，就可以播放声音了。其他应用可以请求焦点，从而占有您持有的音频焦点。主要用了声明app是如何对待Audio ducking的情况，因为app申请的类型是AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK时候，它成为了新焦点，但影响原来的焦点，这个时候就有2中处理方式。1、一种系统默认处理直接让原来音频焦点app不接受丢失焦点的回调，而是系统层面直接吧原来音频焦点app的声音进行音量减低，主要听到肯定是新焦点app的声音，

出现这种情况时，您的应用会收到对 AudioFocusChangeListener 中 onAudioFocusChange() 方法的调用，该方法是您在应用调用 requestAudioFocus() 时指定的。其他应用可以请求焦点，从而占有您持有的音频焦点。在 Android 8.0（API 级别 26）中，当其他应用使用 AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK 请求焦点时，系统可以在不调用应用的 onAudioFocusChange() 回调的情况下降低和恢复音量。

物理音量按键也可以调节声音，设置界面的Seekbar也可以调节声音，请问二者是如何进行同步的呢？物理音量调节后设置的画面的也seekbar会同步动起来，本文来剖析一下为啥可以进行音量进度条的同步。VolumeStreamState类的setIndex中会进行对应的音量变化的广播Setting端的同步更新部分剖析广播方式通知数据更新：音量调节后会广播发送由AudioService发送frameworks/base/core/java/android/preference/SeekBarVolumi

刚开始stream=-2147483648,然后通过getActiveStreamType变成的默认的StreamType为3，也就是StreamType为music，后续都一直以StreamType为3进行音量条件，那么接下来主要分析一下getActiveStreamType方法。为什么系统在按音量上下键时候，就可以准确识别出当前的StreamType，调节的都是当前正在播放的StreamType？2、物理音量按键也可以调节声音，设置界面的Seekbar也可以调节声音，请问二者是如何进行同步的呢？

Netlink是Linux系统中一种用户空间进程和Kernel进行通信的机制，通过这个机制，位于用户空间的进程，可接收来自Kernel的一些信息（例如Vold中用到的USB或SD的插拔消息），同时应用层也可通过Netlink向Kernel发送一些控制命令。

上面已经剖析清楚了相关直接播放的speaker声音比内录到的声音大的原因了，解决办法其实就比较简单，那就是需要针对内录情况下的设备AUDIO_DEVICE_OUT_REMOTE_SUBMIX对应的音量index和正常播放的设备AUDIO_DEVICE_OUT_SPEAKER音量index做成一致既可以。1、直接引导用户自己在内录声音时候要进行音量条的设置，因为这个时候输出设备是AUDIO_DEVICE_OUT_REMOTE_SUBMIX，所以音量调节就是针对这个设备的。但是看看在内录声音时候的情况。

这个问题大家可以回想一下，本质上音量设置也是一般设置app操作了UI最后跨进程调用到了AudioService服务，一般跨进程服务其实也是可以直接使用adb shell service call 方式进行调用，比如以前使用service call命令调用SurfaceFlinger进行Layer trace的导出。那么根据上面IAudioService.aidl文件中展示的各个接口方法，首先要确定接口方法，然后数出对应方法的序号，再确认具体参数，确定使用的方法，下面两个方法其实都可以。

这种带有_REMOVE主要代表的是track的数据，因为track一般使用完了就会进行remove，所以一般track的数据是不需要进行主动的dump才生成的，是每次track 在remove时候就会有。那么本文马哥就带大家来深入剖析一下Tee sink的源码分析，因为理解了源码后，后续大家如果想要在其他地方或者场景要额外dump出数据，或者这种Tee sink的调试方案也有了很好的参考。Tee sink本质就是导出相关的track和mixerthread的数据，这些数据具体导出后是怎么样的呢？

1.确定是否有 /data/misc/audioserver目录，这个目录来获取相关AudioFlinger里面的音频输出目录 2.确定是否有 af.tee property，prop值主要有1，2，4，具体值含义可以frameworks/av/services/audioflinger/NBAIO_Tee.h查看。整个音频流程中，首先是各个app的AudioTrack的数据，传入AudioFlinger，由AudioFlinger进行了混音后，再送入Hal，kernel等。

从简单的基础专题开始学习，以最熟悉的声音播放为主线对整个涉及的音频框架系统进行挨个模块剖析，这里面涉及App层面，AudioFlinger，AudioPolicy等模块，都会带你进行详细剖析，而且还对较难的音频hal部分也进行了深入讲解，同时也会讲解音频实战开发中，经常使用的dumpsys命令及命令输出相关源码及代表意义。3、公司级别的项目实战为主导，让你学习的音频系统的源码分析理论知识可以直接用于实现公司级别的项目需求，真实带你手把手实现项目需求，包括方案预言，调研其他厂商，方案设计，代码实现等。

功能 android.hardware.audio.pro 中的“pro”是指可预测的实时性能级别，而非目标用户。在 Android 中，ALSA 指的是内核音频框架和驱动程序，而不是用户模式类。就满足专业音频部分中所述 android.hardware.audio.pro 功能的要求而言，设备实现方案支持实时计算是一个必要但非充分的前提条件。不过，AudioFlinger 客户端可以是一个在 mediaserver 系统进程中运行的线程，例如，播放由 MediaPlayer 对象解码的媒体内容时。

通过调用 getEventFlagWord()，您可以获取指向队列的事件标记字词的指针，并可以使用该指针（或任何指向合适的共享内存位置的指针）来创建 EventFlag 对象，以传入其他队列的长格式 readBlocking() 和 writeBlocking()。如果某个读取器的读取速度无法跟上写入器的写入速度，则写入的数据量和该读取器尚未读取的数据量加在一起会超出队列容量，这会导致下一次读取不会返回数据；相反，该读取操作会将读取器的读取位置重置为写入位置，加上容量的一半，然后返回失败。

在使用dumpsys media.audio_policy时候经常会看到关于Engine的2个重要输出：1、Product Strategies相关2、Volume Groups相关那么大家是否有考虑这个两个输出具体是怎么来的，还有Product Strategies和Volume Groups二者有什么联系么？二者又是桌面联系到一起的，带着这些疑问下面来进行详细剖析。

代码基于aosp15。

而StreamIO描述的是系统中的音频输入输出流，比如AUDIO_OUTPUT_FLAG_PRIMARY、AUDIO_OUTPUT_FLAG_DIRECT。在C/C++世界中的定义是在system/media/audio/include/system/audio-hal-enums.h头文件中的audio_stream_type_t枚举。在C/C++世界中的定义是在system/media/audio/include/system/audio.h头文件中的audio_attributes_t结构体。

hal对应的守护进程模拟器上audio的hal其实有一个守护进程，这个守护进程就是hidl的服务端，因为audio目前还是使用hidl进行通讯，客户端一般是AudioFlinger。这个android.hardware.audio.service进程对应的代码位置如下：核心代码主要就是这个service.cpp，当然还有肯定包含了很多的接口实现，不过一般这些实现都会有对应的so文件。