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的写到内核驱动中。

    扫描二维码关注公众号,回复: 16764456 查看本文章
  • out_write

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

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

猜你喜欢

转载自blog.csdn.net/H2008066215019910120/article/details/132611474