第一篇：alsa音頻總結(jié)

Linux音頻驅(qū)動總結(jié)

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

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

分析只列出部分重要代碼，具體請參考linux3.0內(nèi)核代碼。

Alsa架構(gòu)整體來說十分復(fù)雜，但對于驅(qū)動移植來說我們僅僅只需要關(guān)心ASOC就足夠了。在學(xué)習(xí)asoc之前我們先了解一些專業(yè)術(shù)語：

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現(xiàn)在支持如今的SoC控制器和便攜音頻解碼器上的三個主要數(shù)字音頻接口，即AC97，I2S，PCM（與pcm音頻格式注意區(qū)分，前者是一種音頻接口，后者是一種輸入聲卡的音頻格式）。

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 divided into 13 time slots.AC97是一種個人電腦聲卡上常見的五線接口?，F(xiàn)在在很多便攜設(shè)備中也很流行。這個數(shù)字音頻接口有一個復(fù)位線，分時在SDATA＿OUT（回放）和SDATA＿IN（捕獲）線上傳送數(shù)據(jù)。位時鐘常由解碼器驅(qū)動（通常是12.288MHz).幀時鐘（通常48kHz)總是由控制器驅(qū)動。每個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線數(shù)字音頻接口，常用于HiFi，STB便攜設(shè)備。Tx 和Rx信號線用于音頻傳輸。而位時鐘和左右時鐘（LRC）用于同步鏈接。I2S具有靈活性，因為控制器和解碼器都可以控制位時鐘和左右時鐘。位時鐘因采樣率和主系統(tǒng)時鐘而有不同。LRCLK與采樣率相同。少數(shù)設(shè)備支持獨立的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）解碼器數(shù)字音頻接口和PCM配置。

2）解碼器控制IO－使用I2C，3總線（SPI）或兩個都有。3）混音器和音頻控制。4）解碼器音頻操作。

Optionally, codec drivers can also provide:-解碼器驅(qū)動可以選擇性提供：

5)DAPM description.6)DAPM event handler.7)DAC Digital mute control.5）動態(tài)音頻電源管理描述。6）動態(tài)音頻電源管理事件控制。7）數(shù)模轉(zhuǎn)換數(shù)字消音控制。SoC DAI Drivers 板級DAI驅(qū)動 ===============

Each SoC DAI driver must provide the following features:-每個SoC DAI驅(qū)動都必須提供如下性能：

1)Digital audio interface(DAI)description 1)數(shù)字音頻接口描述

2)Digital audio interface configuration 2)數(shù)字音頻接口配置 3)PCM's description 3）PCM描述

4)SYSCLK configuration 4）系統(tǒng)時鐘配置

5)Suspend and resume(optional)5）掛起和恢復(fù)（可選的）

以上由君子翻譯，本人實在沒辦法比他描述的更好了，所以把重要的部分提取出來直接copy。在這里對君子表示由衷感謝，賦上君子注。君子注:

您現(xiàn)在所閱讀的，是君子閱讀Linux音頻SoC驅(qū)動時，寫下的文檔譯文。

君子寫些譯文，一方面是作為自己的筆記，幫助記憶，另一方面也希望能對他人有所幫助。如果您能于君子的譯文中有所收獲，則吾心甚慰

現(xiàn)在我們開始分析ASOC：

ASoC被分為Machine、Platform和Codec三大部分。其中的Machine驅(qū)動負責(zé)Platform和Codec之間的耦合和設(shè)備或板子特定的代碼。

看起來挺復(fù)雜，其實需要我們做的事情并不多，大部分內(nèi)核已經(jīng)完成。下面我們分析哪些是我們需要自己做的：

codec驅(qū)動：負責(zé)音頻解碼。這部分代碼完全無平臺無關(guān)，設(shè)備原廠提供，我們只需要把它加進內(nèi)核編譯就好了。platform驅(qū)動：與處理器芯片相關(guān)，這部分代碼在該芯片商用之前方案產(chǎn)商提供的demo板已完全確定了，也就是說我們只需要使用就可以了。

machine驅(qū)動：好了，到了最關(guān)鍵的地方了，machine驅(qū)動是耦合platform和codec驅(qū)動，同時與上層交互的代碼。由于上層是標準的alsa架構(gòu)，所以下層接口肯定要做了統(tǒng)一，所以我很負責(zé)的告訴你，這部分由machine本身的platform驅(qū)動和platform設(shè)備組成(請跟asoc的platform驅(qū)動區(qū)別)，platform驅(qū)動內(nèi)核幫我們完成了，所以你無須過多的關(guān)心你的驅(qū)動怎么跟上層alsa怎么衍接的問題，我們只需要注冊一個machine的platform設(shè)備以及完成platform和codec耦合就ok

asoc的關(guān)系圖如下：（以下適應(yīng)于linux3.0。linux2.6會有所不同）

