yyc的博客

①java层的AudioTrack只是java语言的api（包皮公司），我们对java层AudioTrack的api调用，实际都会传递到native层的AudioTrack去执行；②native层的AudioTrack在初始化的时候，会跨进程的调用AudioFlinger的createTrack方法，并返回一个IAudioTrack的对象，native层的AudioTrack以及AudioFlinger通过这个对象进行交互；

我们的自己开发的模块如果需要跟踪系统中音频设备的插拔情况，就可以通过实现AudioDeviceCallback 接口并注册到AudioManager中。这样当系统中的音频设备发生插拔时就会回调AudioDeviceCallback 中的钩子函数。注意：音频焦点是只存在Android java framework层的机制，在native framework并不存在相关的概念。4.通常焦点申请者会获得音频焦点，释放先前持有焦点的申请。(先处理失去焦点要做的逻辑，再处理新的申请者获得焦点的逻辑)

要想不修改AudioService的文件换启动方式的话，也可以不动Lifecycle的代码，只要不启动Lifecycle而采用其他方式实例化AudioService就行了。并在onstart函数中完成AudioService的发布（这步完成后，其它进程就可以获取AudioService的binder句柄并藉此使用AudioService提供的服务）。通过上面的内容，我们已经知道audioservice是怎么被实例化的，接下来我们看看audioservice在构造函数中做了哪些工作。

audioflinger要负责具体的和硬件抽象层（hal）打交道，负责数据流的传递，混音，音量处理等工作。这些服务直接基于linux用户态相关的框架开发，提供媒体服务的支持。hal层：android定义的硬件抽象层，用于抽象底层的硬件结构。相关的API， 这些API既有java的版本，也有通过C++实现的。相关的API， 这些API既有java的版本，也有通过C++实现的（audiosystem）。这是任何基于linux内核开发的操作系统的基础，负责管理以及抽象硬件资源等传统意义上的操作系统的职责。

摘要：本文分析了Android系统中音量调节的核心实现逻辑，重点解读了AudioService中的adjustSuggestedStreamVolume和adjustStreamVolume两个关键函数。adjustSuggestedStreamVolume负责处理外部音量控制器、流类型判断等预处理逻辑；adjustStreamVolume则执行具体的音量调整操作，包含权限检查、静音处理等安全机制。文章通过代码注释的方式，揭示了TV/STB设备通过遥控器进行音量调节时，系统底层的处理流程和关键控制点。

从机制的角度来看，Binder在Android中起到了一种桥梁的作用，使得进程之间可以建立起通信管道，在需要的时候进行数据交换和消息传递。它允许一个进程调用另一个进程中的方法，就像调用本地方法一样，这使得应用程序可以在不同的进程之间共享功能和服务。然后，在客户端，开发者可以使用这些接口来调用服务端的方法，实现跨进程通信。总的来说，Binder是Android系统中实现进程间通信的重要机制，它为开发者提供了方便而强大的工具，使得不同进程之间的通信和数据共享变得简单而高效。

