第一篇：高通音频调试总结

高通音频调试总结

----夏珊珊

之前会议电话项目我们设计的方案是：外部的codec内带音频处理dsp接6270模块工作。外部codec+6270与高通的codec+dsp工作方式大致相同。所以调节音频的工作原理可以以高通内部的原理来作依据。

在调节会议电话的时候我们遇到了一个很大的问题，底噪。我们在这个问题上纠结了很久。调节了mic的滤波电路，高通的AGC参数，TX,RX filter 参数，都没有明显的改善，后来我们把mic断开接地，发现tx端还是有很大的噪音，截取输入到高通的音频噪音比较明显，从而我们确定了这个噪音是由外部的codec所引入的。调整音频的时候分析噪音来源比较重要，这样相应调整各部分增益来使噪音源影响尽量减小。

对于噪音处理，发现不管使用高通的AGC压制噪音还是使用外部CODEC带的DSP处理噪音都对音质有很大的损伤。所以建议在调整音频之前先最大限度的保证结构和硬件设计的优化性，毕竟软件可以对数字噪音处理比较理想，但是对于模拟噪音就不是万能的了。具体对于噪音的处理后续会在文档中提到。

高通音频通道及调整

基本概念

回音:Near end 端不说话，far end说话了后经过上图的path，经过喇叭播放后在空中回荡，又被mic收回去，在far-end听到了自己的声音。

Echo path：从Echo Canceller出来，经过gain、a/d转换 到speaker 经外面的环境，然后又被mic收回，通过一系列的通道到Echo Canceller。

Acoustic echo path：从speaker 出来，在环境中回荡后再进mic

从上图可以看到：

如果TX进来的ECHO跟我们估测的ECHO相近，Ataptive filter相减TX进来的echo可以消除回音。

Ataptive filter：用于模拟echo。

PCD(Path Change Detect)：当使用者在移动，acoustic echo path也会改变。SPDET：用于检测是far end speaker讲话或者near end speaker，防止near end speaker讲话的时候被抑制掉

理想的状态是TX进来的echo，跟我们估测echo相近，相减就为0，但是实际上不可能，所以需要一个DENS消除非线性的回音，我们选择0~4KHZ是因为这个范围的声音是人声范围。

调整顺序：

设置音量等级和AGC gain→EC gain和 limit→codec和mic的gain→Ec parameter。高通的default volume 基本上可以使用于各个普通的场合。

AGC gain 我们首先调整外围的gain，比如tx agc、txvolume，AGC处理噪音比较有效，但是会相应的牺牲tx端的音质及音量大小。如果这个噪音会随着Rx_Volume变化，在拔出手柄或者静音Rx_CODEC_GAIN(0x0000),噪音明显减弱，那么这个噪音是数字噪音，可以使用RxAGC减弱，具体的操作方法是：

 设置Rx AGC工作在静态增益模式(compFlinkAIGFlag=0x0000); 减弱‘rx_agc_static_gain’为0dB(compFlinkStaticGain=0x2000); 增加‘rx_agc_exp_thres’ 到-40dBm0mu(expFlinkThreshold=0x1180).同样TX端的数字噪音也可以调整TX AGC 消除，调整的方式于RX AGC相同。在音频通路上，建议调整增益的地方是codectxgain 和txvolume，这样做的目的是防止送入codec处理的音频信号太大出现削顶失真，使EC无法很好的模拟回音并处理掉回音。所以我们尽量在EC处理完毕后对信号进行放大。

EC gain和limit 外围的gain调整完毕后调整EC block gain（input gain、output gain）在调整的时候，rx volume 是调整到最大处理，这样做为了避免rx 方向上声音太小，扬声器声音不够大，不易于测试回音。

Nlpp limit：当input太大的时候，rx收到的声音特别大声，但是spk不总是这么大声，这样使ECHO收到的东西太多失真，设置limit的话使突强的时候使进入EC的echo不要太多。AF limit：控制TX方向的，EC 无法收敛，或者收敛的速度太慢，收到的东西突强太多，这样使用limit 解决，用于限制突然大声的信号。

Codec及mic的gain 随后设置codec和mic的gain，文章开端曾提到若模块有噪音，噪音的来源必须找到，并相对于此来设置codec及mic的gain。我们的应用噪音是来自于codec芯片本身，所以对于mic增益的降低对噪音是没有益处的，因为噪音会随着ADC的放大而放大，衰减而减弱。Mic增益小，相对的ADCgain必须放大才能让tx端听到清晰的声音，这样反而把噪音放大了。所以为了让产生的噪音最小，我们尝试把mic的增益放大，ADC gain衰减来减弱噪音，达到比较好的效果。所以调整这部分的增益需要根据具体的情况，具体的模块相应调整。

Ec parameters 对回音来说，结构及材料也有很大的影响因素。我们在设计的时候必须要考虑到这些因素才能更好的实现音质效果。比如SPK与mic必须尽量的拉开距离；mic腔体不能太大，mic使用专门的泡膜包起来；机壳的材质最好使用吸引的材料，防止大声音播放的时候机壳震动影响mic等等，这些在前期的时候最好设计考虑到。

关于EC参数，高通有几组默认的回音参数，从Speaker phone 到bluetooth 几个等级。通常尝试的时候从普通的模式到aggressive尝试，ECHO canceller的肯定会伤害到double talk的能力，所以可以不用不压抑太多就不要压抑太多。如果尝试模式的参数没有echo，就选择压制的比较小的那组参数。总之是在Double talk 和echo canceller取得一个平衡。

细调

如果使用aggressive那组参数，echo还是没有消除，那么查找echo path delay Echo会随着echo path改变，echo path有长短。当echo path delay设置不好，会使echo收敛不好。

如果不知道要设置多少的话就先设置为0，然后慢慢向上调整。

调整进入AF的参数

调整进入AF的两个进入EC的input的大小，他们的大小关系必须在一定的范围，AF才能正常的收敛。

X[K]> Z[K]，AF才能正常的收敛。从网路端送来的信号，ECHO是从环境处理后的声音，肯定是稍微有点小，但是如果经过codec处理后就可能比X大，那么就使用Inputgain降低，然后增大OutputGain。

EC已经收敛了，如果有非线性的echo无法消除，通过设置 DENS_tail_portion： DENS_tail_alpha： DENS_NL_atteu：

这几个参数设置越大，echo 消除能力越好，但是影响double talk 高通给出的参数适用于大部分的场合，只需要在默认参数的基础上微调就可以了。这些参数的调整如果使用工具调整就比较方便了。下面就讲讲音频调试工具。

音频调试工具

音频调试工具的比较（这个是引用了钟明同学的文档，他的高通文档讲解的比较清晰了，我对其引用补充下吧 O(^_^)O）

AT Command: 引用了6100的使用的AT命令作个简要的介绍。设置回音的ECHO命令AT+ECHO和AT+ECHO1可以设置回音的28个参数。

AT+CLVL: 音量级别设置 AT+RXVOL: RX端音量设置 AT+CMUT：静音设置 AT+CMIC： mic音量设置 AT+SIDET：侧边音设置

AT+ECHO：设置手持与免提模式下的回声各个参数 AT+ECHO1：设置蓝牙耳机与普通耳机的回声参数

QACT 需要导入正确的audio_cal.xml，通常这个文件在工程里带有 使用步骤

1.配置QPST，使使端口出现在active Phones tab。

如果设备没有连接上或者XML文件导入错误，在QACT v1.x的版本会弹出这个窗口。表示只能在PC上调整，而无法在线的把数据导入到模块。

导入正确的xml文件

如果连接成功，可以看到以下图片，选择“否”，也就是不把XML 中默认的结果导到模块里面去。（我们这里只是调试，不要导入.XML 中默认的值）

我们在里面会调整的比较多的是： 调整codec的gains

Graphical拉AGC 参数，从Data获取参数

拉TX,RX filter 曲线

选择对应的path，device，拉出曲线后可见右边的7个参数，对应于代码里voc_pcm_path_cal_type结构体中的tx_iir_filter。

QACT在线调试必须通话挂机后才生效。而且拉TX,RX filter无法模拟模块里原来的声音曲线，调节音质曲线个人比较倾向于使用Qfilt。

