Android下音频的测试程序tinyalsa(录音,放音,查看声卡信息)

简介: audio代码比较复杂,除了音频参数,我们平时客制化的地方不多。所以没有太深入了解。建议先抽空看看如下代码:kernel, linux alsa 架构:kernel-3.10/sound/soc/mediatek/kernel-3.

audio代码比较复杂,除了音频参数,我们平时客制化的地方不多。所以没有太深入了解。

建议先抽空看看如下代码:

kernel, linux alsa 架构:
kernel-3.10/sound/soc/mediatek/
kernel-3.10/Documentation/sound/alsa/soc/

android 上层alsa接口
external/tinyalsa/

hal:
vendor/mediatek/proprietary/platform/common/hardware/audio/
vendor/mediatek/proprietary/platform/mt6735/hardware/audio/

andorid audio flinger:
frameworks/av/services/audioflinger/


tinyalsa位于Android源码的external/tinyalsa位置。


关于tinyalsa,tinyalsa是Google在Android 4.0之后推的基于alsa内核的用户层音频接口。在Android 4.0之前还一直是使用这alsa-lib接口。Google之所以推出tinyalsa,我认为有可能是因为alsa使用了GPL许可证的缘故,也有可能是因为alsa-lib的库过于复杂繁琐大部分功能在Android平台没有实际实用意义却依然占用屈指可数的内存空间。

关于alsa在Android中,在Android 4.0及之后只要你愿意还是可以使用原版alsa的,因为内核中依然是使用alsa的驱动,只需要把alsa的用户层接口alsa-lib移植到源码中即可。

tinyalsa中主要的头文件和数据结构如下,通过ioctrl和内核的alsa驱动交互。

tinyalsa.bmp

pcm设备,通过阅读tinyalsa的代码和查看Android下的音频设备节点,可知在Android中一个pcm设备最多可有一个mixer设备"/dev/snd/controlC%u"(一般是controlC0)和32个/dev/snd/pcmC%uD%uc(一般是pcmC0D0c)、/dev/snd/pcmC%uD%u%p (一般是pcmC0D0p),pcm设备中的C代表card,D代表device,c代表capture,p代表playback。当我们新增一个pcm声卡C的值会+1,D还是从0开始,可能只有c(pcmC1D0c 例如麦克风),可能只有p(pcmC1D0p 例如音响 ),可能同时存在c和p( pcmC1D0c    pcmC1D0p   )。

tinyalsa的对外提供的头文件就我上图提到的一个" asoundlib.h",提供最基础的pcm和mixer操作。实现文件为 pcm.c(实现pcm api)和mixer.c(实现mixer api)。根据asoundlib.h编写了四个小工具 tinypcminfo tinyplay tinycap tinymix,这四个小工具作为系统命令存放在系统中,可以很方便的使用。tinyasla作为精简版的alsa-lib可能会有人想把它移植到Linux使用, tinyasla 依赖的库有libcutils && libutils,如果能把依赖的这两个库的一些方法使用Linux接口实现那么剩下的问题应该不大了吧,这个仅仅是我的猜想。
tinypcminfo的实现文件 tinypcminfo.c (查看pcm设备能力)
tinyplay的实现文件 tinyplay.c(使用pcm设备播放wav格式的音频文件)
tinycap的实现文件 tinycap.c(使用pcm设备采集pcm格式的码流,并保存为wav格式的文件)
tinymix的实现文件 tinymix.c(对pcm设备的控制,包括音量调节、设备切换)
这几个命令使用时可以先使用tinypcminfo查看pcm设备的能力,要不当我们使用其他三个命令时使用了不合理的配置会出现parameter invalid的错误。

PCM API
   
   
/* 对pcm设备节点的操作 */
struct pcm *pcm_open(unsigned int card, unsigned int device, unsigned int flags, struct pcm_config *config);
int pcm_close(struct pcm *pcm);
int pcm_is_ready(struct pcm *pcm);
 
/* 获取pcm设备的能力 */
struct pcm_params *pcm_params_get(unsigned int card, unsigned int device, unsigned int flags);
void pcm_params_free(struct pcm_params *pcm_params);
unsigned int pcm_params_get_min(struct pcm_params *pcm_params, enum pcm_param param);
unsigned int pcm_params_get_max(struct pcm_params *pcm_params, enum pcm_param param);
 
/* 配置pcm设备capture和playback的规格 */
int pcm_get_config(struct pcm *pcm, struct pcm_config *config);
int pcm_set_config(struct pcm *pcm, struct pcm_config *config);
 
/* 返回调用tinyalsa最后的错误信息 */
const char *pcm_get_error(struct pcm *pcm);
 
/* 设置pcm设备采集和播放的位数,位数越高越接近真实声音 */
unsigned int pcm_format_to_bits(enum pcm_format format);
 
