ARM920T是ARM公司系列微处理器核的一种，它采用5阶段管道化技术，同时配备了Thumb扩展、Embedded ICE调试技术和Harvard总线。在生产工艺相同的情况下，性能可达ARM7TDMI的2倍以上。S3C2410是Samsung公司采用0.18 μm工艺制造的ARM9TDMI核微处理器。它有独立的16KB指令Cache、16KB数据Cache和MMU，这一特性使得开发人员可以直接将Linux移植到基于该处理器的目标系统中。

　　ⅡS(Inter-IC Sound)总线是Philips公司提出的串行数字音频总线协议。它是一种面向多媒体的音频总线，专用于音频设备之间的数据传输，为数字立体声提供序列的连接至标准编解码器。ⅡS总线只处理声音数据。其他信号(如控制信号)必须单独传输。为了使电路的引出引脚尽可能少，ⅡS只使用了3条串行总线：提供分时复用功能的数据线、字段选择线和时钟信号线。

　　整个音频系统的硬件部分主要是CPU和CODEC的连接与实现。本系统采用Philips基于ⅡS音频总线的UDAl34l型音频CODEC。该CODEC支持ⅡS总线数据格式，采用位元流转换技术进行信号处理，具有可编程增益放大器(PGA)和数字自动增益控制器(AGC)。

　　S3C2410内置ⅡS总线接口，可直接外接8/16比特的立体声CODEC。它还可以给FIFO通道提供DMA传输模式而非中断模式，从而使数据发送和接收同时进行。该ⅡS接口有3种工作方式，可以通过设置ⅡSCON寄存器来选择。本文介绍的硬件框架基于传输和接收模式。在这种模式下，ⅡS数据线将通过双通道DMA同时接收和发送音频数据，DMA服务请求由FIFO只读寄存器自动完成。S3C2410支持4通道连接系统总线(AHB)和外围总线(APB)的DMA控制器。表1列出S3C2410的各通道请求源。

　　为了实现音频数据的全双工传输，需要使用S3C2410的通道1和通道2：接收数据选择通道1和发送数据选择通道2。S3C2410的DMA控制器没有内置的DMA存储区域，因而程序中必须为音频设备分配DMA缓存区，通过DMA直接将需要回放或录音的数据放在内存的DMA缓存区中。

      如图1所示，S3C2410的ⅡS总线信号与U-DAl34l的ⅡS信号直接相连。L3接口的引脚L3MODE、L3CLOCK和L3DATA分别连接到S3-C2410的GPBl、GPB2和GPB3通用数据输出引脚。UDAl34l对外提供两组音频信号输入接口，每组包括左右2个声道。

      如图2所示，2组音频输入在UDAl34l内部的处理存在很大差别：第一组音频信号输入后经过1个0 dB/6 dB开关后采样送入数字混音器；第二组音频信号输入后先经过可编程增益放大器(PGA)，然后再进行采样，采样后的数据要再经过数字自动增益控制器(AGC)送入数字混音器。设计硬件电路时选用第二组输入音频信号。因为希望通过软件的方法实现对系统输入音量大小的调节，显然选用第二组可以通过L3总线接口控制AGC来实现。另外，选择通道2还可以通过PGA对从NIC输入的信号进行片内放大。

　　由于ⅡS总线只处理音频数据，因此UDAl34l还内置了用于传输控制信号的L3总线接口。L3接口相当于混音器控制接口，可以控制输入/输出音频信号的低音及音量大小等。L3接口接在S3C2410的3个通用GPIO输入输出引脚上，利用这3个I/O口模拟L3总线的全部时序和协议。这里一定要注意L3总线的时钟不是连续时钟，它只在数据线上有数据时才发出8个周期的时钟信号，其他情况下时钟线始终保持高电平。

　　设备驱动程序是操作系统内核和机器硬件之间的接口，为应用程序屏蔽了硬件细节。设备驱动是内核的一部分，主要完成以下功能：设备初始化和释放；设备管理，包括实时参数设置及提供对设备的操作接口；读取应用程序传送给设备文件的数据并回送应用程序请求的数据；检测和处理设备出现的错误。