QFILT 使用音频分析仪器获取未处理的（TX/RX filter全部设置为0）频响曲线。把这个曲线数据保存为*.EXP格式。

之前在龙旗做测试的时候发现使用仪器获取曲线数据无法直接保存为.EXP格式，保存为.ASM格式，将保存的数据去掉100之前及4000之后的数据，加上固定的格式如下：

# 09-27-06 15:32:32.49 Hz dBPa/V 100 0.239521 105.83 0.174744 112 0.105024 118.322 0.0793721 125 0.0562545 132.288 0.0526554 140 0.0522274 149.666 0.0886258 160 0.144394 169.706 0.17004 180 0.128156 189.737 0.0954074 „„„„ 3768.29 0.286294 4000 FAIL 保存为.EXP格式，红色的是RX的首尾固定格式，Tx的首尾固定格式如下：

# 09-29-06 15:05:11.04 Hz dBV/Pa „„ FAIL 使用QFILT导入对应的RX或者TX数据，导入数据之前必须配置右边的相关设置。选择Test Mode，Test Class，Test Path及Filter Type 0.676438

导入文件后的初始化曲线，这个曲线跟使用仪器测出来的频响曲线一致。

通过调整滤波曲线后的图如下：绿色是调整后的曲线，黄色的是原始的曲线，红色的滤波器的调整曲线。我们调整曲线的目的是确保调整后曲线在两条白色的曲线之间，且比较平滑。

调整到合适的曲线则点击Get Cofficients 获取调整的参数

在实际测试的时候如果把这个参数写入程序然后编译下载效率太慢了，这个时候可以直接使用QDV把这些实时的数据写入到模块，在通话的过程中实时生效，使用测试仪器测试使用调整后的参数曲线是否能通过测试。

QDV QDV使用需要导入正确的rpt文件。这个文件可以跟高通提SR获取。

之前遇到使用了错误的rpt文件导致有些参数设置不正确，所以一定要确保使用正确的文件。

启动QDV，首先看到以下的界面：

MEMA , MEMB , MEMC , MEMI值一定要设置正确，这个值可以通过查看代码获取。设置完成后进入以下界面

它的工具条如下所示

选择导入.rpt文件。

选择完.rpt文件后 点击 打开一个Text view 界面，右击选择需要修改的参数。

选择new可以导入一个新的参数。

导入后如图，选中变量后点击

可以修改变量值。

调整EC block中参数，配置完成后，必须写ecParametersUpdated使回音参数生效。如下图，设定了Echo参数后需要设置ecParametersUpdated为FFFF使其生效，设置完成后它会自动跳变为0000.同样，对于TX filtr和RX filter也需要写一个load参数（txPcmFiltLoad和rxPcmFiltLoad）FFFF使写入的参数生效，同样这个参数生效后会自动跳回0000。

第二篇：高通音频增益调试总结

高通音频调试总结

1、综述

该文档主要描述了手机打开免提通话的时候，如何解决固话端出现的啸音、噪音问题。

2、环境 项目：xxx 硬件平台：MSM7X27A 软件版本：android2.3.5, AMSS11452302

3、调试流程

（1）咨询高通FAE，明确哪些参数需要调整

FAE给出的建议是：针对啸音，调整codec_rx_gain、codec_tx_gain参数；针对杂音，调整rx_agc_static_gain、rx_agc_exp_thres、rx_agc_compr_thres、tx_agc_exp_thres、tx_agc_compr_thres参数；（2）使用QACT工具，对上述参数进行调试 QACT是高通提供的音频校准工具，可以使用该工具直接在线修改各类音频参数，调试十分方便（使用方法详见安装文件目录下的文档《80-VM407-1_E_Audio_Calibration_Tool_User_Guide.pdf》）。

使用该工具在线调试的基本思路是：适当降低增益（codec_rx_gain、codec_tx_gain），并调整AGC的门限值以及静态增益(rx_agc_exp_thres、rx_agc_compr_thres、tx_agc_exp_thres、tx_agc_compr_thres、rx_agc_static_gain参数)，以达到消除啸音、噪音的目的。在线调试完成后，还可以用这个工具将调好的audio_cal.xml文件直接生成代码，具体也请参考上述文档。（3）修改代码 代码路径：modem_proc/multimedia/audio/vocoder/src/voccal.c 在结构体voc_pcm_on_chip_speaker_cal_umts_qrd中，分别修改各个参数，代码如下：

CAL_MEMORY voc_pcm_path_cal_type voc_pcm_on_chip_speaker_cal_umts_qrd = {

VOC_EC_VER_ECNS，/* ec_version */

VOC_EC_AEC，/* ec_mode */

VOC_NS_ON，/* ns_enable */

0x656e，/* tx_gain */ 0x1000，/* dtmf_tx_gain */ // codec_tx_gain由0x71cf修改为0x2328 0x2328, /* codec_tx_gain */ // codec_rx_gain由0xb460修改为0x1770

0x1770，/* codec_rx_gain */ 0x0000，/* codec_st_gain */ …… ……

#ifdef FEATURE_AUDIO_AGC /* agc_param */ /* rx_agc_static_gain由0x8000修改为0x4000，rx_agc_exp_thres由0x1b00修改为0xe42，rx_agc_compr_thres由0x2000修改为0x1f40，tx_agc_exp_thres由0xf86修改为0x09c4，tx_agc_compr_thres由0x1bde修改为0x1964 */ { 0x4000, 0x0000, 0xe42, 0xffb0, 0x1f40, 0xffff, 0x0000, 0x0000, 0x2000, 0x0000, 0x09c4, 0xffc0, 0x1964, 0xffff }, voc_cal_adv_agc_param，voc_cal_avc_param，#endif /* FEATURE_AUDIO_AGC */ …… …… };

第三篇：高通平台常用调试Tool介绍1

高通平台的常用的调试tool: QPST, QRCT, QXDM, Trace32(use JTAG)202_年09月07日 ⁄ 综合 ⁄ 共 4410字 ⁄ 字号 小 中 大 ⁄ 评论关闭 OverView:

QPST 综合工具, 传输文件, 查看device的EFS文件系统, 代码烧录 QRCT 测试RF QXDM 看log JTAG trace32调试

QPST,QXDM的使用说明，具体的可以看我上传到csdn的资源文件，我都是看它，看了那个user guide就完全会了，很简单的

QPST是一个针对高通芯片开发的传输软件。简单的说就是用高通处理芯片的手机理论上都可以用QPST传输文件，可以修改C网机器内部参数的软件。一次可以track多台电脑 QPST还可进行代码烧入 包括:

5个 client applications Ø QPST Configuration monitor the status of: Active phones Available serial ports Active clients To start QPST Configuration, from the Start menu, select Programs → QPST → QPST Configuration.Ø Service Programming provide service programming for CDMA phones that contain Qualcomm ASICs.With it, you can save SP data to a file, then download the data in that file to multiple phones.The SP application accesses settings regardless of the phone’s internal memory implementation.It is feature-aware and displays settings pages appropriate to the phone being programmed.To start SP, from the Start menu, select Programs → QPST → Service Programming.Ø Software Download Ø RF NV Item Manager Ø EFS Explorer The EFS Explorer application lets you navigate the embedded file system(EFS)of phones that support EFS.It is similar in function to the Windows Explorer program on a PC.To start EFS Explorer, from the Start menu, select Programs → QPST → EFS Explorer.When EFS Explorer launches, it displays a Phone Selection dialog that lists the phones currently being monitored by the QPST server, as shown in Figure Creating a new directory • When you create a directory in the phone’s EFS, the directory is created on the phone and the file structure list is refreshed.To create a directory: 1.Navigate to the location where you want to create a new directory.2.From the File menu, select New → Directory.The Create Directory dialog, as shown in Figure below 3.Type a name for the file in the field.4.Click OK.Two standalone utilities,--QCNView--Roaming List Editor, complete the QPST tool set.QRCT

• QRCT is a Windows toolkit designed to control a QUALCOMM phone such as a Form Factor Accurate(FFA)for testing RF in three system modes – CDMA 202_, GSM, and WCDMA.• This application requires Advanced Mode Subscriber Software(AMSS)software with FTM built into it.The FTM mode must be enabled before using the CDMA 202_, GSM, and WCDMA RF controls.• FTM is a mode of operation that allows a user to perform diagnostic or design verification functionality by exposing functions not discretely available to the user in AMSS mode.FTM does not provide the ability to make phone calls and is not driven by the AMSS Call Processing State Machine.• QRCT uses the Qualcomm Manufacturing Support Library(QMSL)for all communication with the phone.It is possible to determine the exact function calls by monitoring the QMSL Text Log.The user can then replicate any QRCT sequence by calling QMSL in their own program.QXDM是监视手机状态的，还有一些简单的控制功能

• The QUALCOMM® Extensible Diagnostic Monitor(QXDM)provides a diagnostic client for Dual-Mode Subscriber Station(DMSS)and newer User Equipment(UE)software, Advanced Mobile Subscriber Software(AMSS).• QXDM was developed to provide a rapid prototyping platform for new diagnostic clients and diagnostic protocol packets.It provides a Graphical User Interface(GUI)that displays data transmitted to and from the DMSS.Options menu on QXDM: QXDM communications menu: • Lists all the available ports on the system and their properties • Ports listed in this are those that have been added in the QPST Configuration tool for monitoring Traces on the QXDM: JTAG

• Joint Test Action Group(JTAG)is the common name for what was later standardized as the IEEE 1149.1 Standard Test Access Port and Boundary-Scan Architecture.It was initially devised for testing printed circuit boards using boundary scan and is still widely used for this application.• Today JTAG is also widely used for IC debug ports.In the embedded processor market, essentially all modern processors support JTAG when they have enough pins.Embedded systems development relies on debuggers talking to chips with JTAG to perform operations like single stepping and break pointing.Digital electronics products such as cell phones or a wireless access point generally have no other debug or test interfaces • Used for debugging & storing firmware.

第四篇：alsa音频总结

Linux音频驱动总结

参考文章：http://blog.csdn.net/droidphone/

http://blog.chinaunix.net/uid/22917448.html

分析只列出部分重要代码，具体请参考linux3.0内核代码。

Alsa架构整体来说十分复杂，但对于驱动移植来说我们仅仅只需要关心ASOC就足够了。在学习asoc之前我们先了解一些专业术语：

ASoC currently supports the three main Digital Audio Interfaces(DAI)found on SoC controllers and portable audio CODECs today, namely AC97, I2S and PCM.ASoC现在支持如今的SoC控制器和便携音频解码器上的三个主要数字音频接口，即AC97，I2S，PCM（与pcm音频格式注意区分，前者是一种音频接口，后者是一种输入声卡的音频格式）。

AC97 AC97 ====

AC97 is a five wire interface commonly found on many PC sound cards.It is now also popular in many portable devices.This DAI has a reset line and time multiplexes its data on its SDATA_OUT(playback)and SDATA_IN(capture)lines.The bit clock(BCLK)is always driven by the CODEC(usually 12.288MHz)and the frame(FRAME)(usually 48kHz)is always driven by the controller.Each AC97 frame is 21uS long and is pided into 13 time slots.AC97是一种个人电脑声卡上常见的五线接口。现在在很多便携设备中也很流行。这个数字音频接口有一个复位线，分时在SDATA＿OUT（回放）和SDATA＿IN（捕获）线上传送数据。位时钟常由解码器驱动（通常是12.288MHz).帧时钟（通常48kHz)总是由控制器驱动。每个AC97帧21uS,并分为13个时间槽。

