首先我從ALSA 官方網上下載了alsa-utils-1.0.23版本的工具，因為我android 的alsa-lib
也是1.023版本的，防止版本不一樣出現問題，我就選擇了版本一樣，我們的alsa-lib放的路徑是在android_source/external/alsa-lib目錄下面，我們下載的alsa-utils-1.023工具包也下載放在裡面。
接下來我們需要完成以下幾個動作：
1、在alsa-utils下面創建一個Android.mk寫的內容是：
ifeq ($(strip $(BOARD_USES_ALSA_AUDIO)),true)
LOCAL_PATH:= $(call my-dir)
#
# Build aplay command
#
include $(CLEAR_VARS)
LOCAL_CFLAGS := \
-fPIC -D_POSIX_SOURCE \
-DALSA_CONFIG_DIR=\"/system/usr/share/alsa\" \
-DALSA_PLUGIN_DIR=\"/system/usr/lib/alsa-lib\" \
-DALSA_DEVICE_DIRECTORY=\"/dev/snd/\"
LOCAL_C_INCLUDES:= \
$(LOCAL_PATH)/include \
$(LOCAL_PATH)/android \
external/alsa-lib/include
LOCAL_SRC_FILES := \
aplay/aplay.c
LOCAL_MODULE_TAGS := debug
LOCAL_MODULE := alsa_aplay
LOCAL_SHARED_LIBRARIES := \
libasound \
libc
include $(BUILD_EXECUTABLE)
上面我只寫了個編譯aplay工具的代碼，別的工具也是一樣的寫法
2、接下來進入alsa-utils工具包裡面進行創建sys目錄和aconfig.h文件，在aconfig.h文件裡面編寫以下內容
#define DATADIR "/system/usr/share/alsa"
#define rindex strrchr
#define open64 open
#undef __swab16
#define __swab16(x) __arch__swab16((x))
#undef __swab32
#define __swab32(x) __arch__swab32((x))
3、進入第2步中創建的sys目錄，在sys目錄中創建signal.h頭文件，在這個頭文件中寫如以下內容
[plain] view plainprint?
01.#include <signal.h>
#include <signal.h>4、接下來你直接編譯android 就可以了，在編譯過程中可能出現以下 錯誤「
4.1:kernel/common/linux/un.h:18: error: expected specifier-qualifier-list
before 'sa_family_t
那是因為我們在alsa-utils/alsactl/init_parse.c裡面在include un.h之前沒有#include
<sys/socket.h>，你只要在這之前include這個頭文件就解決了
4.2：還有可能遇到這個錯誤：在aplay.c裡面會提示報錯'S_IRGRP' undeclared (first use in this
function，你只要在在aplay.c裡面添加一個頭文件：#include <sys/stat.h>,這樣就解決了
4.3:接下來可能語言到這樣的錯誤：speaker-test.c裡面報wav_file_dir沒有定義，這個值是用來定義你的wav文件存放在pad中的位置的，你隨便放在哪裡，我定義的路徑
就是在/sdcard目錄下面
經過上面的種種修改，alsa-utils工具終於編譯成功了
轉載
Ⅱ android聲音通道怎麼理解
由於使用的是耳機 麥克分離式的耳機，所以要分別上報事件。在Android系統層耳機插孔的檢測是基於/sys/class/switch/h2w/state的值來判斷的（以4.4.4_r2為例子位於WiredAccessoryManager.java）。
只要在內核中實現一個「或真或假」的基於switch類的h2w開關。Android系統就可以監聽到插拔信息。
在播放音樂的時候插入耳機，使用tinymix（參考：Android音頻底層調試-基於tinyalsa）命令可以查找到Playback Path的值從SPK變為HP_NO_MIC，就可以說明耳機插拔軟體檢測正常了。
# tinymix
Mixer name: 'RK_RK616_TINY'
Number of controls: 7
ctl type num name value
0 ENUM 1 Playback Path HP_NO_MIC
1 ENUM 1 Capture MIC Path MIC OFF
2 ENUM 1 Voice Call Path OFF
3 ENUM 1 Voip Path OFF
4 INT 2 Speaker Playback Volume 24 24
5 INT 2 Headphone Playback Volume 24 24
6 ENUM 1 Modem Input Enable ON
Ⅲ android 應用怎樣調用tinyalsa
1.編譯tinyalsa配套工具
$ mmm external/tinyalsa/
編譯完後會產生tinyplay/tinymix/tinycap等等工具。
tinymix: 查看配置混音器
tinyplay: 播放音頻
tinycap: 錄音
2.查看當前系統的音效卡
[python] view plain
root@android:/ # cat /proc/asound/cards
0 [RKRK616 ]: RK_RK616 - RK_RK616
RK_RK616
1 [ROCKCHIPSPDIF ]: ROCKCHIP-SPDIF - ROCKCHIP-SPDIF
ROCKCHIP-SPDIF
root@android:/ #
3.tinymix查看混響器
tinymix使用方法a.不加任何參數-顯示當前配置情況 b.tinymix [ctrl id] [var]不加[var]可以查看哪配該[ctrl id]可選李渣指選項。
[python] view plain
root@android:/ # tinymix
Number of controls: 7
ctl type num name value
0 ENUM 1 Playback Path OFF
1 ENUM 1 Capture MIC Path MIC OFF
2 ENUM 1 Voice Call Path OFF
3 ENUM 1 Voip Path OFF
4 INT 2 Speaker Playback Volume 0 0
5 INT 2 Headphone Playback Volume 0 0
6 ENUM 1 Modem Input Enable ON
root@android:/ #
4.使用tinyplay播放wav音樂
這個只是一個最基本的播放器，所以不支持播放MP3等等壓縮過格式的音樂。沒有學會使用前，網上都說很麻煩，但是現在看來一點也不麻煩，直接梁悄播放了44.1kHz/44.8kHz的wav音樂。
[python] view plain
root@android:/ # tinyplay /sdcard/0_16.wav
Playing sample: 2 ch, 44100 hz, 16 bit
root@android:/ #
註：播放之前得首先使用tinymix把通道設置好，上文中已經給出了設置到揚聲器中的例子;由於播放時使用的最大音量進行播放的，所以注意防止被嚇到。這里將測試音頻文件上傳。
5.tinycap使用
root@android:/ # tinycap /sdcard/test.wav
可以進行錄音。
目前只遇到這些，就先總結到這，可以隨時再深入。
Ⅳ MTK Android tinycap錄制音頻
tinycap和tinymix 是tinyalsa下的可執行程序，源碼在external\tinyalsa下
我們只需要在device.mk 內添加
編譯即可
1.在開機後，有root許可權的情況，執行扮彎tinymix，得到控制項狀薯侍態。
2.開啟錄音機。執行tinymix，得到錄音狀態下控制項情況
比較不同處
經過分析，主要是ctl id 14 15 16 17 20 21需要在錄音時候打開。
1.執行如廳手悶下命令
tinymix 14 1
tinymix 15 3
tinymix 16 1
tinymix 17 1
tinymix 20 4
tinymix 21 4
2.tinycap錄音
tinycap /sdcard/aud-test.wav -D 0 -d 1 -c 2 -b 16 -r 16000
OK～
Ⅳ 怎麼修改Android 的Linux內核
Android 產品中，內核格式是Linux標準的zImage，根文件系統採用ramdisk格式。這兩者在Android下是直接合並在一起取名為boot.img,會放在一個獨立分區當中。這個分區格式是Android自行制定的格式。
Android開發時，最標準的做法是重新編譯於內核和根文件系統，然後調用Android給的命令行文件mkbootimg(out/host/linux-x86/bin/)來打包。
在製作手機ROM時，有時會單獨編譯內核或抽出根文件進行修改內容，比如我只編譯內核，其餘的地方不變。這樣重新安裝巨大的Android開發環境實在不劃算。因此很多boot.img解包工具被人開發出來，這一些工具都是把內核和根文件系統從一個現成的boot.img抽取出來，修發後再次打包還原。
一.常見的解包工具
因為boot.img的格式比較簡單，它主要分為三大塊（有的可能有四塊）
因此很多人開發分析工具，有是linux shell腳本，比如repack-zImage，也有人採用perl,還有C語言編寫的 unbootimg，
我使用的是在源碼位置system/core/mkbootimg/ 下的 mkbootimg。為了簡化，藍點工坊把與mkbootimg中打包工具和解包工具以及所包含的libmincrpty庫抽出來，並且重寫一個Makefile,作為開源項目。
使用者只需要在linux（需安裝gcc,make,一般是標配）或windows（需要安裝mingw）的命令行執行make,即可產生可執行文件mkbootimg ，unpackbootimg。
二.解/打包工具使用
解包工具：unpackbootimg
常見格式
unpackbootimg -i .\tmp\boot.img -o .\out
這一句命令行表示把boot.img解包，所有文件輸出到out目錄下
它會解壓出如下文件：
boot.img-zImage (內核文件）
boot.img-ramdisk.gz (根文件系統打包文件）
boot.img-cmdline (mkbootimg cmdline參數)
boot.img-pagesize (mkbootimg pagesize參數)
boot.img-base (mkbootimg base參數)
打包工具：mkbootimg （Android自帶）
常見的命令格式：
./mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel zImage --ramdisk boot/boot.img-ramdisk.gz -o boot.img --base 02e00000
這句含義是把內核文件zImage和boot目錄下的根文件壓縮包 boot.img-ramdisk.gz打包成boot.img.
其中cmdline和base的值均來源於unpackbootimg的結果
Ⅵ smoothaction為什麼有雜音
smoothaction為什麼有雜音？APP
整個音頻體系的最上層
Framework
MediaPlayer和MediaRecorder、AudioTrack和AudioRecorder，Android系統為控制音頻系統提供了AudioManager、AudioService及AudioSystem類，這些都是framework為便利上層應用開發所設計的
Libraries
系統服務AudioFlinger和AudioPolicyService(比如:ServiceManager、LocationManagerService、ActivityManagerService等等)，音頻體系中另一個重要的系統服務是MediaPlayerService
HAL
硬體抽象層是AudioFlinger直接訪問的對象，這說明了兩個問題，一方面AudioFlinger並不直接調用底層的驅動程序;另一方面，AudioFlinger上野或層(包括和它同一層的MediaPlayerService)的模塊只需要與它進行交互就可以實現音頻相關的功能了。因而我們可以認為AudioFlinger是Android音頻系統中真正的「隔離板」，無論下面如何變化，上層的實現都可以保持兼容。音頻跡握方面的硬體抽象層主要分為兩部分，即AudioFlinger和AudioPolicyService。實際上後者並不是一個真實的設備，只是採用虛擬設備的方式來讓廠商可以方便地定製出自己的策略，抽象層的任務是將AudioFlinger/AudioPolicyService真正地與硬體設備關聯起來
以前Android系統中的Audio系統依賴於ALSA-lib，但後期就變為了tinyalsa，這樣的轉變不應該對上層造成破壞。因而Audio HAL提供了統一的介面來定義它與AudioFlinger/AudioPolicyService之間的通信方式，這就是audio_hw_device、audio_stream_in及audio_stream_out等等存在的目的，這些Struct數據類型內部大多隻是函數指針的定義，是一姿脊慶些「殼」。當AudioFlinger/AudioPolicyService初始化時，它們會去尋找系統中最匹配的實現(這些實現駐留在以audio.primary.*,audio.a2dp.*為名的各種庫中)來填充這些「殼」
理解Android音頻系統的時候分為兩條線索
以庫為線索，比如:AudioPolicyService和AudioFlinger都是在libaudioflinger庫中，而AudioTrack、AudioRecorder等一系列實現則在libmedia庫中
以進程為線索，庫並不代表一個進程，進程則依賴於庫來運行。雖然有的類是在同一個庫中實現的，但並不代表它們會在同一個進程中被調用。比如AudioFlinger和AudioPolicyService都駐留於名為mediaserver的系統進程中，而AudioTrack/AudioRecorder和MediaPlayer/MediaRecorder一樣實際上只是應用進程的一部分，它們通過binder服務來與其它系統進程通信。
Ⅶ I2S注意事項
關於I2S， wikipedia 上介紹的比較全面。這里記錄一些容易出錯的點。
以Linux/Android主板而言，I2S是ASoC中的CPU Platform驅動。一般情況下需要同時搭上Codec和Machine驅動才能夠啟用。啟用後會在/proc/asound/cards中查看到多出一個音效卡。(如果硬體上I2S確實沒有連接Codec，那麼一般CPU廠家內核中會有 Plublic Machine 的Machine驅動來保證單獨的I2S也可以被使用起來)
以Allwinner H3的I2S0為例，由於板子I2S0沒有連接Codec，需要按照以下配置啟用該I2S：
其中 SoC daudio0 tdm interface for SUNXI chips 為ASoC中的CPU Platform驅動， Daudio0 Public Machine for SUNXI chips 為ASoC中的 Machine + 虛擬Codec驅動。
對於Allwinner的平台而言還要確定sys_config.fex中的相應配置有沒有選中，相應的GPIO有無佔用飢答塵。
這樣編譯燒寫系統後， cat /proc/asound/cards 可以查看到多了一個音效卡。
使用I2S就是按照普通音效卡的方式進行使用，比如Android下的tinyalsa都可以做簡單的播放錄制等等。
更多使用方法見： Android音頻底層調試-基於tinyalsa 。
I2S中的一般常用的bit有16 24 32，這些I2S輸出的CLK都是32個。播放16bit時，放到了前舉散32bit的前16bit；播放32bit一般是剛好是32bit；而播放24bit時，需要把數據按照32bit傳遞給設備節點，也是前24bit。如果使爛禪用tinyalsa播放一個真24bit數據時，沒有轉換成32bit下傳時播放會出現雜訊。
I2S硬體輸出的波形如下：
當然還有一點，一些宣稱支持到32bit的，實際輸出的是時候可能會按照24bit輸出（當低8bit丟棄了），比如Allwinner H3。或許只是kernel驅動的問題。
<完>
Ⅷ Android音頻底層調試-基於tinyalsa
因為Android中默認並沒有使用標准alsa，而是使用的是tinyalsa。所以就算基於命令行的測試也要使用libtinyalsa。Android系統在上層Audio千變萬化的時候，能夠能這些個工具實時查看到，比方音頻通道的切換等等。
編譯完後會產生tinyplay、tinymix、tinycap等工具。
tinymix用法：
相應解釋：
Playback Path：
例：將輸出切換到揚聲器
關於tinymix小結：
通過觀察發現，Android系統的聲音音量的調節並沒有直接使用tinyalsa，而基於上層軟體實現。由於不管上層音量怎麼改變，這里看到的都是24（以我使用的設備為例）。
通道的切換是真正使用了tinyalsa，當通過不同通道播放音樂的時候能夠實時觀察到通道的切換。在某個站點上看到Android在沒有聲音播放的3秒後會關閉alsa，這里也得到了證實，我曾經覺得Android系統會永久佔用音頻設備。
當通過藍牙播放音樂的時候，已經不經過alsa了，tinymix查看到都處理關閉狀態。由於Android4.2的藍牙協議所有在用戶層實現了，直接走uart通道。
一般播放1khz 0db正弦波，然後在codec輸出端示波器簡單測量是否失真，雜音，然後再使用音頻分析儀測試指標。
tinyalsa源碼
原文： https://www.cnblogs.com/yxwkf/p/5344068.html
Ⅸ android audio 怎麼切換到dmic
android audio 切換到dmic 的辦法鎮慶
tinyalsa訪問設備節點應該是/dev/snd/pcmCxDxp, /dev/snd/pcmCxDxc和/dev/snd/controlCx，畫圖時沒有確認造成筆誤這個框圖大致把soundrecorder從app到framework到HAL的類圖畫了出來
2.有些子類父類繼承關系沒有表示出來，從soundrecorder到AudioRecord基本就是一條線下來
3.我也沒有詳細去看代碼，stagefright這一塊很龐大，實現了多種mime格式的編解碼
音頻數據生成文件保存在sd卡中應該是在MPEG4Writer這里完成的，這個沒有細看
我們重點看喚信下AudioSystem，AudioPolicyService，AudioFlinger和AudioHardware這塊。
4.以open_record()和get_input()這兩個方法為例我們看下這幾個類之間的調用關御鏈握系
從AudioRecord.cpp開始，文件位置：frameworksasemedialibmediaAudioRecord.cpp
Ⅹ 4.Android音頻驅動(底層1)
Android使用的音頻驅動庫是tinyalsa，所以後面的說明都是基於驅動程序與tinyalsa的。
生成的文件在out/target/proct/tiny4412/symbols/system/bin/目錄下。
然後可以將生成的文件拷貝到SD卡中：
在Android系統中基亂，如果出現：
解決辦法為：
之後，就可以將文件拷貝到Android中了模緩。
要注意，使用tinyplay的時候，最好查看一下要播旦鋒模放的文件的格式，我是用過cooledit製作音頻文件，發現是不符合tinyplay格式要求的。
需要注意的是如下內容：
按照紅色劃分，主要是根據分析tinyplay.c源碼分析出來的。
可以看到數據組織格式為：
tinyplay是支持16bits per sample，2聲道。我在cooledit上報錯主要原因是這里不正確。
經過驗證，在Tiny4412開發板上，播放與錄制音頻都能成功。