上圖把asoc架構(gòu)顯示的淋漓盡致，如果你分析了asoc你就會發(fā)現(xiàn)上圖描述的結(jié)構(gòu)以及函數(shù)真的一個都跑不了。

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結(jié)構(gòu)，又引出了Machine驅(qū)動的另外兩個個數(shù)據(jù)結(jié)構(gòu)：

? ? snd_soc_dai_link（實例：smdk_dai[]）snd_soc_ops（實例：smdk_ops）

snd_soc_dai_link看名字就知道，很明顯它是起耦合鏈接作用的。它指定了Platform、Codec、codec_dai、cpu_dai的名字，稍后Machine驅(qū)動將會利用這些名字去匹配已經(jīng)在系統(tǒng)中注冊的platform，codec，dai。

snd_soc_ops連接Platform和Codec的dai_link對應(yīng)的ops操作函數(shù)，本例就是smdk_ops，它只實現(xiàn)了hw_params函數(shù)：smdk_hw_params。

到此為止，最主要的部分machine的平臺設(shè)備注冊我們完成了。

下面我們關(guān)注machine平臺驅(qū)動部分(這部分內(nèi)核不需要我們實現(xiàn)，但我們需要知道它是怎么工作的）

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平臺設(shè)備和它保持一致 5..owner = THIS_MODULE, 6..pm = &soc_pm_ops, 7.}，8..probe = soc_probe, 9..remove = soc_remove, 10.};

初始化入口soc_probe()

soc_probe函數(shù)本身很簡單，它先從platform_device參數(shù)中取出snd_soc_card，然后調(diào)用snd_soc_register_card，通過snd_soc_register_card，為snd_soc_pcm_runtime數(shù)組申請內(nèi)存，每一個dai_link對應(yīng)snd_soc_pcm_runtime數(shù)組的一個單元，然后把snd_soc_card中的dai_link配置復(fù)制到相應(yīng)的snd_soc_pcm_runtime中，最后，大部分的工作都在snd_soc_instantiate_card中實現(xiàn)，下面就看看snd_soc_instantiate_card做了些什么： 該函數(shù)首先利用card->instantiated來判斷該卡是否已經(jīng)實例化，如果已經(jīng)實例化則直接返回，否則遍歷每一對dai_link，進行codec、platform、dai的綁定工作，下只是代碼的部分選節(jié)，詳細的代碼請直接參考完整的代碼樹。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()函數(shù):

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數(shù)組申請內(nèi)存，每一個dai_link對應(yīng)一個snd_soc_pcm_runtime數(shù)組單元。。。。

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

card->rtd[i].dai_link = &card->dai_link[i];//把snd_soc_card中的dai_link復(fù)制到相應(yīng)的snd_soc_pcm_runtime。。。。

snd_soc_instantiate_cards();//將調(diào)用snd_soc_instantiate_card()//最為重要 }

下面我們分析snd_soc_instantiate_card()函數(shù)：

