189 8069 5689
前段时间在阅读苹果音频文档（均列在参考资料一节里面了），并做了一些音频相关的开发（主要是带回音消除的录音）。这里做一个总结。
成都创新互联专注为客户提供全方位的互联网综合服务，包含不限于成都做网站、成都网站设计、沭阳网络推广、微信小程序定制开发、沭阳网络营销、沭阳企业策划、沭阳品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；成都创新互联为所有大学生创业者提供沭阳建站搭建服务，24小时服务热线：13518219792，官方网址：www.cdcxhl.com
每一个 app 带有一个 AVAudioSession 的单例（也就是说正常情况下你无法获得第二个 AVAudioSession 实例）。iOS 系统上每个 app 有各自不同的 AVAudioSession 实例。通过使用这个实例的方法可以告诉系统当前的 app 是怎样使用手机的音频服务的，然后系统会根据每个 app 的配置进行相应的协调， 尽量 满足所有 app 的请求，当无法满足的时候，系统尽量满足前台 app 的要求或者系统电话服务等。比如说，如果当前另外一个 app 正在播放的话，当前 app 可能希望能将其播放的音频和其他 app 的音频一起播放，而不是暂停其他 app 的音频服务；又比如说当前 app 需要播放音频或者进行录音；比如当前 app 只是播放音频；比如当前 app 只是录音；比如当前 app 播放音频时候屏蔽所有其他 app 的音频等等，总之就是告诉系统当前 app 是如何使用它的音频服务的。
Audio Session 有三个比较重要的概念：
通过配置这三个内容，表达了当前 app 的使用音频服务的具体意图。
在某些情况下，我们不需要配置 Audio Session 的 category，比如如果使用 AVAudioRecorder 来录音，并不需要配置 category 为 AVAudioSessionCategoryRecord ，因为系统在我们使用 AVAudioRecorder 的录音服务的时候已经为我们配置了。同时 Audio Session 有默认配置（如果当前 app 不进行配置的话）。当默认配置无法满足需求的时候，就可以手动配置 Audio Session
Audio Session 另一个重要功能是配置系统音频服务硬件参数，比如配置输入的声道数，采样率，IO 缓存时间等等。其 API 中 setPreferred__ 开头的方法作用就是这些。
配置完 Audio Session 以后，当我们要求的音频服务受到打断（比如，电话来了，则系统要停止录音和播放；比如，app 退到后台运行了，如果没有配置后台运行的话，系统也会停止当前 app 的音频服务；），我们可以使用通知中心的方式来监听，并做一下相应的处理。音频服务中断有两个概念比较重要，就是中断开始以及中断结束，我们可以在中断开始的时候记录当前播放时间点，中断结束的时候重新开始播放（当然系统默认行为是会在中断结束时重新开始播放音频，但是如果默认行为无法满足需求时候，就需要自行处理了）。
Audio Session 另一个重要我们需要监听的变化是路由变化 （Route Change）。比如有新的输出源来了（比如用户把耳机插进去或者是用户开始使用蓝牙耳机），或者原来的输出源不可用了（用户拔掉耳机等）。
还有一些其他的功能，比如当前其他 app 是否在播放音频，请求麦克风权限等，可以查看具体的 API 文档 AVAudioSession 。
使用 Audio Queue Service 我们可以做到录音或者播放音频。当然我们使用 AVAudioPlayer 也能很简单的做播放音频功能，那为什么要用到 Audio Queue Service 呢？它有几个优点
理解 Audio Queue Service 比较重要的是它的 buffer queue。拿录音来说，一般设置的缓存是3个。首先通过 AudioQueueEnqueueBuffer 将可用缓存提供给相应的 queue。然后系统开始将记录下的音频数据放到第一个缓存，当缓存满的时候，回调函数会将该 buffer 返回给你并将该缓存出列，在回调函数中我们可以对这些数据进行处理，与此同时系统开始将数据写到第二个缓存，当我们的回调函数处理完第一个返回的缓存时候，我们需要重新使用 AudioQueueEnqueueBuffer 将该缓存入列，以便系统再次使用。当第二个缓存返回的时候，系统开始往第三个缓存写数据，写完之后返回第三个缓存，并开始往之前返回的第一个缓存写数据。这就是一个典型的队列结构（先进先出，后进后出）。
Audio Unit 是所有 iOS 以及 macOS 上音频框架的最底层，无论使用的是 AVAudioRecorder、AVAudioPlayer、或者 Audio Queue Service、OpenAL 等，最终底层实现都是通过 Audio Unit 来完成的。
在 iOS 上可用的 audio unit 是有限的，macOS 上面可以自定义一个 audio unit 但是 iOS 上不行，只能使用系统提供的 audio unit。
什么时候使用 Audio Unit ？官方的说法是，当你需要高度可控的、高性能、高灵活性或者需要某种特别的功能（比如回音消除，只在 audio unit 提供支持，所有高层 API 均不支持回音消除）的时候，才需要使用 audio unit。
有4类 audio unit（具体用途看名字就能理解）：
使用 audio unit 有两种方式：
第一种方式是对于比较简单的结构。
第二种方式是用于构建复杂的音频处理流程。配置具体的 audio unit 的属性的时候还是会用到直接使用种的方法。
audio unit 重要的概念是 scope 和 element。scope 包含 element。
scope 分三种：
scope 概念有一点抽象，可以这样理解 scope，比如 input scope 表示里面所有的 element 都需要一个输入。output scope 表示里面所有的 element 都会输出到某个地方。至于 global scope，应该是用来配置一些和输入输出概念无关的属性。
element 官方的解释是可以理解成 bus，就是将数据从 element 的一头传到另一头。
这里有些问题我也不知道如何解答，若有了解的，请多多指教一下。
在音频开发中 .WAVs和.MP3有什么不同呢,或者还有的.AAC和.CAF之前又有什么区别呢,这些概念在这篇文章以后应该会有一定的理解.
如果要理解每一个音频文件,就需要了解它的两个部分的内容:文件格式和数据格式.文件格式又称为音频容器,数据格式又可以认为是编码格式.
文件格式(音频容器)描述的是存储在文件系统的文件的本身,而存储在文件中的音频数据是可以被编码成各种各样的格式的.比如,我们常见的CAF文件是一个文件格式(音频容器),它可以用来存储音频编码格式为MP3,LPCM或者其他的音频编码格式.
这里先来理解音频编码,在音频相关的内容中,音频编码是最重要的.
iPhone中支持的音频格式如下:
AAC: 被设计用来取代MP3音频编码的.它会压缩原来的声音,因此会减少存储空间.实际中ACC比MP3更好的压缩率.
AMR: AMR是一个编码格式用于压缩语音的音频编码格式.
linear PCM: 是标准的线性脉冲编码,一般是将模拟声音转化成数字信号,这是一个未压缩的音频格式.由于是未压缩的音频编码格式,因此播放时候用这种格式最是最好的选择,但是会占用过多的空间.
MP3: ...
IMA4: ...未压缩
...
首先明确自己有哪些需求:
所以如何选择数据音频格式,这里有些建议:
对于LPCM音频编码是iPhone中使用非压缩音频数据最好的数据格式.同时,根据具体的存储方式,又有多种变种.音频数据可以存储于大端或者小端模式,用float或者integer存储,也可以使用不同的bit-width存储.
而在iPhone中,使用的最平凡的是:little-endian integer 16bit(或者LEI16 short类型)的格式.在Mac中,使用native-endian(和电脑一致) float point 32bit.如果是在Mac上生成音频数据,那么最好生成合适的格式,再转化成iPhone使用的格式.
iPhone支持许多文件格式(音频容器)包括:MPEG-1(.mp3),MPEG-2 ADTS(.aac),AIFF,CAF,WAVE等.但是通常在iPhone中使用的容器格式就CAF,因为它可以用来封装iPhone所支持的所有音频格式.
比特率是一个和音频数据格式关系密切的概念.
音频文件的比特率就是只单位时间内传送的bit数,单位是bit/s,kbit/s.更高的比特率会导致更大的文件.我们在使用有些音频数据格式例如AAC或者MP3时,需要我们去设置比特率,这个参数与音频格式在压缩过程的压缩率有关.当我们让比特率变低,那么音频质量就会更差.
我们需要权衡比特率的大小和声音文件的质量,选择合适的比特率.如果我们使用的是语音声音,那么比特率可以适当低一点.
下面是常见的比特率:
最后一个专业术语:采样率.可以见前面的文章.
Core Audio 是iOS和MAC系统中的关于数字音频处理的基础，它是应用程序用来处理音频的一组软件框架，所有关于iOS音频开发的接口都是由Core Audio来提供或者经过它提供的接口来进行封装的。
其实一句话，它是任何iOS或者MAC系统音频处理框架的基础。
具体可以用官方文档的一张图表示。
接下来我们就一起分析一下。
这里的高级别服务，更加接近于顶层，基本上我们很多关于音频开发的工作在这一层就可以完成。
它位于框架 AudioToolbox 中。
提供录制、播放、暂停、循环、和同步音频它自动采用必要的编解码器处理压缩的音频格式。
要在iOS设备上播放和录制音频，苹果推荐我们使用 AVFoundation 框架中的 AVAudioPlayer 和 AVAudioRecorder 类。虽然用法比较简单，但是不支持流式；这就意味着：在播放音频前，必须等到整个音频加载完成后，才能开始播放音频；录音时，也必须等到录音结束后，才能获取到录音数据。这给应用造成了很大的局限性。为了解决这个问题，我们就需要使用 Audio Queue Services 来播放和录制音频。感兴趣的可以看我前面写的几篇关于 Audio Queue Services 的文章。这里只是简单的给出录音和播放的原理图，具体原理和流程，看我前面写的那几篇，都有详细的介绍。
它位于框架 AVFoundation 中。
是专为IOS平台提供的基于Objective-C接口的音频播放类，可以支持iOS所支持的所有音频的播放，它主要支持以下音频格式。
这个是纯OC的实现，特点就是调用简单，下面简单的看一下他的API。
由 Audio File 与 Audio Converter 组合而成，提供压缩及无压缩音频文件的读写能力。
它与 Audio File Services 、 Audio File Stream Services 和 Audio Queue Services 等同时存在 AudioToolbox 框架中。 ExtendedAudioFile 相对 Audio File Services 和 Audio Converter Services ，API调用非常简单和明确，并且不需要去处理 AudioStreamPacketDescription ，在实际开发中逻辑更为清晰。
它就是存在框架 OpenAL 中。
是CoreAudio对OpenAL标准的实现，可以播放3D混音效果。
OpenAL 主要的功能是在来源物体、音效缓冲和收听者中编码。来源物体包含一个指向缓冲区的指标、声音的速度、位置和方向，以及声音强度。收听者物体包含收听者的速度、位置和方向，以及全部声音的整体增益。缓冲里包含 8 或 16 位元、单声道或立体声 PCM 格式的音效资料，表现引擎进行所有必要的计算，如距离衰减、多普勒效应等。
不同于 OpenGL 规格，OpenAL 规格包含两个API分支；以实际 OpenAL 函式组成的核心，和 ALC API ， ALC 用于管理表现内容、资源使用情况，并将跨平台风格封在其中。还有 “ALUT ”程式库，提供高阶“易用”的函式，其定位相当于 OpenGL 的 GLUT 。
该层功能比较齐全，包括音频数据格式转换，音频文件读写，音频流解析，插件工作支持等。
它位于框架 AudioToolbox 中。
负责音频数据格式的转换
它位于框架 AudioToolbox 中。
负责音频数据的读写。
它位于框架 AudioToolbox 中。
支持均衡器和混音器等数字信号处理的插件。
它位于框架 AudioToolbox 中。
负责流解析。
它位于框架 Core Audio 中。
负责音频音频时钟同步。
该主要在MAC上的音频APP实现中并且需要最大限度的实时性能的情况下使用，大部分音频APP不需要使用该层的服务。而且，在iOS上也提供了具备较高实时性能的高层API达到你的需求。例如 OpenAL ，在游戏中具备与I/O直接调用的实时音频处理能力。
它在 IOKit 框架中，与硬件驱动交互。
获得用户空间访问硬件设备和驱动程序。 I / O Kit 框架通过设备接口机制实现对I / O Kit对象（驱动程序和结点）的非内核访问。
音频硬件抽象层，使API调用与实际硬件相分离，保持独立。
它位于 Core MIDI 框架中，与MIDI设备（如硬件键盘和合成器）进行通信。
Core MIDI 框架提供了用于与MIDI（乐器数字接口）设备（包括硬件键盘和合成器）进行通信的API。 使用基座连接器或网络从iOS设备进行连接。 有关使用基座连接器的更多信息，请参阅Apple的 MFi program 。
访问电脑硬件时钟。
只实现音频的播放，没有其他需求， AVAudioPlayer 就可以满足需求。它的接口使用简单，不用关心其中的细节，通常只提供给它一个播放源的URL地址，并且调用其play、pause、stop等方法进行控制，observer其播放状态更新UI即可。
APP需要对音频进行流播放，就需要 AudioFileStreamer 加 Audio Queue ，将网络或者本地的流读取到内存，提交给 AudioFileStreamer 解析分离音频帧，分离出来的音频帧可以送给 AudioQueue 进行解码和播放，可参考下面。
AudioStreamer
FreeStreamer
AFSoundManager
APP需要需要对音频施加音效（均衡器、混响器），就是除了数据的读取和解析以外还需要用到AudioConverter或者Codec来把音频数据转换成PCM数据，再由AudioUnit+AUGraph来进行音效处理和播放，可参考下面。
DouAudioStreamer
TheAmazingAudioEngine
AudioKit
1. iOS Audio Unit(一)
1、只可以播放完整的音频
2、支持播放本地和网络音频
3、在播放网络音频的时候需要先下载到本地，做转码播放
4、只能存在一个，想要播放下一个音乐的时候需要将上一个销毁
建议使用AVPlayer
任何吸引人的游戏都少不了声音。iOS开发者在游戏中需要使用声音时有多种选择，取决于对游戏中音频的控制需求，可以选择简单的内置服务，也可以选择更高级的API（比如OpenAL）。
通过音频API，可以实现流式音频，播放简短音效，甚至模拟3d空间的音频。有些游戏可以通过音轨让玩家沉浸在特定的心境中玩游戏，设置鼓励用户使用耳机来获得更完美的体验。
本系列文章中，会陆续整理近几年来在工作中涉及到的音频的相关知识，以算做对自己知识体系的一次梳理吧，大体包括Core Audio、OpenAL 以及Cocos2d引擎中的音效部分等三个方面。
• Core Audio 是什么?
• Core Audio 中提供的音频服务
• Core Audio 中的有关音频框架
• 有关 Core Audio 的变化及更新
Core Audio 是什么？
Core Audio 是iOS和 MAC 的关于数字音频处理的基础，它提供应用程序用来处理音频的一组软件框架，所有关于IOS音频开发的接口都是由Core Audio来提供或者经过它提供的接口来进行封装的，按照官方的说法是集播放、音频处理、录制为一体的专业技术，通过它我们的程序可以同时录制，播放一个或者多个音频流，自动适应耳机，蓝牙耳机等硬件，响应各种电话中断，静音，震动等，甚至提供3D效果的音乐播放。
相关链接:
Core Audio Overview
Audio Video Starting Point
Core Audio Glossary
Core Audio中提供的音频服务
Core Audio 本身是一个很庞大的话题，涉及到多个领域中的不同服务，为了更方便的使用Core Audio，通常可以将其分割为更小的模块。图一展示了根据应用程序服务层分解的示意图。构建在应用程序栈最下面的是底层硬件。接下来往上是驱动程序层。构建在驱动层之上的每一层都是苹果提供给开发人员的应用层服务，包括各类音频API和框架。
主要的几类服务：
Audio Unit
Audio Unit 是Core Audio 在应用层中最底层的服务。在使用其他音频API时，最终在底层都会调用到Audio Unit。在所有的API中，Audio Unit 是延迟最短且最灵活的，但代价就是它的使用相当的复杂，幸运的是在实际使用中，我们很少直接使用Audio Unit。
相关链接:
Audio Unit Framework Reference
相关项目工程：
Core Audio Utility Classes
Audio File Service
通过Audio File Service 提供的API可以打开并读取或者写入磁盘上存储的文件。
Audio File Stream Service
它是对Audio File Service 的扩展补充。Audio File Service 对存储到磁盘上的音频文件进行操作，而Audio File Stream Service
并不一定关联到某个文件上，它更适合基于网络的音频应用程序。
Audio Conversion Service
通过它可以将数据转换为PCM格式或者从PCM格式转换成数据。
Extended Audio File Service
可以将它理解为Audio File Service 和 Audio File Service 的组合。通过这种API 可以直接加在并转换音频文件。
Audio Session Service
和Core Audio中的其他API不同，它的主要用于 iOS 系统中协调应用程序之间的音频播放的 API 的。例如，当有电话打进来时，音频的播放就会被暂停；在用户启动电影时，音乐的播放就会停止。我们需要使用这些 API 来确保一个应用程序能够正确响应并处理这类事件。
System Sound Service
它是一种允许播放短音效和警告的基本服务，还具有提供振动功能的独特能力，Core Audio中的其他任何服务都不能访问振动系统。
Audio Queue Service
它可以对播放音频进行精细的控制，比如暂停、继续、循环播放和音频同步等，因此特别适合于播放和录制持续时间很长的音频。在游戏中进行语音叙述等情景时，需要音乐或者长时间的播放文件，便会需要它。
AVFoundation
它是Core Audio中唯一基于Objective－C的框架。这个框架提供了AVAudioPlayer类用于播放，AVAudioReconder类用于录音，以及AVAudioSession类用于设置音频回话。和其他高层API一样，我们需要在易用性和功能之间做出权衡。如果在此框架中找不到我们需要的特性或者功能，那么就必须深入底层服务并直接使用底层的API。
相关链接：
AV Foundation Framework Reference
AV Foundation Programming Guide
Audio Session Programming Guide
相关的项目工程:
AVCaptureAudioDataOutput To AudioUnit iOS
OpenAL
和其他专用API不同，OpenAL是一个狂平台的用于播放和捕捉音频的工业标准。OpenAL更适合播放空间音频（spatialized sound）或者定位音频（positional sound）。可以将空间音频理解成3D空间中的声音，通过OpanAL可以对音效添加一些效果，比如位置属性，这样会使远程的声音比近处的声音听起来要弱一些。
相关链接：
OpenAL FAQ for iPhone OS
相关的项目工程：
oalTouch
Core Audio中的有关音频框架
Core Audio 中的服务和框架并没有一对一的对应关系，应用层的服务实际上分为5个不同的框架：Core Audio、Audio Toolbox、Audio Unit、AVFoundtaion、OpenAL。图二中很好的展示了这些框架和服务之间的映射关系。
Audio Unit、AVFoundation和OpenAL的框架非常明了，和他们同名的服务直接对应，其中AVFoundtion有三个Objective－C类组成：AVAudioPlayer、AVAudioRecorder和AVAudioSession。
Audio Toolbox 框架提供了前面列出的其他剩下的应用层服务，包括非常重要的Audio Session Service。
相关链接：
Audio Toolbox Framework Reference
其他相关框架：
Media Player Framework
它是一个用于音频和视频播放的高层级接口，它包含了一个可以在应用中直接使用的默认的用户界面，可以使用它来播放用户在 iPod 库中的项目，或者播放本地文件以及网络流。另外，这个框架也包括了查找用户媒体库中内容的 API，同时还可以配置像是在锁屏界面或者控制中心里的音频控件。
相关链接：
Media Player Framework Reference
Core MIDI Framework
提供与MIDI设备通讯的标准方式，包括硬件键盘和合成器。可以使用这个框架来发送和接收MIDI消息以及与通过dock连接器或网络连接到iOS设备的MIDI外设交互。
相关链接：
Core MIDI Framework Reference
OS 4.0以后的功能变化如下：
iOS 7.1
Support for External Media Players (CarPlay相关的)
iOS 7.0
新增 Inter-App Audio和 AudioCopy
强化 Media Player / AV Foundation Framework
弃用 Audio Toolbox framework内的Audio Session API
iOS 6.0
新增 Audio UnitのComponent
强化 Media Player / Core Media / AV Foundation Framework
iOS 5.0
新增 Audio UnitのComponent
强化 Media Player / AV Foundation / AudioToolbox Frameworks
iOS 4.3
强化 AV Foundation
强化 Media Player / Audio Unit / Audio Toolbox Frameworks
iOS 4.2
新增 Core MIDI framework
强化 Media Player Framework
新增 AirPlay
iOS 4.1
强化 AV Foundation
iOS 4.0
新增 Core Media Framework
强化 AV Foundation
相关链接：What's New in iOS