tronteng的专栏

android的audioserver 进程启动时，会创建AudioPolicyManager,洋洋洒洒数千行的其构造函数，第一步就是加载配置相关的xml。#define AUDIO_POLICY_XML_CONFIG_FILE_PATH_MAX_LENGTH 128#define AUDIO_POLICY_XML_CONFIG_FILE_NAME "audio_policy_config...

1.1.1 AudioPolicyService的路由实现我们在AudioPolicyService小节曾将其比作是一个“路由器”，不过还没有深入解析它是如何完成路由选择的。这部分的功能与使用者——AudioTrack有很大关联，所以我们特别将它的实现原理剖析放在这里，以使读者可以综合起来理解。路由器功能由如下几个部分组成：l  与发送方(AudioTrack)的接口就好像路由器首

1.1.1 AudioMixer每一个MixerThread都有一个唯一对应的AudioMixer(在MixerThread中用mAudioMixer表示)，它的作用如其名所表示的，就是为了完成音频的混音操作。 图 13‑14 MixerThread示意图 如上图，MixerThread对外开放的接口主要涉及到Parameter(比如setPar

播放声音可以用MediaPlayer和AudioTrack，两者都提供了java API供应用开发者使用。虽然都可以播放声音，但两者还是有很大的区别的。其中最大的区别是MediaPlayer可以播放多种格式的声音文件，例如MP3，AAC，WAV，OGG，MIDI等。MediaPlayer会在framework层创建对应的音频解码器。而AudioTrack只能播放已经解码的PCM流，如果是文

目录(?)[+]前面一节的内容我们提到，ASoC被分为Machine、Platform和Codec三大部分，其中的Machine驱动负责Platform和Codec之间的耦合以及部分和设备或板子特定的代码，再次引用上一节的内容：Machine驱动负责处理机器特有的一些控件和音频事件（例如，当播放音频时，需要先行打开一个放大器）；单独的Platform和Codec驱动是不能工作的，它

目录(?)[+]1.  ASoC的由来ASoC--ALSA System on Chip ，是建立在标准ALSA驱动层上，为了更好地支持嵌入式处理器和移动设备中的音频Codec的一套软件体系。在ASoc出现之前，内核对于SoC中的音频已经有部分的支持，不过会有一些局限性：   Codec驱动与SoC CPU的底层耦合过于紧密，这种不理想会导致代码的重复，例如，仅

落鹤生 发布于 2012-03-04 12:21 点击:1277次 昨天（2011-11-15）发布了Android4.0的源码，今天download下来，开始挺进4.0时代。简单看了一下，发现音频系统方面与2.3的有较多地方不同，下面逐一描述。TAG: HAL  音频系统  ALSA  昨天（2011-11-15）发布了Android4.0的源码，今天

落鹤生 发布于 2012-03-04 12:19 点击:958次 这篇是承接上一篇提到的底层resample处理，以Samsung的mini alsa-lib为例说明。TAG: ALSA  Resample  音频系统  这篇是承接上一篇提到的底层resample处理，以Samsung的mini alsa-lib为例说明。mini alsa-lib

落鹤生 发布于 2012-02-01 10:18 点击:1053次 本来有打算写写Android音频系统的，但是仔细研究了如下链接的三篇文章，果断中断了我的想法。毫不夸张来说，这是我看过的最好的阐述 Android音频系统的文章了，简练精辟，将音频系统各个方面的重要的脉络都描述出来了。有这三篇文章，理解Android音频系统何止加快了10倍TAG: 蓝牙  音频

落鹤生 发布于 2012-02-22 10:13 点击:615次 默认的情况下，Android放音的采样 率固定为44.1khz，录音的采样率固定为8khz，因此底层的音频设备驱动只需设置好这两个固定的采样率。如果上层传过来的采样率与其不符的话，则 Android Framework层会对音频流做resample（重采样）处理。TAG: Resample  音频

之前转载过一篇文章-智能手机音频系统概述，描述了手机音频系统设计框图。实际上那是一个简单的做法，应用中有较大的局限性。那么一个完善的音频框架应该是什么样的呢？这两天根据Android4.0源码的一些线索，找到了相应的硬件资料，摘录下来。注：以samsung tuna方案（即galaxy nexus）为例。audio_hw在ANDROID音频系统散记之四：4.0音频系统HAL初探

1.1 AudioFlinger在上面的框架图中，我们可以看到AudioFlinger(下面简称AF)是整个音频系统的核心与难点。作为Android系统中的音频中枢，它同时也是一个系统服务，启到承上(为上层提供访问接口)启下(通过HAL来管理音频设备)的作用。只有理解了AudioFlinger，才能以此为基础更好地深入到其它模块，因而我们把它放在前面进行分析。 1.1.1 AudioF

1.1 音频框架转载请注明，From LXS, http://blog.youkuaiyun.com/uiop78uiop78/article/details/8796492Android的音频系统在很长一段时间内都是外界诟病的焦点。的确，早期的Android系统在音频处理上相比于IOS有一定的差距，这也是很多专业的音乐播放软件开发商没有推出Android平台产品的一个重要原因。但这并不代表它的音

1.1.1 音频设备的管理虽然AudioFlinger实体已经成功创建并初始化，但到目前为止它还是一块静态的内存空间，没有涉及到具体的工作。从职能分布上来讲，AudioPolicyService是策略的制定者，比如什么时候打开音频接口设备、某种Stream类型的音频对应什么设备等等。而AudioFlinger则是策略的执行者，例如具体如何与音频设备通信，如何维护现有系统中的音频设备，以及多

转至：https://www.cnblogs.com/senior-engineer/p/5089559.htmlAudioPolicyService是策略的制定者，比如什么时候打开音频接口设备、某种Stream类型的音频对应什么设备等等。而AudioFlinger则是策略的执行者，例如具体如何与音频设备通信，如何维护现有系统中的音频设备，以及多个音频流的混音如何处理等等都得由它来完成。Aud...

注意：本文基于 Android 7.0 进行分析。1) 设备开机，系统启动时将执行 /system/etc/init/audioserver.rc ，运行 /system/bin/ 目录下的 audioserver 服务。audioserver.rc 内容如下：service audioserver /system/bin/audioserver    class main    us...