static void snd_soc_instantiate_card(struct snd_soc_card *card){

。。。。

if(card->instantiated){ //判斷該卡是否已經(jīng)實例化，如果是就返回

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，系統(tǒng)中所有的Codec、DAI、Platform都在注冊時連接到這三個全局鏈表上。soc_bind_dai_link函數(shù)逐個掃描這三個鏈表，根據(jù)card->dai_link[]中的名稱進行匹配，匹配后把相應(yīng)的codec，dai和platform實例賦值到card->rtd[]中（snd_soc_pcm_runtime）。經(jīng)過這個過程后，snd_soc_pcm_runtime：（card->rtd）中保存了本Machine中使用的Codec，DAI和Platform驅(qū)動的信息。

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

/* 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緩存，創(chuàng)建聲卡實例

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

if(card->probe){

ret = card->probe(card);

if(ret < 0)

goto card_probe_error;

}

。。。。。

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

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

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

}

。。。。。

ret = snd_card_register(card->snd_card);//然后調(diào)用標準的alsa驅(qū)動的聲卡函數(shù)進行聲卡注冊

。。。。。

}

到這里聲卡已經(jīng)注冊好了，聲卡可以正常工作了，我們再分析最后一個函數(shù)，也就是它們是怎么匹配的 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);//如果上面都匹配成功將創(chuàng)建標準的alsa的pcm邏輯設(shè)備

。。。。。

}

好了，到此為止我們最主要的部分machine部分分析完成了。接著是codec驅(qū)動部分：

Codec簡介

在移動設(shè)備中，Codec的作用可以歸結(jié)為4種，分別是：

? ? 對PCM等信號進行D/A轉(zhuǎn)換，把數(shù)字的音頻信號轉(zhuǎn)換為模擬信號

對Mic、Linein或者其他輸入源的模擬信號進行A/D轉(zhuǎn)換，把模擬的聲音信號轉(zhuǎn)變CPU能夠處理的數(shù)字信號

? 對音頻通路進行控制，比如播放音樂，收聽調(diào)頻收音機，又或者接聽電話時，音頻信號在codec內(nèi)的流通路線是不一樣的

? 對音頻信號做出相應(yīng)的處理，例如音量控制，功率放大，EQ控制等等

ASoC對Codec的這些功能都定義好了一些列相應(yīng)的接口，以方便地對Codec進行控制。ASoC對Codec驅(qū)動的一個基本要求是：驅(qū)動程序的代碼必須要做到平臺無關(guān)性，以方便同一個Codec的代碼不經(jīng)修改即可用在不同的平臺上。以下的討論基于wolfson的Codec芯片WM8994，kernel的版本3.3.x。

描述Codec的最主要的幾個數(shù)據(jù)結(jié)構(gòu)分別是：snd_soc_codec，snd_soc_codec_driver，snd_soc_dai，snd_soc_dai_driver，其中的snd_soc_dai和snd_soc_dai_driver在ASoC的Platform驅(qū)動中也會使用到，Platform和Codec的DAI通過snd_soc_dai_link結(jié)構(gòu)，在Machine驅(qū)動中進行綁定連接。

Codec的注冊

因為Codec驅(qū)動的代碼要做到平臺無關(guān)性，要使得Machine驅(qū)動能夠使用該Codec，Codec驅(qū)動的首要任務(wù)就是確定snd_soc_codec和snd_soc_dai的實例，并把它們注冊到系統(tǒng)中，注冊后的codec和dai才能為Machine驅(qū)動所用。以WM8994為例，對應(yīng)的代碼位置：/sound/soc/codecs/wm8994.c，模塊的入口函數(shù)注冊了一個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，必定會有相應(yīng)的platform device，platform device其實在我們之前講過的machine device注冊時已經(jīng)引入了。

[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驅(qū)動的第一個步驟就是定義snd_soc_codec_driver和snd_soc_dai_driver的實例，然后調(diào)用snd_soc_register_codec函數(shù)對Codec進行注冊。

snd_soc_register_codec（）函數(shù)是machine driver提供的，只要注冊成功后codec提供的操作函數(shù)就能正常提供給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驅(qū)動定義的snd_soc_dai_link中會指定每個link的codec和dai的名字，進行匹配綁定時就是通過和這里的名字比較，從而找到該Codec的 */

// 然后初始化它的各個字段，多數(shù)字段的值來自上面定義的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函數(shù)對本Codec的dai進行注冊 if(ret < 0)goto fail;}

mutex_lock(&client_mutex);list_add(&codec->list, &codec_list);/*最后，它把codec實例鏈接到全局鏈表codec_list中，并且調(diào)用snd_soc_instantiate_cards是函數(shù)觸發(fā)Machine驅(qū)動進行一次匹配綁定操作 */

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

好了，在這里我們的codec驅(qū)動也分析完了，其實這部分都是與平臺無關(guān)代碼，一般也不需要改動，這部分我們從設(shè)備原廠拿到代碼后丟上去就可以了，只是我們在寫machine device的時候要注意和這里的名字匹配。接下來是asoc的platform驅(qū)動：

Platform驅(qū)動的主要作用是完成音頻數(shù)據(jù)的管理，最終通過CPU的數(shù)字音頻接口（DAI）把音頻數(shù)據(jù)傳送給Codec進行處理，最終由Codec輸出驅(qū)動耳機或者是喇叭的音信信號。在具體實現(xiàn)上，ASoC有把Platform驅(qū)動分為兩個部分：snd_soc_platform_driver和snd_soc_dai_driver。其中，platform_driver負責(zé)管理音頻數(shù)據(jù)，把音頻數(shù)據(jù)通過dma或其他操作傳送至cpu dai中，dai_driver則主要完成cpu一側(cè)的dai的參數(shù)配置，同時也會通過一定的途徑把必要的dma等參數(shù)與snd_soc_platform_driver進行交互。

snd_soc_platform_driver的注冊

通常，ASoC把snd_soc_platform_driver注冊為一個系統(tǒng)的platform_driver，不要被這兩個想像的術(shù)語所迷惑，前者只是針對ASoC子系統(tǒng)的，后者是來自Linux的設(shè)備驅(qū)動模型。我們要做的就是：

? ? 定義一個snd_soc_platform_driver結(jié)構(gòu)的實例；

在platform_driver的probe回調(diào)中利用ASoC的API：snd_soc_register_platform()注冊上面定義的實例；

? 實現(xiàn)snd_soc_platform_driver中的各個回調(diào)函數(shù)；

以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()該函數(shù)用于注冊一個snd_soc_platform，只有注冊以后，它才可以被Machine驅(qū)動使用。它的代碼已經(jīng)清晰地表達了它的實現(xiàn)過程：

? ? ? ? ? 為snd_soc_platform實例申請內(nèi)存；

從platform_device中獲得它的名字，用于Machine驅(qū)動的匹配工作； 初始化snd_soc_platform的字段；

把snd_soc_platform實例連接到全局鏈表platform_list中；

調(diào)用snd_soc_instantiate_cards，觸發(fā)聲卡的machine、platform、codec、dai等的匹配工作；

cpu的snd_soc_dai driver驅(qū)動的注冊

dai驅(qū)動通常對應(yīng)cpu的一個或幾個I2S/PCM接口，與snd_soc_platform一樣，dai驅(qū)動也是實現(xiàn)為一個platform driver，實現(xiàn)一個dai驅(qū)動大致可以分為以下幾個步驟：

? ? 定義一個snd_soc_dai_driver結(jié)構(gòu)的實例；

在對應(yīng)的platform_driver中的probe回調(diào)中通過API：snd_soc_register_dai或者snd_soc_register_dais，注冊snd_soc_dai實例；

? ? 實現(xiàn)snd_soc_dai_driver結(jié)構(gòu)中的probe、suspend等回調(diào)；

實現(xiàn)snd_soc_dai_driver結(jié)構(gòu)中的snd_soc_dai_ops字段中的回調(diào)函數(shù)；

snd_soc_register_dai 這個函數(shù)在上一篇介紹codec驅(qū)動的博文中已有介紹

具體不再分析，這個驅(qū)動也不需要用戶做任務(wù)修改，所以只要知道它的作用就已經(jīng)夠了。就像電話機一樣，我們只要知道電話怎么打就夠了，至于它怎么連接我們并不太需要關(guān)心。

第二篇：音頻分類總結(jié)(算法綜述)

總結(jié)音頻分類的算法

剛開始對音頻分割還有特征提取有些自己的想法，感覺應(yīng)該能夠分清楚，但是當開始查閱文獻的時候，發(fā)現(xiàn)對他們兩個的概念越來越模糊。很多時候他們是重疊的。后來我在一篇文獻里找到這句話。覺得應(yīng)該是這個道理：

音頻數(shù)據(jù)的分類是一個模式識別的問題，它包括兩個基本方面：特征選擇和分類。

音頻分割是在音頻分類的基礎(chǔ)上從音頻流中提取出不同的音頻類別，也就是說在時間軸上對音頻流按類別進行劃分。分類是分割的前提和基礎(chǔ)。對音頻流的準確分割是最終的目的。

于是我找了一下比較典型的分類算法

比較典型的音頻分類算法包括最小距離方法、支持向量機、神經(jīng)網(wǎng)絡(luò)、決策樹方法和隱馬爾可夫模型方法等。

1．最小距離法。(典型的音頻分類算法)最小距離分類法的優(yōu)點是概念直觀，方法簡單，有利于建立多維空間分類方法的幾何概念。在音頻分類中應(yīng)用的最小距離分類法有k近鄰(k—Nearest Neighbor，簡稱K—NN)方法和最近特征線方法(Nearest Feature，簡稱NFL))等。

k近鄰方法的思想是根據(jù)未知樣本X最近鄰的k個樣本點的類別來確定X的類別。為此，需要計算X與所有樣本x。的距離d(x，x。)，并且從中選出最小的k個樣本作為近鄰樣本集合KNN，計算其中所有屬于類別Wj的距離之和，并且按照以下判別規(guī)則進行分類：?C(x)?argminC?{W1,...,Wn}

?d(x,xi),其中，C為類別集合由于k近鄰方法利用了更多的樣本信息確定它的類別，k取大一些有利于減少噪聲的影響。但是由于k近鄰方法中需要計算所有樣本的距離，因此當樣本數(shù)目非常大的時候，計算量就相當可觀。取k=l時，k近鄰方法就退化為最近鄰方法。

最近特征線方法是從每一類的樣本子空間中選取一些原型(Prototype)特征點，這些特征點的兩兩連線稱為特征線(Feature Line)，這些特征線的集合用來表示原先每一類的樣本子空間。

設(shè)類C的原型特征點集合:,其中Nc為類C的原型特征點數(shù)目，則對應(yīng)的特征線的數(shù)目為Sc，而類C的特征線集合

{|XicXjc|1?i,j?Nc，i?j} i≠jl構(gòu)成類C的特征線空間，它是類C的特征子空間。—般所選取的原型特征點的數(shù)目比較少，因此特征線的數(shù)目也比較少。未知樣本X與特征線XicXjc的距離定義為x在XicXjc上的投影距離，如圖4所示，而X與類別C的距離為X與類C的特征線空間中的所有特征線的最短距離。

2．神經(jīng)網(wǎng)絡(luò)(Neural Network)。

在使用神經(jīng)網(wǎng)絡(luò)進行音頻分類時，可以令輸入層的節(jié)點與音頻的特征向量相對應(yīng)，而輸出層的節(jié)點對應(yīng)于類別Ci。，如圖5所示。在訓(xùn)練時，通過對訓(xùn)練樣本集中的樣本進行反復(fù)學(xué)習(xí)來調(diào)節(jié)網(wǎng)絡(luò)，從而使全局誤差函數(shù)取得最小值。這樣，就可以期望該網(wǎng)絡(luò)能夠?qū)π螺斎氲拇诸悩颖綯輸出正確的分類Ci。

