手机通讯系统信号流程
一、通信系统
通常我们把信息从发送者传送到接收者的过程称为通信，而实现信息传输过程的系统称为通信系统。
下面的框图表示了一个基本的通信系统。
信道根据传输介质、方式的不同可分为有线和无线
1、编码调制
由于传输介质及其格式的限制，通信双方的信号不能直接进行传送，必须通过一定的方式处理之后，使之能够适合传输媒体特性，才能够正确无误地传送到目的地。
调制是指用模拟信号乘载数字或模拟数据；而编码则是指用数字信号乘载数字或模拟数据。
2、通信系统的两个主要指标：有效性和可靠性
（1）模拟通信系统：
有效性→带宽
可靠性→输出信噪比
（2）数字通信系统：
有效性→码元速率、信息速率和频带利用率
可靠性→误码率、误信率
二、GSM的帧结构
帧描画了以串行流的形式在通信信道上发送的数据的结构。在串行通讯中，数据以流的形式从源端发送到目的端。两个系统共同维护当前的通讯会话。数据流被分成若干个帧，帧是由一个起始位、几个数据位和1个停止位组成的。
GSM900工作带宽为25 MHz，每个载频为200 kHz， 因此可以获得124个载频频道，考虑到第一个、最后一个作为保护频道不用，因此GSM900共有122个载频频道可用。这就是GSM的频分复用。
对于每个载频频道，再进行时分，分为8个时隙。这就是GSM的时分复用。
载频是载波的一个特性。在无线通信技术上我们使用载波传递信息，将数字信号调制到一个高频载波上然后再在空中发射和接收。载频是载波的频率，单位HZ。
三、信号处理流程
这里以MTK平台举例说明：
1、MTK平台 GSM双频手机发送信号处理流程
2、MTK平台 GSM双频手机接收信号处理流程
四、通话处理流程（硬件）五、音频软件架构
该部分转载（http://blog.csdn.net/zyuanyun ）
Audio 是整个 Android 平台非常重要的一个组成部分，负责音频数据的采集和输出、音频流的控制、音频设备的管理、音量调节等，主要包括如下部分：
Audio Application Framework：音频应用框架
AudioTrack：负责回放数据的输出，属 Android 应用框架 API 类
AudioRecord：负责录音数据的采集，属 Android 应用框架 API 类AudioSystem： 负责音频事务的综合管理，属 Android 应用框架 API 类
Audio Native Framework：音频本地框架
AudioTrack：负责回放数据的输出，属 Android 本地框架 API 类
AudioRecord：负责录音数据的采集，属 Android 本地框架 API 类
AudioSystem： 负责音频事务的综合管理，属 Android 本地框架 API 类
Audio Services：音频服务
AudioPolicyService：音频策略的制定者，负责音频设备切换的策略抉择、音量调节策略等
AudioFlinger：音频策略的执行者，负责输入输出流设备的管理及音频流数据的处理传输
Audio HAL：音频硬件抽象层，负责与音频硬件设备的交互，由 AudioFlinger 直接调用
与 Audio 强相关的有 MultiMedia，MultiMedia 负责音视频的编解码，MultiMedia 将解码后的数据通过 AudioTrack 输出，而 AudioRecord 采集的录音数据交由 MultiMedia 进行编码。
播放声音可以使用 MediaPlayer 和 AudioTrack，两者都提供 Java API 给应用开发者使用。两者的差别在于：MediaPlayer 可以播放多种格式的音源，如 mp3、flac、wma、ogg、wav 等，而 AudioTrack 只能播放解码后的 PCM 数据流。从上面 Android 音频系统架构图来看：MediaPlayer 在 Native 层会创建对应的音频解码器和一个 AudioTrack，解码后的数据交由 AudioTrack 输出。所以 MediaPlayer 的应用场景更广，一般情况下使用它也更方便；只有一些对声音时延要求非常苛刻的应用场景才需要用到 AudioTrack。
AudioTrack Java API 两种数据传输模式：
AudioTrack Java API 音频流类型：
Android 为什么要定义这么多的流类型？这与 Android 的音频管理策略有关，例如：
（1）音频流的音量管理，调节一个类型的音频流音量，不会影响到其他类型的音频流；
（2）根据流类型选择合适的输出设备；比如插着有线耳机期间，音乐声（STREAM_MUSIC）只会输出到有线耳机，而铃声（STREAM_RING）会同时输出到有线耳机和外放。
六、语音通话处理流程（调试）