　　音频设备驱动程序主要通过对硬件的控制实现音频流的传输，同时向上层提供标准的音频接口。笔者设计的音频接口驱动向上提供2个标准接口：数字音频处理(Digital Sound Processing-DSP)，负责音频数据的传输即播放数字化声音文件和录音操作等；混音器(MIXER)，负责对输出音频进行混音处理，如音量调节、高低音控制等。这2个标准接口分别对应设备文件dev/dsp和dev/mixer。

　　整个音频驱动的实现分为初始化、打开设备、DSP驱动、MIXER驱动和释放设备等部分。

3．1设备初始化

　　设备初始化主要完成对UDAl34l音量、采样频率、L3接口等的初始化，并且注册设备。通过函数audio_init(void)完成以下具体功能：

　　· S3C2410控制端口(GPBl-GPB3)的初始化；

　　· 为设备分配DMA通道；

　　· UDAl34l的初始化；

　　· 注册audio设备和mixer设备。

　　· 打开设备由打开函数open()完成以下功能；

　　· 设置好ⅡS和L3总线；

　　·  准备好声道、采样宽度等参数并通知设备；

　　· 根据采样参数计算出缓冲区大小；

　　· 分配相应大小的DMA缓冲区供设备使用。

3．2DSP驱动的实现

　　DSP驱动实现了音频数据的传输即播放和录音的数据传输。同时提供ioctl对UDA134l中的DAC和ADC采样率进行控制。采样率的控制主要是读写UDAl34l内的采样率控制寄存器，所以驱动的主要部分就是控制音频数据的传输。

　　驱动中通过结构static audio_state来描述整个音频系统的状态，其中最主要的是2个数据流结构audio_in和audio_out。这2个数据流结构分别描述输入音频流和输出音频流的信息。通过对audio_in和audio_out的操作分别实现音频的输入和输出(音频的播放和录音)，本驱动的主要内容是数据流结构的设计和实现。该结构应该包含音频缓冲区的信息、DMA的相关信息、所用到的信号量及FIFO的入口寄存器的地址。

　　为了提高系统的吞吐量，系统使用DMA技术直接将需要回放或录制的声音存放在内核的DMA缓存区中，由于S3C2410的DMA控制器没有内置的DMA存储区域，因而驱动程序必须在内存内为音频设备分配DMA缓存区。缓冲区设置是否合理非常关键。以write()函数为例，因为音频数据量通常较大，而缓存太小容易造成缓存溢出，所以要采用较大的缓冲区。而要填充大的缓冲区，CPU就要一次处理大量的数据，这样处理数据时间较长，容易造成延迟。笔者采用多个缓存的机制，将缓冲区分为多个数据段。数据段的个数和大小分别在数据流结构中指定。这样把大的数据段分为几个小段处理，每处理一小段数据就可以通过DMA发送出去。read函数也是如此，DMA每发来一小段数据就可以处理，不用等到大缓冲区都填满才处理数据。这里还提供了ioctl接口给上层调用，这样上层可以根据音频数据的精度即数据流量来调整缓冲区数据段的大小和个数，以取得最好的传输效果。

3．3MIXER驱动的实现

　　MIXER驱动只控制混音效果，并不执行读写操作，所以MIXER的文件操作结构只实现了1个ioctl调用，提供给上层设置CODEC的混音效果。驱动中主要实现了1个结构体struct UDAl34l_codec。该结构体描述了CODEC的基本信息，主要是实现了CODEC寄存器的读写函数和混音的控制函数。MIXER文件操作结构中的ioctl就是调用U-DAl341_codec中的混音控制函数来实现的。

3．4 设备的卸载

　　设备的卸载由注销函数close()来完成。注销函数使用注册时得到的设备号，同时释放驱动程序使用的各种系统资源，如DMA和缓冲区等。

      本文使用S3C2410和LINUX构建嵌入式系统，通过ⅡS音频总线与UDAl341型CODEC构成一种音频系统，并给出相关硬件电路的说明及Linux下音频驱动程序的设计要点，实现了音频的播放和采集。