I2S I2S ===

I2S is a common 4 wire DAI used in HiFi, STB and portable devices.The Tx and Rx lines are used for audio transmission, whilst the bit clock(BCLK)and left/right clock(LRC)synchronise the link.I2S is flexible in that either the controller or CODEC can drive(master)the BCLK and LRC clock lines.Bit clock usually varies depending on the sample rate and the master system clock(SYSCLK).LRCLK is the same as the sample rate.A few devices support separate ADC and DAC LRCLKs, this allows for simultaneous capture and playback at different sample rates.I2S是一个4线数字音频接口，常用于HiFi，STB便携设备。Tx 和Rx信号线用于音频传输。而位时钟和左右时钟（LRC）用于同步链接。I2S具有灵活性，因为控制器和解码器都可以控制位时钟和左右时钟。位时钟因采样率和主系统时钟而有不同。LRCLK与采样率相同。少数设备支持独立的ADC和DAC的LRCLK。这使在不同采样率情况下同步捕获和回放成为可能。

I2S has several different operating modes:-I2S有几个不同的操作模式：

o I2SMSB is transmitted on transition of LRC.左对齐模式：MSB在LRC传送时传送。

o Right JustifiedMSB is transmitted on falling edge of first BCLK after FRAME/SYNC.模式A－MSB在FRAME/SYNC后第一个BCLK的下降沿传送。

o Mode Busing I2C, 3 Wire(SPI)or both APIs 3)Mixers and audio controls 4)Codec audio operations 1）解码器数字音频接口和PCM配置。

2）解码器控制IO－使用I2C，3总线（SPI）或两个都有。3）混音器和音频控制。4）解码器音频操作。

Optionally, codec drivers can also provide:-解码器驱动可以选择性提供：

5)DAPM description.6)DAPM event handler.7)DAC Digital mute control.5）动态音频电源管理描述。6）动态音频电源管理事件控制。7）数模转换数字消音控制。SoC DAI Drivers 板级DAI驱动 ===============

Each SoC DAI driver must provide the following features:-每个SoC DAI驱动都必须提供如下性能：

1)Digital audio interface(DAI)description 1)数字音频接口描述

2)Digital audio interface configuration 2)数字音频接口配置 3)PCM's description 3）PCM描述

4)SYSCLK configuration 4）系统时钟配置

5)Suspend and resume(optional)5）挂起和恢复（可选的）

以上由君子翻译，本人实在没办法比他描述的更好了，所以把重要的部分提取出来直接copy。在这里对君子表示由衷感谢，赋上君子注。君子注:

您现在所阅读的，是君子阅读Linux音频SoC驱动时，写下的文档译文。

君子写些译文，一方面是作为自己的笔记，帮助记忆，另一方面也希望能对他人有所帮助。如果您能于君子的译文中有所收获，则吾心甚慰

现在我们开始分析ASOC：

ASoC被分为Machine、Platform和Codec三大部分。其中的Machine驱动负责Platform和Codec之间的耦合和设备或板子特定的代码。

看起来挺复杂，其实需要我们做的事情并不多，大部分内核已经完成。下面我们分析哪些是我们需要自己做的：

codec驱动：负责音频解码。这部分代码完全无平台无关，设备原厂提供，我们只需要把它加进内核编译就好了。platform驱动：与处理器芯片相关，这部分代码在该芯片商用之前方案产商提供的demo板已完全确定了，也就是说我们只需要使用就可以了。

machine驱动：好了，到了最关键的地方了，machine驱动是耦合platform和codec驱动，同时与上层交互的代码。由于上层是标准的alsa架构，所以下层接口肯定要做了统一，所以我很负责的告诉你，这部分由machine本身的platform驱动和platform设备组成(请跟asoc的platform驱动区别)，platform驱动内核帮我们完成了，所以你无须过多的关心你的驱动怎么跟上层alsa怎么衍接的问题，我们只需要注册一个machine的platform设备以及完成platform和codec耦合就ok

asoc的关系图如下：（以下适应于linux3.0。linux2.6会有所不同）

上图把asoc架构显示的淋漓尽致，如果你分析了asoc你就会发现上图描述的结构以及函数真的一个都跑不了。

Machie：

Machine platform device:(~/sound/soc/samsung/smdk_wm8994.c)

1.smdk_snd_device = platform_device_alloc(“soc-audio”,-1);2.if(!smdk_snd_device)3.return-ENOMEM;4.5.platform_set_drvdata(smdk_snd_device, &smdk);6.7.ret = platform_device_add(smdk_snd_device);