3．支持向量機(support Vector Machine，簡稱為SVM)。

支持向量機是Vapnik等人提出的以結(jié)構(gòu)風(fēng)險最小化原理(Stuctural Risk Minimization Principle)為基礎(chǔ)的分類方法。該方法最初來自于對二值分類問題的處理，其機理是在樣本空間中尋找—個將訓(xùn)練集中的正例和反例兩類樣本點分割開來的分類超平面，并取得最大邊緣(正樣本與負樣本到超平面的最小距離)，如圖6所示。該方法根據(jù)核空間理論將低維的輸入空間數(shù)據(jù)通過某種非線性函數(shù)(即核函數(shù))映射到—個高維空間中，并且線性判決只需要在高維空間中進行內(nèi)積運算，從而解決了線性不可分的分類問題。

根據(jù)不同的分類問題，可以選用不同的核函數(shù)，常用的核函數(shù)有三種：

① 項式核函數(shù):

② 徑向基核函數(shù):

③ Sigmoid核函數(shù)：

SVM訓(xùn)練算法主要有三類：二次規(guī)劃算法，分解算法，增量算法。

4．決策樹方法

決策樹是一種結(jié)構(gòu)簡單、搜索效率高的分類器。這類方法以信息論為基礎(chǔ)，對大量的實例選擇重要的特征建立決策樹，如圖7所示。

