Android 音频框架 基于android 12

文章目录

前言

  • Android 的音频是一个相当复杂的部分。从应用到框架、hal、kernel、最后到硬件,每个部分的知识点都相当的多。而android 这部分代码在版本之间改动很大、其中充斥着各种workaround的处理,让人看的云里雾里。网上相应的分析文章也很多,有些就贴大段的代码 是很不容易理解的。
  • 本系列就遵循从整体到局部, 从简单到复杂来分析。很多时候可能是带着问题来看文章。而写博客的目的 一是记录分析的过程,从迷茫 混乱到清晰 有序的关键概念和流程的理解。二是对系统或者框架思想的一个整体理解,为解决问题打下基础。
  • 总体的一个理解:借用android 官网的一张图, 从应用层开始,所有封装中的音频数据经过解码后为pcm数据(或者音频的裸数据),这个数据就拷贝到framework层,framework根据设备和配置文件中定义的路由情况,将应用层指定的数据送到对应的设备进行输出。

本篇文章的目标包括以下几点

  1. 从开机出发理解android audioservice 中audioflinger、audiopolicy提供怎样的服务。
  2. 从播放出发理解android的音频数据如何一路送到硬件。
  3. 从vendor.auio-hal出发理解hal层提供了怎样的服务。

音频服务audioserver

  • 首先从开机启动的音频相关服务audioserver开始

    • 开机init.rc文件中和音频有关的service audioserver其包括android 音频框架两个最重要的服务audioflinger 和audiopolicy。当然这两个服务之间并没有相互隔离的很开,有些函数会在这两个服务直接相互调用。
  • audioflinger的作用:

    • 跟HAL层的接口进行交互的地方, 包括load具体的某个module的实现,open相应的stream、往stream中写数据。
    • 为每个open的stream 创建相对应的线程,并维护线程和dev之间的关系,创建线程的时机是在成功open stream之后。
    • 维护和暴露给外部接口相对应的track,对外部track写到stream的数据进行处理包括mix、格式转换、采样率转换、音效处理、音量处理等等。
    • 创建patch,为音频输入和输出直接创建通路和线程, 使输入的数据直接输出到输出设备,而不需要通过应用层。
    • 根据配置track的模式、生成不同的线程,对数据进行不同的处理 主要有三种分别为direct(track的数据直接写到hal)、mix(经过混音 格式转换等处理)、offload (不经过解码数据直接写到dsp中。
  • audiopolicy的作用:

    • 载入音频audio_policy_configuration.xml配置文件,并将配置文件中的moules、module、port、profile、routes抽象成代码中的各种概念比如modules、device、port等等。并在解析到attach device后 去调用audioflinger的openOutput stream打开设备.
    • 保存路由的信息、这里面包括xml定义的 和 通过外部注册到policy的mix。
    • track 启动播放的时候 会调用audiopolicy的接口getoutputfromattr 通过attr获取输出的设备。获取设备后同时可以找到对应的线程,这样往track写的数据 就会写到hal。

音频数据链路

  • 简单的来讲 外部通过解码或者未解码的数据 buffer 写到track(这个track 可以是应用层也可以是framework层,应用层的调用到mediaPlayerservice 中的AudioOutput 其继承了AudioSink,audioSink是外部用的),

  • 从前面的分析可以往这个track写数据最终都会要通过output device对应的线程里面去写的。可以看出这两个是属于不同的进程。一个是mediaserver 一个是audioserver,其数据交互是通过匿名共享内存来实现。 这个共享内存在audioflinger创建track的时候分配的。在mediaserver 往track写数据的时候,会把数据拷贝到这个共享内存中,然后audioflinger 把数据从共享内存中拷贝出来 经过一系列处理写到hal中。

hal 提供什么样的作用

hal的功能有定义的一系列的接口,主要就是打开声卡设备、然后往声卡设备里面写数据。hal提供给外部audioFlinger的主要接口是openDevice 和open_output_stream。不同vendor实现的方式不一样,目前看到的大部分的实现是基于tinyalsa提供的接口来实现对声卡控件的操作和声卡的读写。

  • open_output_stream

    实现是创建了stream_out结构体,并赋值实现stream_out结构体中的不同函数指针。并将这个结构体返回给外部调用。这个会转换为外部的结构体 AudioStreamOut。 这个结构体会传递到audioFlinger 创建MixerThread中,后续应用调用audiotrack的write 函数会调用到hal层的write函数hal层使用tinyalsa 或者alsa的写到内核驱动中。

  • out_write

    hal中只有在out_write里面才会真正的去打开底层的硬件 进行数据的写入。

总结:

总的来说, 外部 framework audioflinger 通过hal提供的接口创建出dev 和stream以用来获取hal层的能力,相关的接口实现在audio hal中有定义,然后audioFlinger 通过调用dev和stream的指针函数来操作hal,主要的接口有打开设备 打开流 写数据 读数据等等。

相关推荐
SRC_BLUE_171 小时前
SQLI LABS | Less-39 GET-Stacked Query Injection-Intiger Based
android·网络安全·adb·less
无尽的大道4 小时前
Android打包流程图
android
镭封6 小时前
android studio 配置过程
android·ide·android studio
夜雨星辰4876 小时前
Android Studio 学习——整体框架和概念
android·学习·android studio
邹阿涛涛涛涛涛涛6 小时前
月之暗面招 Android 开发,大家快来投简历呀
android·人工智能·aigc
IAM四十二6 小时前
Jetpack Compose State 你用对了吗?
android·android jetpack·composer
奶茶喵喵叫7 小时前
Android开发中的隐藏控件技巧
android
Winston Wood9 小时前
Android中Activity启动的模式
android
众乐认证9 小时前
Android Auto 不再用于旧手机
android·google·智能手机·android auto
三杯温开水9 小时前
新的服务器Centos7.6 安卓基础的环境配置(新服务器可直接粘贴使用配置)
android·运维·服务器