配置音频政策Android 7.0 引入了一种新的音频政策配置文件格式 (XML)，用于描述音频拓扑。以前的 Android 版本需要使用 device/<company>/<device>/audio/audio_policy.conf 来声明您产品上存在的音频设备（您可以在 device/samsung/tuna/audio/audio_policy.conf ...

对音频系统的探索起源于工作中遇到的一个bug。平时都是力求快速解决问题，不问原因。这次时间比较宽裕，正好借着解决问题的机会，把Android的音频系统了解一下。既然由bug引发，那就从bug开始说。一. bug现象    Android的照相机在拍照的时候会播放一个按键音。最近的一个MID项目（基于RK3188，Android 4.2）中，测试部门反馈，拍照时按键音播放异常

1.1.1 Android中的同步与互斥Android系统也提供了自己的同步互斥机制，不过任何技术的本质都是类似的，更多的是把这些本质的东西应用到符合自己要求的场景。目前Android封装的同步互斥类包括：·          Mutex头文件在frameworks/native/include/utils/Mutex.h，因为实现与具体的平台有关，我们只关心如何使用它·     

1.1 SurfaceFlinger的启动SurfaceFlinger的启动和ServiceManager有点类似，它们都属于系统的底层支撑服务，必需在设备开机的早期就运行起来。/*frameworks/base/cmds/system_server/library/System_init.cpp*/extern "C" status_t  system_init(){…   

转载请注明：LXS, http://blog.youkuaiyun.com/uiop78uiop78/article/details/8787779对于一部嵌入式设备来说，除了若干基础功能外（比如手机通话、短信），最重要的可能就是多媒体了——那么一个最简单的问题，什么是多媒体呢？这个术语对应的英文单词是“Multi-Media”，直译过来就是多媒体。名称就很好地解释了它的含义，

1.1 AudioTrack1.1.1 AudioTrack应用实例对于Android应用开发人员来讲，音频回放最熟悉的莫过于MediaPlayer，而AudioTrack相信用的人相对会少很多。这是因为MediaPlayer提供了更完整的封装和状态控制，使得我们用很少的代码就可以实现一个简单的音乐播放器。而相比MediaPlayer，AudioTrack更为精练、高效，实际上MediaP

1.1 AudioPolicy Service在AudioFlinger小节，我们反复强调它只是策略的执行者，而AudioPolicyService则是策略的制定者。这种分离方式有效地降低了整个系统的藕合性，而且为各个模块独立扩展功能提供了保障。1.1.1 AudioPolicyService概述汉语中有很多与策略有关联的俗语，比如“因地制宜”、“具体问题具体分析”;战争中只遵照兵书制

1.1.1 PlaybackThread的循环主体当一个PlaybackThread进入主循环后(threadLoop),音频事务就正式开启了。仔细观察的话，我们会发现这个循环中会不断地调用以“threadLoop_”开头的若干接口，比如threadLoop_mix、threadLoop_sleepTime、threadLoop_standby等等。以这样的前缀开头，是因为这些函数都是在thr

刚刚解决了一个播放不出声音的问题，这里总结一下，在TI平台上调试ALSA的一些方法和步骤。平台ALSA信息ls /dev/snd/controlC0controlC1pcmC0D0cpcmC0D0ppcmC0D10ppcmC0D11cpcmC0D12ppcmC0D13ppcmC0D14cpcmC0D14ppcmC0D15cpcmC0D15p

声明：本博内容均由http://blog.youkuaiyun.com/droidphone原创，转载请注明出处，谢谢！Control接口Control接口主要让用户空间的应用程序（alsa-lib）可以访问和控制音频codec芯片中的多路开关，滑动控件等。对于Mixer（混音）来说，Control接口显得尤为重要，从ALSA 0.9.x版本开始，所有的mixer工作都是通过control接口

Loong：之前写过基于ALSA的WAV播放录音程序，见http://blog.youkuaiyun.com/sepnic/archive/2011/01/14/6140824.aspx。现在本想好好整理一下ALSA的编程思想，但Google了一下，发现已经有同道做了类似的工作，故将其转载过来，并添加一些本人的疑问以及补充（将会继续补充，原文很多重要的ALSA参数没有提到）。原文：http://blogo

前些日子写了一篇snd_kcontrol探究，该文主要从内核源码出发简单讲述一下kcontrol接口的始末。这几天因为要在Android里面添加一些音频控制接口，配合alsa_amixer scontents分析，对此有了更深的体会，记录于此。因为这方面的资料实在太少，很多东西都是自我理解的，如有错误请见谅并指出。 name字段是名称标识，这个字段非常重要，因为kcontrol的作用由名称

hwdep模块简述字符设备驱动中，ioctl是一个很常见的IO设备操作函数，可以自定义cmd命令字并实现对应的设备IO控制。音频设备的控制有所不同：驱动层大部分控制操作定义各种snd_kcontrol_new，然后注册到SNDRV_DEV_CONTROL模块中（sound\core\control.c），详见snd_kcontrol探究；而上层调用alsa-lib的snd_ctl_

这一年来的一个重要工作是音频设备驱动方面，如驱动开发、调试debug、性能调优、音频路由、回声消除等。除此之外，熟悉了一下alsa-lib接口，Android音频系统，包括设备抽象层和音频策略。遗憾的是一直没有什么机会接触蓝牙设备的集成和开发，可预知的未来无线设备会极大地普及。还有就是ffmpeg，以前经常用它来做一些兴致突来能力而及的小工具，年初时计划进一步在它的基础上学习H264或

需求：USB Headset插上去后，声音要从本地CODEC切换到USB Headset输出/输入。上网搜了有关USB Audio Hotplug的东西，比较适用的资源如下：1、Hotplugging USB audio devices (Howto)题目看起来很吻合我们的问题，事实上并没有多少参考价值。其中脚本/etc/hotplug/usb/extigy或许可以捕捉到USB

经过一周多的整理，包括一个周末，终于形成这个较为条理的文档。dapm系列从开坑到现在，时间跨度是3个多月。呵呵，这其实比我想象中要快，毕竟平时工作还是挺忙的。今后我想关于音频驱动方面的内容会减少，并不是说我已经全部掌握了alsa架构，pcm、card方面都没有进入深入研究。但架构方面的内容是相通的，细节方面嘛，我想dapm机制可能比其它更加复杂些。而且alsa-core部分可以找到不少资料的，

DAPM--Dynamic Audio Power Management，对应结构体是snd_soc_dapm_widget和snd_soc_dapm_route，对应的操作函数是snd_soc_dapm_new_controls()、snd_soc_dapm_add_routes()和snd_soc_dapm_new_widgets()。在我看来，DAPM是音频驱动初接触者的噩梦。从何处来，到何

在用alsa_amixer controls时，除了我们之前提到的snd_soc_add_controls添加的kcontrols外，还有一些多出来的controls。其实多出来的那些都是属于dapm kcontrol，主要用于切换音频路径。 一、AUDIO PATHS OVERVIEW以标准内核2.6.32的wm8900 codec为例。先看AUDIO P

ALSA: Advanced Linux Sound Architecture，它包括内核驱动集合、API库和工具。用户层程序直接调用libsound的API库，不需要打开设备等操作，因此编程者不需要了解底层细节。这里不分析ALSA的核心代码core，也不阐述如何在用户层进行声卡编程，仅仅简要介绍在ALSA的架构上添加一个声卡驱动，即上图中的Sound Driver。其实文档《wirte an

哲学里有三个终极命题：你是谁？从何处来？到何处去？而对于dapm机制，我们可以这样提问：dapm是什么，起到何作用？dapm是如何建立的？dapm又是如何触发的？下面会就这三个问题进行分析。首先是dapm是什么？这在DAPM之一：概述中提及了，就是音频电源动态管理。相信电源管理大家都不会陌生。dapm设计的目的就是只有需要时才打开必要的部件（widget），不需要时则关闭部件，达到省电的目的，

control控制接口控制接口对于许多开关(switch)和调节器(slider)应用广泛，它能被用户空间存取，从而读写CODEC相关寄存器。control的主要用于mixer。它用snd_kcontrol_new结构体描述。snd_kcontrol_new[cpp] view plaincopystruct snd_kcontrol

之前写过一个音频驱动CODEC分析，当时忽略了阐述最基本的概念。要了解一个东西，首先要明白它是什么它起到什么作用，然后才会更好对它的工作流程更好的分析。所以这里提一下：CODEC ：音频芯片的控制，比如静音、打开（关闭）ADC（DAC）、设置ADC（DAC）的增益、耳机模式的检测等操作。I2S   ：数字音频接口，用于CPU和Codec之间的数字音频流raw data的传输。每当有play

这段时间在探索ALSA架构，从ALSA Core到ALSA Lib，再到Android Audio System。在看ALSA Lib时，写了一个比较典型的基于ALSA的播放录音程序。程序包包含四个部分：WAV Parser是对WAV文件的分析和封装，这里只针对Standard WAV File；SND Common是Playback 和Record共同操作，如SetParams、Read

声明：本博内容均由http://blog.youkuaiyun.com/droidphone原创，转载请注明出处，谢谢！1. struct snd_card 1.1. snd_card是什么snd_card可以说是整个ALSA音频驱动最顶层的一个结构，整个声卡的软件逻辑结构开始于该结构，几乎所有与声音相关的逻辑设备都是在snd_card的管理之下，声卡驱动的第一个动作通常就是创建一个snd_c