最優(yōu)決策樹的構(gòu)造是一個NP完全(NPComepleteness)問題，其設(shè)計原則可以形式化地表示為

其中T為特定的決策樹結(jié)構(gòu)，F(xiàn)和d分別為分枝結(jié),為在數(shù)據(jù)集合點的特征子集和決策規(guī)則，D為所有的訓(xùn)練數(shù)據(jù)，D上選取特征集合F和決策規(guī)則d訓(xùn)練得到的結(jié)構(gòu)為T的決策樹的分類錯誤?的條件概率。因此，決策樹的構(gòu)造過程可以分為三個問題：選取合適的結(jié)構(gòu)，為分枝結(jié)點選取合適的特征子集和決策規(guī)則。常用的決策樹構(gòu)造方法有非回溯的貪心(Greedy)算法和梯度上升算法。

5.隱馬爾可夫模型(Hidden Markov Model，簡HMM)方法。

隱馬爾可夫模型(HMM)的音頻分類性能較好，它的分類對象是語音(speech)、音樂(music)以及語音和音樂的混合(speech+music)共3類數(shù)據(jù)，根據(jù)極大似然準則判定它們的類別，最優(yōu)分類精度可達90.28％。

HMM本質(zhì)上是一種雙重隨機過程的有限狀態(tài)自動機(stochastic finite-state automata)，它具有刻畫信號的時間統(tǒng)計特性的能力。雙重隨機過程是指滿足Markov分布的狀態(tài)轉(zhuǎn)換Markov鏈以及每一狀態(tài)的觀察輸出概率密度函數(shù)，共兩個隨機過程。HMM可以用3元組來表示：入；(A，B，?)，其中A是狀態(tài)Si到Sj的轉(zhuǎn)換概率矩陣，B是狀態(tài)的觀察輸出概率密度，?是狀態(tài)的初始分布概率。

第三篇：高通音頻調(diào)試總結(jié)

高通音頻調(diào)試總結(jié)

----夏珊珊

之前會議電話項目我們設(shè)計的方案是：外部的codec內(nèi)帶音頻處理dsp接6270模塊工作。外部codec+6270與高通的codec+dsp工作方式大致相同。所以調(diào)節(jié)音頻的工作原理可以以高通內(nèi)部的原理來作依據(jù)。

在調(diào)節(jié)會議電話的時候我們遇到了一個很大的問題，底噪。我們在這個問題上糾結(jié)了很久。調(diào)節(jié)了mic的濾波電路，高通的AGC參數(shù)，TX,RX filter 參數(shù)，都沒有明顯的改善，后來我們把mic斷開接地，發(fā)現(xiàn)tx端還是有很大的噪音，截取輸入到高通的音頻噪音比較明顯，從而我們確定了這個噪音是由外部的codec所引入的。調(diào)整音頻的時候分析噪音來源比較重要，這樣相應(yīng)調(diào)整各部分增益來使噪音源影響盡量減小。

對于噪音處理，發(fā)現(xiàn)不管使用高通的AGC壓制噪音還是使用外部CODEC帶的DSP處理噪音都對音質(zhì)有很大的損傷。所以建議在調(diào)整音頻之前先最大限度的保證結(jié)構(gòu)和硬件設(shè)計的優(yōu)化性，畢竟軟件可以對數(shù)字噪音處理比較理想，但是對于模擬噪音就不是萬能的了。具體對于噪音的處理后續(xù)會在文檔中提到。

高通音頻通道及調(diào)整

基本概念

回音:Near end 端不說話，far end說話了后經(jīng)過上圖的path，經(jīng)過喇叭播放后在空中回蕩，又被mic收回去，在far-end聽到了自己的聲音。

