首先我从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开发板上，播放与录制音频都能成功。