/* pcm设备的内置缓冲之间大小、帧数、时间的转换 */
unsigned int pcm_get_buffer_size(struct pcm *pcm);
unsigned int pcm_frames_to_bytes(struct pcm *pcm, unsigned int frames);
unsigned int pcm_bytes_to_frames(struct pcm *pcm, unsigned int bytes);
unsigned int pcm_get_latency(struct pcm *pcm); // in ms
 
/* 返回下一帧的有效帧指针和该帧时间戳,时间戳有CLOCK_MONOTONIC和CLOCK_REALTIME可选,里面使用的是CLOCK_REALTIME */
/* 我认为应该需要两个时间戳,一个用于播放的时间戳(CLOCK_MONOTONIC)不受系统时间的影响,一个用于记录当前音频采集的时间戳(CLOCK_REALTIME) */
int pcm_get_htimestamp(struct pcm *pcm, unsigned int *avail, struct timespec *tstamp);
 
/* 通过FIFO把数据写入硬件用于playback或者从硬件中读取capture数据 */
int pcm_write(struct pcm *pcm, const void *data, unsigned int count);
int pcm_read(struct pcm *pcm, void *data, unsigned int count);
 
/* 这是一个可选的和hardware通信的方式。 */
int pcm_mmap_write(struct pcm *pcm, const void *data, unsigned int count);
int pcm_mmap_read(struct pcm *pcm, void *data, unsigned int count);
int pcm_mmap_begin(struct pcm *pcm, void **areas, unsigned int *offset, unsigned int *frames);
int pcm_mmap_commit(struct pcm *pcm, unsigned int offset, unsigned int frames);
int pcm_start(struct pcm *pcm);
int pcm_stop(struct pcm *pcm);
int pcm_wait(struct pcm *pcm, int timeout);
int pcm_set_avail_min(struct pcm *pcm, int avail_min);
对于pcm设备的操作只需要注意所操作的设备是否存在,以及设备的能力问题不要设置设备所不能及的能力设备就可以正常工作了,其实就是需要注意channels、rate、format、period_size和period_count。

MIXER API
   
   
/* 对mixer设备的操作 */
struct mixer *mixer_open(unsigned int card);
void mixer_close(struct mixer *mixer);
 
/* 获取mixer设备信息name */
const char *mixer_get_name(struct mixer *mixer);
 
/* 获取mixer设备的控制句柄 struct mixer_ctl */
unsigned int mixer_get_num_ctls(struct mixer *mixer);
struct mixer_ctl *mixer_get_ctl(struct mixer *mixer, unsigned int id);
struct mixer_ctl *mixer_get_ctl_by_name(struct mixer *mixer, const char *name);
 
/* 取mixer设备的控制信息 */
const char *mixer_ctl_get_name(struct mixer_ctl *ctl);
enum mixer_ctl_type mixer_ctl_get_type(struct mixer_ctl *ctl);
const char *mixer_ctl_get_type_string(struct mixer_ctl *ctl);
unsigned int mixer_ctl_get_num_values(struct mixer_ctl *ctl);
unsigned int mixer_ctl_get_num_enums(struct mixer_ctl *ctl);
const char *mixer_ctl_get_enum_string(struct mixer_ctl *ctl, unsigned int enum_id);
 
/* Some sound cards update their controls due to external events,
* such as HDMI EDID byte data changing when an HDMI cable is
* connected. This API allows the count of elements to be updated.
*/
void mixer_ctl_update(struct mixer_ctl *ctl);
 
/* 设置和获取可控制的信息,方式有比例、数组、范围、固定值 */
/* id通过mixer_get_num_ctls获得 */
int mixer_ctl_get_percent(struct mixer_ctl *ctl, unsigned int id);
int mixer_ctl_set_percent(struct mixer_ctl *ctl, unsigned int id, int percent);
 
int mixer_ctl_get_value(struct mixer_ctl *ctl, unsigned int id);
int mixer_ctl_get_array(struct mixer_ctl *ctl, void *array, size_t count);
int mixer_ctl_set_value(struct mixer_ctl *ctl, unsigned int id, int value);
int mixer_ctl_set_array(struct mixer_ctl *ctl, const void *array, size_t count);
int mixer_ctl_set_enum_by_string(struct mixer_ctl *ctl, const char *string);
 
int mixer_ctl_get_range_min(struct mixer_ctl *ctl);
int mixer_ctl_get_range_max(struct mixer_ctl *ctl);
MIXER使用,有哪些属性,干什么用的,看名字就已经很清楚了。
     
     
// 原始状态
root@pone:/data/local/tmp # tinymix -D 1
Mixer name: 'mixer_name_xx'
Number of controls: 2
ctl type num name value
0 BOOL 1 Mic Capture Switch Off
1 INT 1 Mic Capture Volume 256
 