安卓音频数据的最终音量由三部分组成，分别是master volume(全局音量，对整个系统所有的音频数据生效），stream volume(流音量，只针对特定类型的音频数据生效)和track volume(track音量，只针对某个audiotrack的数据生效)。音频数据音量大小公式：playbackthread负责这个具体值的计算并设置到audiomixer中生效。其中master_volume，stream_volume和track_volume都是百分比，1表示音量调到最大；

output在创建同时，会创建一个与之一一对应的PlaybackThread，句柄为output，保存在AudioFlinger的mPlaybackThreads中；Output的描述符，真正的output实体，以output为句柄，保存在AudioPolicyManager的mOutputs中；对于module里的每一个output, new IOProfile, 放入module的mOutputProfiles；配置文件中的每一个module都被描述为HwModule，保存在mHwModules中；

息队列msg_idx_queue,此时会唤醒之前block在msg_idx_queue的task_common_task_loop任务并完成对相关消息的处理。audio init函数最终会调用到create_all_audio_task函数完成对所有任务的创建。DL_2ch_xx (fe)=> I2SOUTxx(be)(master) D表示down。2.audio_task包含成员变量和成员函数指针。task_common_task_loop中对IPI消息的分析后面具体分析。

如果把音频流比作水流的话，那sink就相当于大海，是流的目的和终点，source就相当于雪山，是流的开始和起源。流入大海的流就叫sink-input，从雪山流出来的流就叫source-output。回到PulseAudio的层面，sink就是用来播放的设备，sink-input就是播放的流，播放的过程就是创建一个sink-input，并把它连接到相应的sink上。

DMIPS是基于Dhrystone基准测试程序的MIPS值，用于评估CPU的整数运算能力。Dhrystone是一个简单的整数运算和逻辑运算的基准测试程序，通过测量CPU每秒能执行多少Dhrystone循环来反映CPU的整数运算性能。MIPS广泛应用于评估CPU的性能，特别是在不同处理器架构之间的比较中。DMIPS特别适用于评估通用计算任务的处理能力，提供了一个统一的标准来比较不同处理器之间的整数运算性能。MIPS即每秒百万指令数，是衡量CPU速度的一个指标，表示CPU每秒能够执行的百万级机器语言指令数。

杜比全景声突破了传统的以“声道”为基础的声音系统，将声音从在平面的环绕拓展到三维空间，并引入了“声音对象”的概念(object oriented)，让每个“声音对象”都可以在三维空间内被准确定位和移动，从而实现媲美真实世界的沉浸式声音体验。发展至今，从电影到电视剧集再到综艺节目和体育赛事，杜比全景声的内容形式一直在不断丰富，现在更是应用于音乐、游戏等更广的娱乐领域。根据之前和杜比合作的情况来看，在满足延时的前提下，杜比是倾向于在arm侧做杜比解码，在arm侧他们的方案会更加简单统一。车企和杜比合作集成。

自旋锁的目的是在多处理器系统中提供对共享数据的保护，其背后的核心思想是:设置一个在多处理器之间共享的全局变量锁V，并定义当V=1时为上锁状态，V=0为解锁状态。如果处理器A上的代码要进入临界区，它要先读取V的值，判断其是否为0，如果V≠0表明有其他处理器上的代码正在对共享数据进行访问，此时处理器A进入忙等待即自旋状态，如果V=0表明当前没有其他处理器上的代码进入临界区，此时处。以上两者其实并不属于严格意义上的锁，而是一些处理器相关的开关配置，是后面锁实现的基础！

内核的字符设备驱动框架是按照两条线展开的:一条是设备与系统的关系，一个字符设备对象cdev通过cdev add加入到系统中(由cdev map所管理的哈希表)，此时设备号作为哈希索引值;另一条是设备与文件系统的关系，设备通过设备号以设备文件的形式向用户空间显示其存在。也就是上面说到的第二条线。chrdev open通过inode->i_rdev在cdev map中查找inode对应的字符设备，cdev_map中记录着所。核版本的演进，老的.ko文件所调用的一些内核函数在新版本的内核中可能消失或者改变了。

调用pulseaudio接口根据pa_source_new_data数据创建pa_source。pa_source_new_data有点类似adnroid里面常用的builder类。调用pulseaudio框架接口初始化pa_source_new_data数据。至此，pa_init函数完成了pa_source的创建/赋值，以及注册到pulseaudio系统中的流程。daemon将数据写往sink类型的module，从source类型的module读取数据。结束pa_source_new_data的使用。

备注: Ubuntu20.04系统默认已安装libncurses.so.6.2和libtinfo.so.6.2，但是Android编译时需要版本5。python默认指向2.7版本。查看Ubuntu版本。

硬件codec，包含AD/DA ，smart PA，或者音频dsp 的IC，可以在片上（on chip）也可以外接。MCU：微控制器（Microcontroller Unit）或单片机（Microcontroller）的缩写，可理解为极简PC，集成了CPU、存储器、I/O接口等模块。SoC：系统级芯片（System on Chip）的缩写，指将系统的关键部件集成到一块芯片上的技术。一般指手机，电视，机顶盒等便携设备的主控处理器芯片。MAC(Multiply Accumulate): 乘积累加运算。

前面的文章分析了ASoC音频驱动中Codec、Platform、Machine驱动的组成及注册过程，这三者都是和物理设备相关的，大家应该对音频物理链路有了一定的认知。接下来分析ASOC音频驱动的中间层，由于这些并不是真正的物理设备，故我们称之为逻辑设备。逻辑设备和物理设备也是ALSA官方提及的概念。PCM逻辑设备，起着承上启下的作用：1.往上是与用户态接口的交互，实现音频数据在用户态和内核态之间的传输，即user space kernel space；

整个搬运数据的过程中我们比较关注的就是u->block_usec。这个变量决定了每个读写周期的时长（不考虑系统抖动的情况下）以及每次读写数据的时长。这个时长最好和底层的硬件周期时长保持一致！本文主要讨论pulseaudio模块的数据流。这里的模块（module）主要限制在sink和source这两种类型。下面的是module-null-source模块的数据搬运线程启动代码。pulseaudio的模块一般会启动一路线程进行数据的搬运和处理。8.休眠等待计时器以及货区本次休眠的时长。6.统计处理数据的时长。

作为音频从业者，理解一些常见的音频指标是必须的。下面总结一些音频指标以及测量的方法。

OH的音频策略核心类services/audio_policy/server/src/service/manager/audio_adapter_manager.cpp。audio_policy_service.cpp是对audio_adapter_manager.cpp的封装，用于提供跨进程服务。OH进行播放实例创建的时候会进行core和非core的分支判断，需要关注一下core和非core的差异。OH的响铃模式通过设置ring类型的 streamtype的静音来实现。

audiopolicyservice的依赖关系如下，audiopolicyservice最终调用的还是pulseaudio的接口。Audio驱动框架（系统服务以下的模块）基于HDF驱动框架实现，包含内核态（KHDF），和用户态（UHDF）， 对北向提供音频HDI接口（类似android的hal层接口）不难得出openharmony音频框架的设计思路是，基于pulseaudio框架，模仿android的音频概念进行封装和抽象。鸿蒙系统的音频播放API，audiorenderer的依赖关系如下。