1.static struct snd_soc_dai_link smdk_dai[] = { 2.{ /* Primary DAI i/f */

3..name = “WM8994 AIF1”, 4..stream_name = “Pri_Dai”, 5..cpu_dai_name = “samsung-i2s.0”, 6..codec_dai_name = “wm8994-aif1”, 7..platform_name = “samsung-audio”, 8..codec_name = “wm8994-codec”, 9..init = smdk_wm8994_init_paiftx, 10..ops = &smdk_ops, 11.}, { /* Sec_Fifo Playback i/f */

12..name = “Sec_FIFO TX”, 13..stream_name = “Sec_Dai”, 14..cpu_dai_name = “samsung-i2s.4”, 15..codec_dai_name = “wm8994-aif1”, 16..platform_name = “samsung-audio”, 17..codec_name = “wm8994-codec”, 18..ops = &smdk_ops, 19.}, 20.};21.22.static struct snd_soc_card smdk = { 23..name = “SMDK-I2S”, 24..owner = THIS_MODULE, 25..dai_link = smdk_dai，26..num_links = ARRAY_SIZE(smdk_dai), 27.};

通过snd_soc_card结构，又引出了Machine驱动的另外两个个数据结构：

  snd_soc_dai_link（实例：smdk_dai[]）snd_soc_ops（实例：smdk_ops）

snd_soc_dai_link看名字就知道，很明显它是起耦合链接作用的。它指定了Platform、Codec、codec_dai、cpu_dai的名字，稍后Machine驱动将会利用这些名字去匹配已经在系统中注册的platform，codec，dai。

snd_soc_ops连接Platform和Codec的dai_link对应的ops操作函数，本例就是smdk_ops，它只实现了hw_params函数：smdk_hw_params。

到此为止，最主要的部分machine的平台设备注册我们完成了。