// 详细信息
root@pone:/data/local/tmp # tinymix -D 1 0
Mic Capture Switch: Off
root@pone:/data/local/tmp # tinymix -D 1 1
Mic Capture Volume: 256 (range 0->256)
 
// 设置
root@pone:/data/local/tmp # tinymix -D 1 0 1
root@pone:/data/local/tmp # tinymix -D 1 1 250
 
// 修改后的状态
root@pone:/data/local/tmp # tinymix -D 1
Mixer name: 'mixer_name_xx'
Number of controls: 2
ctl type num name value
0 BOOL 1 Mic Capture Switch On
1 INT 1 Mic Capture Volume 250



扩展:
1. 什么是pcm
2. 音频采样

目前Linux中主流的音频体系结构是ALSA(Advanced Linux Sound Architecture),ALSA在内核驱动层提供了alsa-driver,在应用层提供了alsa-lib,应用程序只需要调用alsa-lib提供的API就可以完成对底层硬件的操作。说的这么好,但是Android中没有使用标准的ALSA,而是一个ALSA的简化版叫做tinyalsa。Android中使用tinyalsa控制管理所有模式的音频通路,我们也可以使用tinyalsa提供的工具进行查看、调试。

编译tinyalsa后生成四个小工具:

[objc]  view plain  copy
  1. tinymix  
  2. tinyplay  
  3. tinycap  
  4. tinypcminfo  

编译命令:

[objc]  view plain  copy
  1. mmm external/tinyalsa/  


下面依次演示一下四个小工具的使用:(以下使用联芯科技的LC1860平台配合LC1160电源+音频芯片,截图及演示效果均来自M7301P5测试机)

1,  tinypcminfo

tinypcminfo用于查看pcm通道的相关信息

输入:

[objc]  view plain  copy
  1. tinypcminfo -D /proc/asound/cards  

结果如下:


从上面获得的信息中可以知道PCM的采样率,通道个数,采样点数等信息。

其中 –D 后边跟的参数为声卡文件,一般位于/proc/asound/cards。可以使用

[objc]  view plain  copy
  1. cat /proc/asound/cards  
查看当前声卡

2,  tinymix

如下图所示,直接输入tinymix可以得到音频通路相关的各项配置参数。也可以通过添加参数修改其中的配置,如希望提高ADC1 Gain值到110,输入tinymix 12 110即可。


单独查看上述信息比较难以梳理,配合音频通路图会更加清晰。


上图中红色字体标明了LC1160与麦克风、耳机等硬件设备的连接关系。(注:M73xx项目由于内部ClassD不满足要求,喇叭连在了AUX通路上)

各个通路上的增益调节部分使用绿色字体标出了与tinymix中选项的对应关系。

图中加号与Mux是通路选择开关,对应tinymix中的其它的选项,用于在各种模式下切换音频通道。此部分比较多没有在图中一一标出,但根据已知的通路名是比较容易对应的。

图中黄色箭头标出的是通话时下行音频数据流,从PCM接口进入到LC1160,然后经过MonoDAC进行数模转化后送到听筒。

图中紫色箭头标出的是通话时上行音频数据流,从主MIC采集声音后,经过ADC1进行模数转换后由PMC的DO线送出

3,  tinyplay

tinyplay是一个简易的音乐播放器,一般用于播放测试。tinyplay只能播放wav原始格式的音乐,不能进行Mp3等格式的解码,支持44.1kHz,48kHz采样率的wav音乐。

在调用tinyplay播放音乐之前需要先使用tinymix切换好音频通路:

[objc]  view plain  copy
  1. tinymix 0 I2SR      //选择Stereo DACR的音源为i2s  
  2. tinymix 1 I2SL      //选择Stereo DACL的音源为i2s  
  3. tinymix 2 0 0       //将Stereo DAC左右声道的mute关闭  
  4. tinymix 24 1        //开启喇叭的外部PA芯片  
  5. tinymix 40 1        //将Stereo DACR的声音路由到AUX口输出(因为实验机器喇叭挂载AUX接口上)  
  6. tinymix 41 1        //将Stereo DACR的声音路由到AUX口输出(因为实验机器喇叭挂载AUX接口上)  
  7. tinyplay z.wav  

4,  tinycap

tinycap是一个简易的录音软件,一般用于录音测试。

在调用tinycap录音之前需要先调整好音频通路:

[objc]  view plain  copy
  1. tinymix 14 30           //mic1 volume  
  2. tinymix 19 1            //mic1 boost on  
  3. tinymix 26 1            //adc1 -> mic1  
  4. tinymix 50 ADC1         //i2sR out -> adc1  
  5. tinymix 51 ADC1     //i2sL out -> adc2  
  6. echo "0xfb 0x01" >  /sys/devices/platform/comip_codec/lc1160_reg     //bias poweron  
  7. echo "0xad 0x08" >  /sys/devices/platform/comip_codec/lc1160_reg //adc1 enable  
  8. echo "0xac 0x01" >  /sys/devices/platform/comip_codec/lc1160_reg     //mic1 pga enable  
  9. echo "0x3b 0xcc" >  /sys/devices/platform/comip_codec/lc1160_reg     //ldo  
  10. echo 2 > /sys/bus/i2c/drivers/fm2018/0-0060/mode     //bypass 外部的回声消除音频芯片(M730x项目特有)  
  11.   
  12. tinycap /sdcard/Music/l.wav  

录音结束通过ctrl+C强行退出即可,之后在/sdcard/Music/路径下查看到l.wav音频文件

使用adb pull到本地电脑中,使用goldwave播放、查看。

[objc]  view plain  copy
  1. adb pull /sdcard/Music/l.wav d:\  



另外

LC1160的寄存器是分页的,即同一个地址上存在两个不同含义的寄存器,通过控制0xFC寄存器中的值来切换到第二功能页

[objc]  view plain  copy
  1. echo "0xfc 0x01" >  /sys/devices/platform/comip_codec/lc1160_reg   
  2. cat /sys/devices/platform/comip_codec/lc1160_reg  
  3. echo "0xfc 0x00" >  /sys/devices/platform/comip_codec/lc1160_reg  




目录
相关文章
|
1月前
|
存储 数据采集 分布式计算
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
44 1
|
1月前
|
Java Unix Linux
Android Studio中Terminal运行./gradlew clean build提示错误信息
遇到 `./gradlew clean build`命令执行出错时,首先应检查错误信息的具体内容,这通常会指向问题的根源。从权限、环境配置、依赖下载、版本兼容性到项目配置本身,逐一排查并应用相应的解决措施。记住,保持耐心,逐步解决问题,往往复杂问题都是由简单原因引起的。
243 2
|
1月前
|
安全 Linux 网络安全
Kali渗透测试:远程控制程序基础
Kali渗透测试:远程控制程序基础
Kali渗透测试:远程控制程序基础
|
2月前
|
Java 测试技术 Android开发
Android性能测试——发现和定位内存泄露和卡顿
本文详细介绍了Android应用性能测试中的内存泄漏与卡顿问题及其解决方案。首先,文章描述了使用MAT工具定位内存泄漏的具体步骤,并通过实例展示了如何分析Histogram图表和Dominator Tree。接着,针对卡顿问题,文章探讨了其产生原因,并提供了多种测试方法,包括GPU呈现模式分析、FPS Meter软件测试、绘制圆点计数法及Android Studio自带的GPU监控功能。最后,文章给出了排查卡顿问题的四个方向,帮助开发者优化应用性能。
174 4
Android性能测试——发现和定位内存泄露和卡顿
|
2月前
|
测试技术 Shell Android开发
Android 性能测试初探 (六)
本节聊聊性能测试的最后一项- 流量,当然我所指的性能测试是针对大部分应用而言的,可能还有部分应用会关注网速、弱网之类的测试,但本系列文章都不去一一探讨了。
55 6
|
2月前
|
JavaScript 测试技术 Android开发
Android 性能测试初探 (四)
本文介绍了GPU在移动端性能测试中的重要性,并详细解释了过度绘制、帧率和帧方差的概念。针对GPU测试,文章列举了三项主要测试内容:界面过度绘制、屏幕滑动帧速率和平滑度。其中,过度绘制测试需遵循特定标准,而帧速率和平滑度测试则可通过软件或硬件方法实现。在软件测试中,使用Systrace插件和高速相机是两种常用手段。对于不同机型,帧率及帧方差的测试标准也需相应调整。
55 5
|
2月前
|
测试技术 Shell Android开发
Android 性能测试初探 (三)
本文承接《Android性能测试初探(二)》,深入探讨CPU与内存测试。介绍了移动端内存测试的重要性及其测试目标,并详细列举了不同状态下应用内存消耗情况的测试项目。此外,还提供了多种内存测试方法,包括使用`procrank`等工具的具体操作步骤。最后,文章也简要提及了CPU测试的相关内容,帮助读者更好地理解Android性能测试的关键要素。
52 5
|
1月前
|
安全 Java Linux
Kali渗透测试:通过Web应用程序实现远程控制
Kali渗透测试:通过Web应用程序实现远程控制
|
2月前
|
测试技术 Shell 定位技术
Android 性能测试初探 (五)
聊聊大家不常关注的测试项- 功耗
51 3
|
2月前
|
算法 测试技术 Android开发
Android 性能测试初探 (二)
上回大体介绍了下在 android 端的性能测试项,现在我们就细节测试项做一些阐述(包括如何自己 DIY 测试)
48 4

热门文章

最新文章