Echo path：從Echo Canceller出來，經(jīng)過gain、a/d轉(zhuǎn)換 到speaker 經(jīng)外面的環(huán)境，然后又被mic收回，通過一系列的通道到Echo Canceller。

Acoustic echo path：從speaker 出來，在環(huán)境中回蕩后再進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講話的時候被抑制掉

理想的狀態(tài)是TX進來的echo，跟我們估測echo相近，相減就為0，但是實際上不可能，所以需要一個DENS消除非線性的回音，我們選擇0~4KHZ是因為這個范圍的聲音是人聲范圍。

調(diào)整順序：

設(shè)置音量等級和AGC gain→EC gain和 limit→codec和mic的gain→Ec parameter。高通的default volume 基本上可以使用于各個普通的場合。

AGC gain 我們首先調(diào)整外圍的gain，比如tx agc、txvolume，AGC處理噪音比較有效，但是會相應(yīng)的犧牲tx端的音質(zhì)及音量大小。如果這個噪音會隨著Rx_Volume變化，在拔出手柄或者靜音Rx_CODEC_GAIN(0x0000),噪音明顯減弱，那么這個噪音是數(shù)字噪音，可以使用RxAGC減弱，具體的操作方法是：

? 設(shè)置Rx AGC工作在靜態(tài)增益模式(compFlinkAIGFlag=0x0000);? 減弱‘rx_agc_static_gain’為0dB(compFlinkStaticGain=0x2000);? 增加‘rx_agc_exp_thres’ 到-40dBm0mu(expFlinkThreshold=0x1180).同樣TX端的數(shù)字噪音也可以調(diào)整TX AGC 消除，調(diào)整的方式于RX AGC相同。在音頻通路上，建議調(diào)整增益的地方是codectxgain 和txvolume，這樣做的目的是防止送入codec處理的音頻信號太大出現(xiàn)削頂失真，使EC無法很好的模擬回音并處理掉回音。所以我們盡量在EC處理完畢后對信號進行放大。

EC gain和limit 外圍的gain調(diào)整完畢后調(diào)整EC block gain（input gain、output gain）在調(diào)整的時候，rx volume 是調(diào)整到最大處理，這樣做為了避免rx 方向上聲音太小，揚聲器聲音不夠大，不易于測試回音。

Nlpp limit：當input太大的時候，rx收到的聲音特別大聲，但是spk不總是這么大聲，這樣使ECHO收到的東西太多失真，設(shè)置limit的話使突強的時候使進入EC的echo不要太多。AF limit：控制TX方向的，EC 無法收斂，或者收斂的速度太慢，收到的東西突強太多，這樣使用limit 解決，用于限制突然大聲的信號。

Codec及mic的gain 隨后設(shè)置codec和mic的gain，文章開端曾提到若模塊有噪音，噪音的來源必須找到，并相對于此來設(shè)置codec及mic的gain。我們的應(yīng)用噪音是來自于codec芯片本身，所以對于mic增益的降低對噪音是沒有益處的，因為噪音會隨著ADC的放大而放大，衰減而減弱。Mic增益小，相對的ADCgain必須放大才能讓tx端聽到清晰的聲音，這樣反而把噪音放大了。所以為了讓產(chǎn)生的噪音最小，我們嘗試把mic的增益放大，ADC gain衰減來減弱噪音，達到比較好的效果。所以調(diào)整這部分的增益需要根據(jù)具體的情況，具體的模塊相應(yīng)調(diào)整。

Ec parameters 對回音來說，結(jié)構(gòu)及材料也有很大的影響因素。我們在設(shè)計的時候必須要考慮到這些因素才能更好的實現(xiàn)音質(zhì)效果。比如SPK與mic必須盡量的拉開距離；mic腔體不能太大，mic使用專門的泡膜包起來；機殼的材質(zhì)最好使用吸引的材料，防止大聲音播放的時候機殼震動影響mic等等，這些在前期的時候最好設(shè)計考慮到。

關(guān)于EC參數(shù)，高通有幾組默認的回音參數(shù)，從Speaker phone 到bluetooth 幾個等級。通常嘗試的時候從普通的模式到aggressive嘗試，ECHO canceller的肯定會傷害到double talk的能力，所以可以不用不壓抑太多就不要壓抑太多。如果嘗試模式的參數(shù)沒有echo，就選擇壓制的比較小的那組參數(shù)。總之是在Double talk 和echo canceller取得一個平衡。

細調(diào)

如果使用aggressive那組參數(shù)，echo還是沒有消除，那么查找echo path delay Echo會隨著echo path改變，echo path有長短。當echo path delay設(shè)置不好，會使echo收斂不好。

如果不知道要設(shè)置多少的話就先設(shè)置為0，然后慢慢向上調(diào)整。

調(diào)整進入AF的參數(shù)

調(diào)整進入AF的兩個進入EC的input的大小，他們的大小關(guān)系必須在一定的范圍，AF才能正常的收斂。