下面我们关注machine平台驱动部分(这部分内核不需要我们实现，但我们需要知道它是怎么工作的）

ASoC的platform_driver在以下文件中定义：sound/soc/soc-core.c。还是先从模块的入口看起：

[cpp] view plaincopy 1.static int __init snd_soc_init(void)2.{ 3.......4.return platform_driver_register(&soc_driver);5.}

soc_driver的定义如下：

[cpp] view plaincopy

1./* ASoC platform driver */

2.static struct platform_driver soc_driver = { 3..driver = {

4..name = “soc-audio”, //确保你注册machine平台设备和它保持一致 5..owner = THIS_MODULE, 6..pm = &soc_pm_ops, 7.}，8..probe = soc_probe, 9..remove = soc_remove, 10.};

初始化入口soc_probe()

soc_probe函数本身很简单，它先从platform_device参数中取出snd_soc_card，然后调用snd_soc_register_card，通过snd_soc_register_card，为snd_soc_pcm_runtime数组申请内存，每一个dai_link对应snd_soc_pcm_runtime数组的一个单元，然后把snd_soc_card中的dai_link配置复制到相应的snd_soc_pcm_runtime中，最后，大部分的工作都在snd_soc_instantiate_card中实现，下面就看看snd_soc_instantiate_card做了些什么： 该函数首先利用card->instantiated来判断该卡是否已经实例化，如果已经实例化则直接返回，否则遍历每一对dai_link，进行codec、platform、dai的绑定工作，下只是代码的部分选节，详细的代码请直接参考完整的代码树。static int soc_probe(struct platform_device *pdev){

struct snd_soc_card *card = platform_get_drvdata(pdev);//别忘记了machine的platform_set_drvdata //取出snd_soc_card

.............ret = snd_soc_register_card(card);//注册............}

下面我们看snd_soc_register_card()函数:

int snd_soc_register_card(struct snd_soc_card *card){

。。。。

card->rtd = kzalloc(sizeof(struct snd_soc_pcm_runtime)*

(card->num_links + card->num_aux_devs)，GFP_KERNEL);//为snd_soc_pcm_runtime数组申请内存，每一个dai_link对应一个snd_soc_pcm_runtime数组单元。。。。

for(i = 0;i < card->num_links;i++)

card->rtd[i].dai_link = &card->dai_link[i];//把snd_soc_card中的dai_link复制到相应的snd_soc_pcm_runtime。。。。

snd_soc_instantiate_cards();//将调用snd_soc_instantiate_card()//最为重要 }

下面我们分析snd_soc_instantiate_card()函数：

static void snd_soc_instantiate_card(struct snd_soc_card *card){

。。。。

if(card->instantiated){ //判断该卡是否已经实例化，如果是就返回

mutex_unlock(&card->mutex);

return;

}

/* bind DAIs */

for(i = 0;i < card->num_links;i++)//否则遍例每一对dai_link，进行codec,flatrom,dai的绑定工作

soc_bind_dai_link(card, i);/* ******************************************************************************************************************************************************************

ASoC定义了三个全局的链表头变量：codec_list、dai_list、platform_list，系统中所有的Codec、DAI、Platform都在注册时连接到这三个全局链表上。soc_bind_dai_link函数逐个扫描这三个链表，根据card->dai_link[]中的名称进行匹配，匹配后把相应的codec，dai和platform实例赋值到card->rtd[]中（snd_soc_pcm_runtime）。经过这个过程后，snd_soc_pcm_runtime：（card->rtd）中保存了本Machine中使用的Codec，DAI和Platform驱动的信息。

*****************************************************************************************************************************************************************/

/* bind completed ? */

if(card->num_rtd!= card->num_links){

mutex_unlock(&card->mutex);

return;

}

。。。。。

/* card bind complete so register a sound card */

ret = snd_card_create(SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1,card->owner, 0, &card->snd_card)。。。。。

card->snd_card->dev = card->dev;

card->dapm.bias_level = SND_SOC_BIAS_OFF;

card->dapm.dev = card->dev;

card->dapm.card = card;

list_add(&card->dapm.list, &card->dapm_list);//初始化codec缓存，创建声卡实例

。。。。。。。//下面是最重要的probe匹配工作

if(card->probe){

ret = card->probe(card);

if(ret < 0)

goto card_probe_error;

}

。。。。。

ret = soc_probe_dai_link(card, i, order);//主要的耦合链接工作在此函数完成。。。。。

ret = soc_probe_aux_dev(card, i)。。。。。

if(card->late_probe){//最后的声卡初始化工作，ret = card->late_probe(card);

}

。。。。。

ret = snd_card_register(card->snd_card);//然后调用标准的alsa驱动的声卡函数进行声卡注册

。。。。。

}

到这里声卡已经注册好了，声卡可以正常工作了，我们再分析最后一个函数，也就是它们是怎么匹配的 soc_probe_dai_link():

static int soc_probe_dai_link(struct snd_soc_card *card, int num, int order){

。。。。。

/* probe the cpu_dai */

if(!cpu_dai->probed &&

cpu_dai->driver->probe_order == order){

if(!try_module_get(cpu_dai->dev->driver->owner))

return-ENODEV;

if(cpu_dai->driver->probe){

ret = cpu_dai->driver->probe(cpu_dai);

if(ret < 0){

printk(KERN_ERR “asoc: failed to probe CPU DAI %sn”, cpu_dai->name);

module_put(cpu_dai->dev->driver->owner);

return ret;

}

}

cpu_dai->probed = 1;

/* mark cpu_dai as probed and add to card dai list */

list_add(&cpu_dai->card_list, &card->dai_dev_list);

}

/* probe the CODEC */

if(!codec->probed &&

codec->driver->probe_order == order){

ret = soc_probe_codec(card, codec);

if(ret < 0)

return ret;

}

/* probe the platform */

if(!platform->probed &&

platform->driver->probe_order == order){

ret = soc_probe_platform(card, platform);

if(ret < 0)

return ret;

}

/* probe the CODEC DAI */

if(!codec_dai->probed && codec_dai->driver->probe_order == order){

if(codec_dai->driver->probe){

ret = codec_dai->driver->probe(codec_dai);

if(ret < 0){

printk(KERN_ERR “asoc: failed to probe CODEC DAI %sn”, codec_dai->name);

return ret;

}

}

/* mark codec_dai as probed and add to card dai list */

codec_dai->probed = 1;

list_add(&codec_dai->card_list, &card->dai_dev_list);

}

/* complete DAI probe during last probe */

if(order!= SND_SOC_COMP_ORDER_LAST)return 0;

。。。。。

/* create the pcm */

ret = soc_new_pcm(rtd, num);//如果上面都匹配成功将创建标准的alsa的pcm逻辑设备

。。。。。

}

好了，到此为止我们最主要的部分machine部分分析完成了。接着是codec驱动部分：

Codec简介

在移动设备中，Codec的作用可以归结为4种，分别是：

  对PCM等信号进行D/A转换，把数字的音频信号转换为模拟信号

对Mic、Linein或者其他输入源的模拟信号进行A/D转换，把模拟的声音信号转变CPU能够处理的数字信号

 对音频通路进行控制，比如播放音乐，收听调频收音机，又或者接听电话时，音频信号在codec内的流通路线是不一样的

 对音频信号做出相应的处理，例如音量控制，功率放大，EQ控制等等

ASoC对Codec的这些功能都定义好了一些列相应的接口，以方便地对Codec进行控制。ASoC对Codec驱动的一个基本要求是：驱动程序的代码必须要做到平台无关性，以方便同一个Codec的代码不经修改即可用在不同的平台上。以下的讨论基于wolfson的Codec芯片WM8994，kernel的版本3.3.x。

描述Codec的最主要的几个数据结构分别是：snd_soc_codec，snd_soc_codec_driver，snd_soc_dai，snd_soc_dai_driver，其中的snd_soc_dai和snd_soc_dai_driver在ASoC的Platform驱动中也会使用到，Platform和Codec的DAI通过snd_soc_dai_link结构，在Machine驱动中进行绑定连接。

Codec的注册

因为Codec驱动的代码要做到平台无关性，要使得Machine驱动能够使用该Codec，Codec驱动的首要任务就是确定snd_soc_codec和snd_soc_dai的实例，并把它们注册到系统中，注册后的codec和dai才能为Machine驱动所用。以WM8994为例，对应的代码位置：/sound/soc/codecs/wm8994.c，模块的入口函数注册了一个platform driver：

[html] view plaincopy

1.static struct platform_driver wm8994_codec_driver = { 2..driver = { 3..name = “wm8994-codec”, //注意machine device里面和这里保持一致 4..owner = THIS_MODULE, 5.}, 6..probe = wm8994_probe, 7..remove = __devexit_p(wm8994_remove), 8.};9.10.module_platform_driver(wm8994_codec_driver);有platform driver，必定会有相应的platform device，platform device其实在我们之前讲过的machine device注册时已经引入了。

[html] view plaincopy

1.static int __devinit wm8994_probe(struct platform_device *pdev)2.{

3.return snd_soc_register_codec(&pdev->dev, &soc_codec_dev_wm8994, 4.wm8994_dai, ARRAY_SIZE(wm8994_dai));5.}

其中，soc_codec_dev_wm8994和wm8994_dai的定义如下（代码中定义了3个dai，这里只列出第一个）：

[html] view plaincopy

1.static struct snd_soc_codec_driver soc_codec_dev_wm8994 = { 2..probe = wm8994_codec_probe, 3..remove = wm8994_codec_remove, 4..suspend = wm8994_suspend, 5..resume = wm8994_resume，6..set_bias_level = wm8994_set_bias_level, 7..reg_cache_size = WM8994_MAX_REGISTER, 8..volatile_register = wm8994_soc_volatile, 9.};

[html] view plaincopy

1.static struct snd_soc_dai_driver wm8994_dai[] = { 2.{

3..name = “wm8994-aif1”, 4..id = 1, 5..playback = {

6..stream_name = “AIF1 Playback”, 7..channels_min = 1, 8..channels_max = 2, 9..rates = WM8994_RATES, 10..formats = WM8994_FORMATS, 11.}，12..capture = {

13..stream_name = “AIF1 Capture”, 14..channels_min = 1, 15..channels_max = 2, 16..rates = WM8994_RATES, 17..formats = WM8994_FORMATS, 18.}，19..ops = &wm8994_aif1_dai_ops, 20.}, 21.......22.}

可见，Codec驱动的第一个步骤就是定义snd_soc_codec_driver和snd_soc_dai_driver的实例，然后调用snd_soc_register_codec函数对Codec进行注册。

snd_soc_register_codec（）函数是machine driver提供的，只要注册成功后codec提供的操作函数就能正常提供给machine driver使用了。int snd_soc_register_codec(struct device *dev，const struct snd_soc_codec_driver *codec_drv, struct snd_soc_dai_driver *dai_drv, int num_dai){ codec = kzalloc(sizeof(struct snd_soc_codec), GFP_KERNEL)。。。。。。

/* create CODEC component name */ codec->name = fmt_single_name(dev, &codec->id);/*Machine驱动定义的snd_soc_dai_link中会指定每个link的codec和dai的名字，进行匹配绑定时就是通过和这里的名字比较，从而找到该Codec的 */

// 然后初始化它的各个字段，多数字段的值来自上面定义的snd_soc_codec_driver的实例soc_codec_dev_wm8994： codec->write = codec_drv->write;codec->read = codec_drv->read;codec->volatile_register = codec_drv->volatile_register;codec->readable_register = codec_drv->readable_register;codec->writable_register = codec_drv->writable_register;codec->dapm.bias_level = SND_SOC_BIAS_OFF;codec->dapm.dev = dev;codec->dapm.codec = codec;codec->dapm.seq_notifier = codec_drv->seq_notifier;codec->dev = dev;codec->driver = codec_drv;codec->num_dai = num_dai;mutex_init(&codec->mutex);

/* allocate CODEC register cache */ if(codec_drv->reg_cache_size && codec_drv->reg_word_size){ reg_size = codec_drv->reg_cache_size * codec_drv->reg_word_size;codec->reg_size = reg_size;/* it is necessary to make a copy of the default register cache

* because in the case of using a compression type that requires

* the default register cache to be marked as __devinitconst the

* kernel might have freed the array by the time we initialize

* the cache.*/ if(codec_drv->reg_cache_default){ codec->reg_def_copy = kmemdup(codec_drv->reg_cache_default，reg_size, GFP_KERNEL);if(!codec->reg_def_copy){ ret =-ENOMEM;goto fail;} } }

。。。。。。/* register any DAIs */ if(num_dai){ ret = snd_soc_register_dais(dev, dai_drv, num_dai);//通过snd_soc_register_dais函数对本Codec的dai进行注册 if(ret < 0)goto fail;}

mutex_lock(&client_mutex);list_add(&codec->list, &codec_list);/*最后，它把codec实例链接到全局链表codec_list中，并且调用snd_soc_instantiate_cards是函数触发Machine驱动进行一次匹配绑定操作 */

snd_soc_instantiate_cards();mutex_unlock(&client_mutex)。。。。。}

好了，在这里我们的codec驱动也分析完了，其实这部分都是与平台无关代码，一般也不需要改动，这部分我们从设备原厂拿到代码后丢上去就可以了，只是我们在写machine device的时候要注意和这里的名字匹配。接下来是asoc的platform驱动：

Platform驱动的主要作用是完成音频数据的管理，最终通过CPU的数字音频接口（DAI）把音频数据传送给Codec进行处理，最终由Codec输出驱动耳机或者是喇叭的音信信号。在具体实现上，ASoC有把Platform驱动分为两个部分：snd_soc_platform_driver和snd_soc_dai_driver。其中，platform_driver负责管理音频数据，把音频数据通过dma或其他操作传送至cpu dai中，dai_driver则主要完成cpu一侧的dai的参数配置，同时也会通过一定的途径把必要的dma等参数与snd_soc_platform_driver进行交互。

snd_soc_platform_driver的注册

通常，ASoC把snd_soc_platform_driver注册为一个系统的platform_driver，不要被这两个想像的术语所迷惑，前者只是针对ASoC子系统的，后者是来自Linux的设备驱动模型。我们要做的就是：

  定义一个snd_soc_platform_driver结构的实例；

在platform_driver的probe回调中利用ASoC的API：snd_soc_register_platform()注册上面定义的实例；

 实现snd_soc_platform_driver中的各个回调函数；

以kernel3.3中的/sound/soc/samsung/dma.c为例：

[cpp] view plaincopy

1.static struct snd_soc_platform_driver samsung_asoc_platform = { 2..ops = &dma_ops, 3..pcm_new = dma_new, 4..pcm_free = dma_free_dma_buffers, 5.};6.7.static int __devinit samsung_asoc_platform_probe(struct platform_device *pdev)8.{ 9.return snd_soc_register_platform(&pdev->dev, &samsung_asoc_platform);10.} 11.12.static int __devexit samsung_asoc_platform_remove(struct platform_device *pdev)13.{ 14.snd_soc_unregister_platform(&pdev->dev);15.return 0;16.} 17.18.static struct platform_driver asoc_dma_driver = { 19..driver = { 20..name = “samsung-audio”, 21..owner = THIS_MODULE, 22.}, 23.24..probe = samsung_asoc_platform_probe, 25..remove = __devexit_p(samsung_asoc_platform_remove), 26.};27.28.module_platform_driver(asoc_dma_driver);snd_soc_register_platform()该函数用于注册一个snd_soc_platform，只有注册以后，它才可以被Machine驱动使用。它的代码已经清晰地表达了它的实现过程：

     为snd_soc_platform实例申请内存；

从platform_device中获得它的名字，用于Machine驱动的匹配工作； 初始化snd_soc_platform的字段；

把snd_soc_platform实例连接到全局链表platform_list中；

调用snd_soc_instantiate_cards，触发声卡的machine、platform、codec、dai等的匹配工作；

cpu的snd_soc_dai driver驱动的注册

dai驱动通常对应cpu的一个或几个I2S/PCM接口，与snd_soc_platform一样，dai驱动也是实现为一个platform driver，实现一个dai驱动大致可以分为以下几个步骤：

  定义一个snd_soc_dai_driver结构的实例；

在对应的platform_driver中的probe回调中通过API：snd_soc_register_dai或者snd_soc_register_dais，注册snd_soc_dai实例；

  实现snd_soc_dai_driver结构中的probe、suspend等回调；

实现snd_soc_dai_driver结构中的snd_soc_dai_ops字段中的回调函数；

snd_soc_register_dai 这个函数在上一篇介绍codec驱动的博文中已有介绍

具体不再分析，这个驱动也不需要用户做任务修改，所以只要知道它的作用就已经够了。就像电话机一样，我们只要知道电话怎么打就够了，至于它怎么连接我们并不太需要关心。

第五篇：户户通安装调试资料

安装操作指南

一、卫星天线的组装、将地盘圈、两根调节杆组装

2、把两片支架和馈源杆固定在一起

3、地盘圈与馈源杆组合4、将反射面固定到支架上，安装馈源夹及高频头

二、信号调试

我们接收的是中星九号卫星，位于东经92.2°，位置大约是正南方向偏西一点

1、看接收机调试

确定安装地点后，用馈线把高频头和接收机的信号输入口连接好，开机，按遥控器上的“调星”键，屏幕显示“P00”，对准西南方向，调节伸缩杆，在不同仰角度缓慢移动天线，如此循环，直至屏幕上出现绿灯，“00”变成数字，数值越高，信号越好 图9

图10

2、直接看电视调试

如果天线安装点能直接观看到电视，把天线、接收机、电视连接好，打开电视切换到AV视频状态，可以直观的看着信号质量条来移动天线

★ 接收机防护措施

◆接收机具备雷电、浪涌、静电和短路保护功能

◆电源采用日本三垦公司电源管理芯片具有过温、过负载、短路等保护功能。电源设计时冗余量大、可靠性高、效率高，工作电压范围宽（AC50-260），非常适应农村电网环境。

◆电源采用陶瓷型自恢复保险丝，进一步提高了产品的可靠性、抗雷击能力、抗浪涌冲击能力。◆电源采用先进的CMQX防雷技术。特别适用于农村、偏远山区、高原地带等雷击频繁区。★接收机整机功耗（5.0W）◆接收机整机功耗5.0W ★接收机电压动态范围

◆接收机电压动态范围50-260(AC)（详见广电总局入网检测报告）★样机外观及结构工艺

◆机器整体以白色为主、外观小巧、风格时尚大方、造型明快，线条生动简洁流畅。◆底壳采用耐指纹电解板，上盖采用喷涂板，生产过程中不喷油，达到环保要求；

◆外观工艺采用喷涂防护处理。防锈金属外壳，防辐射、防干扰，对流散热设计，散热性好；

◆样机外观整洁，表面无毛刺、凹痕、划伤、裂纹和变形；涂层不起泡、龟裂、脱落；金属件无锈蚀、损伤，标记清楚、正确 ◆在结构和工艺方面，开关、按键、旋钮灵活自如，标记清晰，机内零部件牢固无松动，印制板无断裂、划痕，机内布线合理，无飞线和金属异物。

★接收机防尘防潮设计 ◆机壳开放侧孔

◆上盖采用封闭式防尘设计，所有按键为塑料按键，防静电级别高；

◆为避免潮湿、高温、霉菌、盐雾等情况对电路的损害，在线路板（主板和电源板）制作时涂覆绝缘漆等防潮措施 ★接收机散热设计

◆接收机机壳材料采用导热性、散热性良好的金属材料；机壳散热孔的布局合理，与主板、电源板协调布置 ★接收机机壳材质 ◆壳顶采用金属防锈基材；

◆底壳采用耐指纹电解板，上盖采用喷涂板，生产过程中不喷油，达到环保要求； ★遥控器

◆遥控器的功能、按键、布局和外观符合GD/J039-202_《卫星直播系统综合接收解码器用红外遥控发射器技术要求和测量方法》的要求 ★电缆接头

◆采用F型接头；接头工艺良好，接头与电缆连接紧密并进行防水处理 ★使用手册

◆每套设备均提供一套完整的用户使用手册，其中应包括设备安装操作步骤或图示、使用指南或说明、故障处理说明等内容

卫星直播“村村通”数字电视平台及应用（上）

浏览 4253 次

摘要：本文简要的对卫星直播的相关情况进行了介绍，并对当前卫星直播采用的标准及优势特点进行了分析，对当前卫星直播应用过程中的一些问题做了简要的说明，对发展卫星直播遇到的相关问题做了简要的概述。

引言

目前我国数字电视接入主要分为地面数字电视(DVB-T)、有线数字电视(DVB-C)、移动多媒体广播、IPTV等广播多种接入方式，各种接入方式在不同的地域分别发挥着重要的作用。目前，我国尚未实现广播电视覆盖，收听、收视不到广播电视节目的人口约有2亿，基本分布于自然环境较差的老少边穷地区。根据广电总局的统计,近几年来广播电视覆盖率的增长幅度按人力财力投入计算，用常规方法建设地面传输转播系统提高覆盖率，广播每增长一个百分点要投入20多亿元人民币，电视每增长一个百分点要投入30多亿元人民币，成本非常高昂。而中国广播电视直播卫星“村村通”系统是我国“十一五”期间的重要项目之一，旨在采用直播卫星技术扩大我国农村地区广播电视覆盖，解决全国已通电但广播电视不通达的20户以上自然村收听收看广播电视节目的问题，是一个公益性节目平台，直接服务于社会主义新农村建设，这对于老少边穷等地区的广播电视的覆盖是最有效的手段。因此发展卫星直播电视直接到户成为了老百姓收看电视节目的强烈需求。

一、什么是卫星直播

卫星直播DBS(Direct Broadcasting Satelite)，以下简称卫星直播，它是利用地球同步轨道卫星，将音频、视频、多媒体数据等进行点对点传送(包括“个体接收”或“集体接收”)的一种卫星传输模式，接收者只需要使用小型卫星接收天线，即可收到来自卫星的电视或广播节目。直播卫星具有能够全面覆盖某一国家或地区，而且能够实现双向数据传输，因为直播卫星的功率远远大于传统通信卫星，所以直播卫星天线对口径的要求较小，造价更加低廉。而传统通信卫星则主要是通过卫星进行点对点(或多点)传输，把节目传送给地面广播台或有线电视台转播，属于固定卫星业务。

二、我国卫星直播的简要发展史

202_年初，通过慎重、充分的论证，经国家发展改革委批复，我国正式启动了开展卫星直播的相关工作。该项工作的开展，可以极大地提高我国广播电视的覆盖水平，增强广播电视的服务能力，促进包括卫星设计与制造技术、节目传输技术、安全播出技术等在内的技术研究水平的提升，推动相关的产品制造、服务行业的发展与产业升级。作为一种有效的传输手段的同时，卫星直播也面临着来自运营、产业、管理、安全等诸多方面的需求。我国的卫星直播系统必将是一个用户规模庞大、管理严格且相对封闭的系统。在这样一个系统中，简单地采用国外技术标准或产品对我国卫星广播电视的有效管理、播出安全、产业发展等都将造成不利的影响。早在202_年，我国自行研制的首颗直播卫星“鑫诺二号”成功发射升空，代表着一个巨大的直播卫星节目市场拉开了大幕。但令人遗憾的是，“鑫诺二号”升空后，太阳板的二次展开和通信天线的展开都未能完成，无法进行其原先预定的工作。由于种种原因，卫星直播数字电视迟迟未能启动，直到今年6月9日“中星九号”广播电视直播卫星已在西昌的成功升空并成功定位测试，“中星九号”直播卫星将弥补“鑫诺二号”所留下的遗憾，这意味着中国将进入电视卫星直播的时代。

三、我国发展直播星业务优势

1．直播卫星电视传输不受地理环境限制

直播卫星系统可以使包括广大偏远地区农村用户在内的全国97%以上的居民不经电视差转台，直接使用直径0.45～0.6m的圆形天线收听、收看广播电视节目。对于我国地形复杂，人口众多而又分布不均、经济发展不平衡的国情特点来说，利用卫星直播电视技术传输广播电视节目是提高我国广播电视人口覆盖率、改进信号传输质量、避免与境外节目共星，并且可以实现节目有偿收视的最有效、最经济、最先进的手段。

2．我国直播星电视业务潜在用户市场广阔

根据国家广电总局的最新统计数字，目前我国全国广播人口综合覆盖率为94.48%，电视人口综合覆盖率为95.81%，有线电视入户率仅为36.01%，我国还有相当一部分地区听不到广播，看不到电视。这部分电视用户多集中在农村或者边远地区，采用有线和微波手段加强覆盖都不是理想的办法。有了直播卫星，只需为用户提供直径0.5m的天线和接收设备，利用卫星相对覆盖率广、传输频道多、信号效果好的多方面优势，我们就可以解决广播电视信号覆盖问题，而且用户接收到的还是频道多、效果好的数字电视。因此，直播卫星电视正好切中市场需求，市场前景广阔。

3.直播卫星可有效缓解电视频道的落地问题

由于各地网络资源渐趋紧张，上星电视频道在各地有线网络的落地费节节高涨，落地困难意味着一些卫视频道将不得不面对有限、甚至是趋于萎缩的用户市场，严重阻碍了电视市场的发展。直播卫星是直接面对受众用户进行广播的传输模式，省去了地方电视差转台的转播环节，大大节省了上星电视频道的落地费用，为优秀的电视频道节目提供了更为广阔的收视市场。4．直播星业务价格优势明显

比起IPTV、数字电视动辄上亿的网络改造投资来说，一颗直播卫星的制造及发射费用在20亿元人民币左右，每年的卫星保险以及运营费用在7000万左右，尽管卫星的研发、发射和运营维护成本也很高，但通过收取丰厚的转发器租用费，最终转嫁到用户身上的成本并不高，这样用户用较低的价格就可体验到数字电视的乐趣。直播星转播现在所有的省级卫视和中央台的节目，作为公益性频道，通过收取转播费来维持直播星的基本运转。对受众用户来说，不用交纳服务费用即可免费收看40多套数字电视节目。四．卫星直播 “村村通系统”组成

中星9 号卫星采用国际电信联盟（ITU）规定的卫星广播业务（BSS）专用Ku波段，以大功率向地面广播播出，“村村通”用户使用45厘米左右的小口径天线、专用高频头和直播卫星专用机顶盒即可直接接收。

五、中星9号介绍 1．中星9号主要性能指标

中星9号定位于东经92.2°轨位上，星上搭载22路大功率Ku转发器，其中1A、2A、1B、2B为54MHz带宽转发器，其余为36MHz带宽转发器。一期直播卫星“村村通”业务采用四个36MHz 转发器进行传输，每个传输流的总码率为43.2 Mbps，其中电视业务总码率为39.94 Mbps、广播业务总码率为1.54 Mbps、其它数据业务为1.72 Mbps。行波管放大器功率为191瓦，工作于BSS频段：上行17.3、17.8 GHz，下行11.7、12.2 GHz，具有2副接收天线和2副发射天线；下行覆盖中国行政区域EIRP值为49.2～57.5dBW（南中国海除外），中东部地域大于52dBW，覆盖中国90%以上人口，东南沿海雨衰较大区域在56dBW以上，喀什、拉萨等地约50dBW，新疆地区为49.2～50dBW，接收天线以0.6米为主。

中星9号一期“村村通”直播卫星系统具备播出48套标准清晰度数字电视节目；48 套立体声广播节目和数据广播业务的能力；为使广大农村用户能够方便快捷地收看感兴趣的节目，直播卫星“村村通”系统提供电子节目指南功能，并可提供远程软件升级服务、提供广播和电视节目的名称、播出时间等相关导视信息、提供3～7天的节目单和当前以及下一个节目的相关信息。一期直播卫星“村村通”节目采用透明方式传输，直播卫星“村村通”机顶盒暂不预置条件接收系统。

卫星直播“村村通”系统节目流参数：平台包含4个传输流，对应4套编码复用系统，每个传输流包含12 套电视节目、12 套广播节目、数据广播、EPG 以及机顶盒升级数据编码，采用四个36MHz 转发器进行传输，每个传输流的总码率为43.2Mbps，其中电视业务总码率为39.94 Mbps、广播业务总码率为1.54 Mbps、其它数据业务为1.72 Mbps。下行中心频率：直播卫星下行中心频率为：11.84GHz、11.88GHz、11.92GHz、11.96GHz，下行极化为左旋圆极化。信号采用QPSK 方式调制、信道编码率为3/

4、滚降系数为0.25、符号率为28.8Msps。2．中星9号采用的传输标准及其特点

中星9号采用的传输标准简介：卫星直播 “村村通”信道编码采用效率更高、拥有国内自主知识产权、具有国际先进水平的ABS-S（Advanced Broadcasting System-Satellite）标准。采用ABS-S的特点：

(1)完全自主知识产权、与境外卫星采用的传输标准不兼容，可限制村村通用户接收其他卫星上的境外节目，确保卫星直播系统的安全性。

(2)直播卫星抗干扰特性

(3)满足国家广播电视信息传输的安全要求(4)有效避免境外和敏感地区上行信号的恶意干扰

(5)区域或点波束能保证广播电视在重点城市集中上行的需求(6)卫星上行波束具备全国波束与区域或点波束之间的切换功能

(7)ABS-S接收能力明显优于目前普遍使用的DVB-S系统，如在同等信号传输能力条件下，ABS-S载噪比门限要求比DVB-S低1.5到2dB；而在同等信道条件下，ABS-S的信号传输能力高于DVB-S系统20-25%。

(8)ABS-S在性能上与DVB-S2基本相当，载噪比门限相差约0.1-0.3分贝，接近理论极限，而传输能力则略高于DVB-S2。同时ABS-S的复杂度远低于DVB-S2，更加易于实现。

(9)一期直播卫星“村村通”信源视频编码采用现行国家标准GB/T 17975.2-202_《信息技术 运动图像及其伴音信息的通用编码 第2部分：视频》，信源音频编码采用现行国家标准GB/T 17191.3-1997《信息技术 具有1.5Mbit/s数据传输率的数字存储媒体运动图像及其伴音的编码 第3部分：音 频 》及 GB/T 17975.3-202_《信息技术 运动图像及其伴音信息的通用编码 第3部分：音频》进行信号传输。(10)MPEGⅡ通用编码方式，提供主类主级（MP@ML）清晰度。

(11)一期“村村通”卫星直播采用不加密方式传输节目，用户只要安装卫星地面接收设施就可收看到48套免费的标清数字电视节目。

(12)采用圆极化，用户接收天线不需要进行极化方向调整，可实现非专业人员的安装，有利于占人口大多数的农村用户和边远地区用户安装使用。

卫星直播“村村通”数字电视平台及应用（下）

浏览 4230 次

（上接卫星直播“村村通”数字电视平台及应用（上））

五、直播卫星接收的几个常见问题

1．为什么传统的DVB-S接收机无法接收直播星节目。

由于传统的卫星节目接收是采用的DVB-S标准，而“中星九号”采用的是拥有国内自主知识产权、具有国际先进水平的ABS-S标准。它采用先进的信道编码方案、合理高效的传输帧结构等技术，效率更高。采用此标准的目的一方面是可以有效的防止受到其他信号的攻击，另一方面也可对关健器件、设备进行有效控制，达到卫星安全的目的。与以前的DVB-S标准完全不兼容，所以用以前的DVB-S接收机无法进行接收。2．使用ABS-S芯片的接收机有什么特点？

接收机采用的ABS-S芯片首先是拥有自主知识产权的芯片，不必交纳昂贵的版权费用；其次，在很多性能方面也优于DVB-S2。如功耗比DVB-S2低50%，需芯片的速率却高出50%，并且支持QPSK和8PSK模式，提供45SMPS符号率和最高120MBPS的净码率，可实现搭载15路～200套高清卫星电视节目的传输。3．为什么可用更小口径的天线接收直播节目？

由于ABS-S在性能上与DVB-S2基本相当，具有更低的载噪比门限要求(相差约0.1-0.3分贝)和更强的节目传输能力。在适应性上，ABS-S标准还提供了14种不同的编码调制方案，结合多种滚降系数选择，可最好地适应不同的业务和应用需求，充分发挥系统效率。因此选用的天线可比传统的天线口径更小。4．为什么采用使用左圆极化方式？

根据国际电联1977年的规定，广播卫星使用圆极化方式。尽管WRC-97增加了卫星广播业务规划的线极化选择方式，但国际电联仍建议在卫星广播业务规划中采用圆极化方式；而技术分析表明，在92.2°E轨道位置使用圆极化方式具有传输优势；此外，圆极化有利于开展移动接收业务；从技术角度来讲，圆、线极化均可实施，但使用圆极化可以实现接收天线非专业人员的安装操作，这将极大方便终端用户的使用，同时也有利于广播业务市场的推广应用；再者，中国目前在92.2°E不具有适用的FSS网络资源，不具有延续FSS网络传输方式的继承性，所以不必跟随采用欧洲模式；鉴于目前覆盖我国的境外线极化卫星电视节目的传输现状，圆极化接收系统对接收境外非法电视节目内容也有一定的抑制作用；还有一点，使用圆极化更易于实现双星同轨、同频，互为备份。5．接收卫星直播节目主要受哪些条件影响？

(1)由于卫星直播采用是Ku频段(上行17.3、17.8 GHz，下行11.7、12.2 GHz)，这个频段电波受雨、雪、冰、霜的影响较大，雨衰会导致信号马赛克直至中断，影响用户对卫星直播电视节目的接收质量，所以在选择卫星接收天线口径时应留一定的余量，保证异常气候条件下的正常收视。

(2)由于电波的直线传播，天线建筑物上放置位置也十分重要，特别是在高楼大厦的城市以及地形多山的地方，这个问题会更为突出，所以在安装时尽量选择空旷、无阻挡的方位进行安装，细心调试，使接收到的信号质量达到较好的水平。

六、直播星专用接收设备的一般要求 1．对接收天线的要求

因天线口径小，因此一般要求抛物面一次成型，具有精度高，抗风强，结构简单、牢固，适用各类房型安装，表面采用复合喷涂工艺，防风沙、酸雨、超强吸收工艺处理，高效防止日光反射及防止环境口音对天线信号的影响，对星定位标设计型设计，添加防止老化，腐蚀的高分子材料，有效防水。2．对高频头的要求

采用圆极化设计，便于安装，准确对星，核心电路用进口器件，具有高增益，低噪声的特点。3．对接收机的要求

中星9号卫星现在主要是服务于广大的农村及偏远山区，用于村村通节目的传送，所在在直播专用机必须是一款符合中国广播电视直播卫星“村村通”机顶盒的软件功能及硬件性能指标的数字卫星接收机，其解调性能符合ABS-S规定的调制信号。采用专用电路设计，降低功耗，减少用户使用成本，采用高灵敏度调谐电路设计，增强雨雪天气节目接收质量。考虑到农村电源电源的波动大，电源一般要求进行宽电压设计，提高抗干扰能力和可靠性，以适应各类电力环境。能支持强大的节目管理功能。具有掉电记忆功能。在接口方面一般要求一路左右声道音频输出、两路复合视频输出、一路S-VIDEO输出和一路RF输出，能满足广大村村通用户的收视要求，并能通过RS232串口或通过卫星进行远程升级。

七、卫星直播“村村通”平台的发展及延伸

从资源角度来看，中星9号共拥有22路大功率的转发器，其中工作于卫星广播业务频段的18个36MHz、4个54MHz Ku波段转发器，能够提供150～200套标准清晰、高清晰度的数字电视节目通道，除免费广播40多套节目外，还可能更多的是靠加密节目来运营；从卫星运营成本来看，直播星升空后每年的卫星保险以及运营费用在7000万左右，如果不尽快明确运营模式，势必造成卫星资源的浪费，也会对直播卫星运营商空间段运营造成巨大的财务压力。因此，延伸卫星直播平台的发展空间十分必要，在这个过程中，需解决好以下问题。

1．配套政策的支持。1993年10月，国务院颁布了《卫星电视广播地面接收设施管理规定》的“129号令”，规定“国家对卫星地面接收设施的生产、进口、销售、安装和使用均实行许可证制度，个人禁止自行接收卫星电视。” 与此同时，全球卫星广播电视产业进入了高速发展阶段。目前，付费卫星直播频道超过3000个，产业规模已达千亿美元。因此直播节目个人接收的解禁以及卫星直播业务的进一步发展相关配套接收政策的落实是发展卫星直播关健的因素之一。

2．坚持有线、地面与卫星需要协同发展。直播卫星计划的主要目的是解决覆盖问题，提高我国电视广播覆盖率，提高节目收视质量，解决我国边远和农村地区群众收看电视难的问题，对部分偏远农村个别有更高收视要求(除收看47套的免费以外的节目)的用户能通过有条件接收方式进行自主收看，做了点面兼顾，进一步充分利用直播卫星的资源。

3．丰富业务内容。除传统基本广播电视业务外，直播星还能提供卫星数字音频广播移动接收业务、高清晰数字电视业务、互动电视付费点播业务、多媒体移动接收业务、3G融合业务等。现在的“村村通”直播节目是作为公益性节目免费开放，其真正的商用价值还不能很好的体现，因此在节目源方面还应下大功夫，必须打造出一系列具有观赏性、特色鲜明、极富个性的高质量节目，同时开展各类增值业务，如数据广播、电子节目菜单、天气预报、金融信息、视频点播等等，而不是简单的累加节目数量，以满足不同用户特殊需求的高清晰度电视服务。

八、结束语

目前已有北美洲、南美洲、欧洲、亚洲、大洋洲、非洲的30多个国家和地区开展了卫星直播业务，其中美国、英国和日本是目前直播卫星业务开展得最好的国家。截至202_年底，美国两大直播卫星电视运营商签约用户约3000万，基本已经占到美国电视用户总数的1/3，英国最大的卫星直播电视运营商BSkyB已有用户900万，日本的Sky PeRFecTV发展直播卫星用户450万。直播卫星业务不仅在这些地区产生了巨大的经济效益，推动了相关技术和产业的快速发展，也有力的促进了行业竞争，因此我们应该抓住“中星9号”卫星直播这个契机，出台各类配套政策，理顺各方关系，认真做好卫星直播业务的定位，让直播业务能够持续健康的发展，真正的跨入卫星直播的新纪元。

参考文献

[1] 《中国广播电视直播卫星“村村通”系统技术体制白皮书》，202_ [2] 亚洲卫视《我国卫星直播领域的相关技术标准》，202_ [3] 《卫星与网络》杂志 王兆合，202_年

[4] 卫星电视情报站 《中星9号为什么使用左圆极化方式》，202_