X[K]> Z[K]，AF才能正常的收斂。從網(wǎng)路端送來的信號，ECHO是從環(huán)境處理后的聲音，肯定是稍微有點小，但是如果經(jīng)過codec處理后就可能比X大，那么就使用Inputgain降低，然后增大OutputGain。

EC已經(jīng)收斂了，如果有非線性的echo無法消除，通過設(shè)置 DENS_tail_portion： DENS_tail_alpha： DENS_NL_atteu：

這幾個參數(shù)設(shè)置越大，echo 消除能力越好，但是影響double talk 高通給出的參數(shù)適用于大部分的場合，只需要在默認參數(shù)的基礎(chǔ)上微調(diào)就可以了。這些參數(shù)的調(diào)整如果使用工具調(diào)整就比較方便了。下面就講講音頻調(diào)試工具。

音頻調(diào)試工具

音頻調(diào)試工具的比較（這個是引用了鐘明同學(xué)的文檔，他的高通文檔講解的比較清晰了，我對其引用補充下吧 O(^_^)O）

AT Command: 引用了6100的使用的AT命令作個簡要的介紹。設(shè)置回音的ECHO命令A(yù)T+ECHO和AT+ECHO1可以設(shè)置回音的28個參數(shù)。

AT+CLVL: 音量級別設(shè)置 AT+RXVOL: RX端音量設(shè)置 AT+CMUT：靜音設(shè)置 AT+CMIC： mic音量設(shè)置 AT+SIDET：側(cè)邊音設(shè)置

AT+ECHO：設(shè)置手持與免提模式下的回聲各個參數(shù) AT+ECHO1：設(shè)置藍牙耳機與普通耳機的回聲參數(shù)

QACT 需要導(dǎo)入正確的audio_cal.xml，通常這個文件在工程里帶有 使用步驟

1.配置QPST，使使端口出現(xiàn)在active Phones tab。

如果設(shè)備沒有連接上或者XML文件導(dǎo)入錯誤，在QACT v1.x的版本會彈出這個窗口。表示只能在PC上調(diào)整，而無法在線的把數(shù)據(jù)導(dǎo)入到模塊。

導(dǎo)入正確的xml文件

如果連接成功，可以看到以下圖片，選擇“否”，也就是不把XML 中默認的結(jié)果導(dǎo)到模塊里面去。（我們這里只是調(diào)試，不要導(dǎo)入.XML 中默認的值）

我們在里面會調(diào)整的比較多的是： 調(diào)整codec的gains

Graphical拉AGC 參數(shù)，從Data獲取參數(shù)

拉TX,RX filter 曲線

選擇對應(yīng)的path，device，拉出曲線后可見右邊的7個參數(shù)，對應(yīng)于代碼里voc_pcm_path_cal_type結(jié)構(gòu)體中的tx_iir_filter。

QACT在線調(diào)試必須通話掛機后才生效。而且拉TX,RX filter無法模擬模塊里原來的聲音曲線，調(diào)節(jié)音質(zhì)曲線個人比較傾向于使用Qfilt。

QFILT 使用音頻分析儀器獲取未處理的（TX/RX filter全部設(shè)置為0）頻響曲線。把這個曲線數(shù)據(jù)保存為*.EXP格式。

之前在龍旗做測試的時候發(fā)現(xiàn)使用儀器獲取曲線數(shù)據(jù)無法直接保存為.EXP格式，保存為.ASM格式，將保存的數(shù)據(jù)去掉100之前及4000之后的數(shù)據(jù)，加上固定的格式如下：

# 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導(dǎo)入對應(yīng)的RX或者TX數(shù)據(jù)，導(dǎo)入數(shù)據(jù)之前必須配置右邊的相關(guān)設(shè)置。選擇Test Mode，Test Class，Test Path及Filter Type 0.676438

導(dǎo)入文件后的初始化曲線，這個曲線跟使用儀器測出來的頻響曲線一致。

通過調(diào)整濾波曲線后的圖如下：綠色是調(diào)整后的曲線，黃色的是原始的曲線，紅色的濾波器的調(diào)整曲線。我們調(diào)整曲線的目的是確保調(diào)整后曲線在兩條白色的曲線之間，且比較平滑。

調(diào)整到合適的曲線則點擊Get Cofficients 獲取調(diào)整的參數(shù)

在實際測試的時候如果把這個參數(shù)寫入程序然后編譯下載效率太慢了，這個時候可以直接使用QDV把這些實時的數(shù)據(jù)寫入到模塊，在通話的過程中實時生效，使用測試儀器測試使用調(diào)整后的參數(shù)曲線是否能通過測試。

QDV QDV使用需要導(dǎo)入正確的rpt文件。這個文件可以跟高通提SR獲取。

之前遇到使用了錯誤的rpt文件導(dǎo)致有些參數(shù)設(shè)置不正確，所以一定要確保使用正確的文件。

啟動QDV，首先看到以下的界面：

MEMA , MEMB , MEMC , MEMI值一定要設(shè)置正確，這個值可以通過查看代碼獲取。設(shè)置完成后進入以下界面

它的工具條如下所示

選擇導(dǎo)入.rpt文件。

選擇完.rpt文件后 點擊 打開一個Text view 界面，右擊選擇需要修改的參數(shù)。

選擇new可以導(dǎo)入一個新的參數(shù)。

導(dǎo)入后如圖，選中變量后點擊

可以修改變量值。

調(diào)整EC block中參數(shù)，配置完成后，必須寫ecParametersUpdated使回音參數(shù)生效。如下圖，設(shè)定了Echo參數(shù)后需要設(shè)置ecParametersUpdated為FFFF使其生效，設(shè)置完成后它會自動跳變?yōu)?000.同樣，對于TX filtr和RX filter也需要寫一個load參數(shù)（txPcmFiltLoad和rxPcmFiltLoad）FFFF使寫入的參數(shù)生效，同樣這個參數(shù)生效后會自動跳回0000。

第四篇：音頻部實訓(xùn)學(xué)習(xí)總結(jié)

今年9月份進入傳媒實踐中心的音頻部，通過這一個月的實訓(xùn)學(xué)習(xí)，我學(xué)會了把我們在學(xué)校所學(xué)的理論知識，運用到客觀實際中，實訓(xùn)，就是把自己所學(xué)到的理論知識有用武之地，只學(xué)不實踐，那么所學(xué)的就等于零。理論應(yīng)該與實踐相結(jié)合，另一方面，實踐可以為以后找工作打基礎(chǔ)。通過這段時間的學(xué)習(xí)，我學(xué)到了一些在課堂上學(xué)不到的東西，因為環(huán)境不同，接觸到的人與事不同，從中學(xué)到的東西自然就不一樣。要學(xué)會從實踐中學(xué)習(xí)，從學(xué)習(xí)中實踐。而且我國的經(jīng)濟飛速發(fā)展，在擁有越來越多的機會多的是，也有了更多的挑戰(zhàn)，對于人才的要求就會越來越高，我們不知要學(xué)好課堂所學(xué)到的知識，不斷從學(xué)習(xí)中，實踐中學(xué)習(xí)其他知識，不斷從各方面武裝自己，才能在競爭中突出自己，表現(xiàn)自己。

這一個月的工作過程使我受益很大，學(xué)習(xí)了關(guān)于聲音的基礎(chǔ)知識，如聲音的傳播，特性，頻率范圍等，還在學(xué)校的活動中認識了調(diào)音臺的操作。這不僅讓我開闊了眼界，最主要的是懂得了如何更好的為人處世。在短暫的實訓(xùn)過程中，我深深的感覺到自己所學(xué)的知識的膚淺和在實踐運用中知識的匱乏，剛開始的一段時間里，對一些工作無從下手，茫然不知所措，這讓我感到非常的難過，在學(xué)?？傄詾樽约簩W(xué)的不錯，一旦接觸到時間，才發(fā)現(xiàn)自己知道的是多么少，這時才真正領(lǐng)悟到學(xué)無止境的含義。

第五篇：高通音頻增益調(diào)試總結(jié)

高通音頻調(diào)試總結(jié)

1、綜述

該文檔主要描述了手機打開免提通話的時候，如何解決固話端出現(xiàn)的嘯音、噪音問題。

2、環(huán)境 項目：xxx 硬件平臺：MSM7X27A 軟件版本：android2.3.5, AMSS11452302

3、調(diào)試流程

（1）咨詢高通FAE，明確哪些參數(shù)需要調(diào)整

FAE給出的建議是：針對嘯音，調(diào)整codec_rx_gain、codec_tx_gain參數(shù)；針對雜音，調(diào)整rx_agc_static_gain、rx_agc_exp_thres、rx_agc_compr_thres、tx_agc_exp_thres、tx_agc_compr_thres參數(shù)；（2）使用QACT工具，對上述參數(shù)進行調(diào)試 QACT是高通提供的音頻校準工具，可以使用該工具直接在線修改各類音頻參數(shù)，調(diào)試十分方便（使用方法詳見安裝文件目錄下的文檔《80-VM407-1_E_Audio_Calibration_Tool_User_Guide.pdf》）。

使用該工具在線調(diào)試的基本思路是：適當降低增益（codec_rx_gain、codec_tx_gain），并調(diào)整AGC的門限值以及靜態(tài)增益(rx_agc_exp_thres、rx_agc_compr_thres、tx_agc_exp_thres、tx_agc_compr_thres、rx_agc_static_gain參數(shù))，以達到消除嘯音、噪音的目的。在線調(diào)試完成后，還可以用這個工具將調(diào)好的audio_cal.xml文件直接生成代碼，具體也請參考上述文檔。（3）修改代碼 代碼路徑：modem_proc/multimedia/audio/vocoder/src/voccal.c 在結(jié)構(gòu)體voc_pcm_on_chip_speaker_cal_umts_qrd中，分別修改各個參數(shù)，代碼如下：

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 */ …… …… };