标签:android blog http os io 使用 ar for 文件
昨天(2011-11-15)发布了Android4.0的源码,今天download下来,开始挺进4.0时代。简单看了一下,发现音频系统方面与2.3的有较多地方不同,下面逐一描述。
一、代码模块位置
1、AudioFlinger
- frameworks/base/services/audioflinger/
- +-- Android.mk
- +-- AudioBufferProvider.h
- +-- AudioFlinger.cpp
- +-- AudioFlinger.h
- +-- AudioMixer.cpp
- +-- AudioMixer.h
- +-- AudioPolicyService.cpp
- +-- AudioPolicyService.h
- +-- AudioResampler.cpp
- +-- AudioResamplerCubic.cpp
- +-- AudioResamplerCubic.h
- +-- AudioResampler.h
- +-- AudioResamplerSinc.cpp
- +-- AudioResamplerSinc.h
AudioFlinger相关代码,好像这部分与2.3相差不大,至少接口是兼容的。值得注意的是:2.3位于这里的还有AudioHardwareGeneric、AudioHardwareInterface、A2dpAudioInterface等一系列接口代码,现在都移除了。实际上,这些接口变更为legacy(有另外更好的实现方式,但也兼容之前的方法),取而代之的是要实现hardware/libhardware/include/hardware/audio.h提供的接口,这是一个较大的变化。
两种Audio Hardware HAL接口定义:
1/ legacy:hardware/libhardware_legacy/include/hardware_legacy/AudioHardwareInterface.h
2/ current:hardware/libhardware/include/hardware/audio.h
- hardware/libhardware_legacy/audio/
- +-- A2dpAudioInterface.cpp
- +-- A2dpAudioInterface.h
- +-- Android.mk
- +-- AudioDumpInterface.cpp
- +-- AudioDumpInterface.h
- +-- AudioHardwareGeneric.cpp
- +-- AudioHardwareGeneric.h
- +-- AudioHardwareInterface.cpp
- +-- AudioHardwareStub.cpp
- +-- AudioHardwareStub.h
- +-- audio_hw_hal.cpp
- +-- AudioPolicyCompatClient.cpp
- +-- AudioPolicyCompatClient.h
- +-- audio_policy_hal.cpp
- +-- AudioPolicyManagerBase.cpp
- +-- AudioPolicyManagerDefault.cpp
- +-- AudioPolicyManagerDefault.h
上面提及的AudioHardwareGeneric、AudioHardwareInterface、A2dpAudioInterface等都放到libhardware_legacy里。
事实上legacy也要封装成current中的audio.h,确切的说需要一个联系legacy interface和not legacy interface的中间层,这里的audio_hw_hal.cpp就充当这样的一个角色了。因此,我们其实也可以把2.3之前的alsa_sound这一套东西也搬过来。
- hardware/libhardware/modules/audio/
- +-- Android.mk
- +-- audio_hw.c
- +-- audio_policy.c
这是一个stub(类似于2.3中的AudioHardwareStub),大多数函数只是简单的返回一个值,并没有实际操作,只是保证Android能得到一个audio hardware hal实例,从而启动运行,当然声音没有输出到外设的。在底层音频驱动或audio hardware hal还没有实现好的情况下,可以使用这个stub device,先让Android跑起来。
- device/samsung/tuna/audio/
- +-- Android.mk
- +-- audio_hw.c
- +-- ril_interface.c
- +-- ril_interface.h
这是Samsung Tuna的音频设备抽象层,很有参考价值,计划以后就在它的基础上进行移植。它调用tinyalsa的接口,可见这个方案的底层音频驱动是alsa。
- external/tinyalsa/
- +-- Android.mk
- +-- include
- | +-- tinyalsa
- | +-- asoundlib.h
- +-- mixer.c ##类alsa-lib的control,作用音频部件开关、音量调节等
- +-- pcm.c ##类alsa-lib的pcm,作用音频pcm数据回放录制
- +-- README
- +-- tinycap.c ##类alsa_arecord
- +-- tinymix.c ##类alsa_amixer
- +-- tinyplay.c ##类alsa_aplay
在2.3时代,Android还隐晦把它放在android2.3.1-gingerbread/device/samsung/crespo/libaudio,现在终于把alsa-lib一脚踢开,小三变正室了,正名tinyalsa。
这其实是历史的必然了,alsa-lib太过复杂繁琐了,我看得也很不爽;更重要的商业上面的考虑,必须移除被GNU GPL授权证所约束的部份,alsa-lib并不是个例。
注意:上面的hardware/libhardware_legacy/audio/、hardware/libhardware/modules/audio/、device/samsung/tuna/audio/是同层的。之一是legacy audio,用于兼容2.2时代的alsa_sound;之二是stub audio接口;之三是Samsung Tuna的音频抽象层实现。调用层次:AudioFlinger -> audio_hw -> tinyalsa。
二、Audio Hardware HAL加载
1、AudioFlinger
- static int load_audio_interface(const char *if_name, const hw_module_t **mod,
- audio_hw_device_t **dev)
- {
- int rc;
-
-
- rc = hw_get_module_by_class(AUDIO_HARDWARE_MODULE_ID, if_name, mod);
- if (rc)
- goto out;
-
-
- rc = audio_hw_device_open(*mod, dev);
- LOGE_IF(rc, "couldn‘t open audio hw device in %s.%s (%s)",
- AUDIO_HARDWARE_MODULE_ID, if_name, strerror(-rc));
- if (rc)
- goto out;
-
- return 0;
-
- out:
- *mod = NULL;
- *dev = NULL;
- return rc;
- }
-
- static const char *audio_interfaces[] = {
- "primary",
- "a2dp",
- "usb",
- };
- #define ARRAY_SIZE(x) (sizeof((x))/sizeof(((x)[0])))
-
-
- AudioFlinger::AudioFlinger()
- : BnAudioFlinger(),
- mPrimaryHardwareDev(0), mMasterVolume(1.0f), mMasterMute(false), mNextUniqueId(1),
- mBtNrecIsOff(false)
- {
- }
-
- void AudioFlinger::onFirstRef()
- {
- int rc = 0;
-
- Mutex::Autolock _l(mLock);
-
-
- mHardwareStatus = AUDIO_HW_IDLE;
-
-
- for (size_t i = 0; i < ARRAY_SIZE(audio_interfaces); i++) {
- const hw_module_t *mod;
- audio_hw_device_t *dev;
-
- rc = load_audio_interface(audio_interfaces[i], &mod, &dev);
- if (rc)
- continue;
-
- LOGI("Loaded %s audio interface from %s (%s)", audio_interfaces[i],
- mod->name, mod->id);
- mAudioHwDevs.push(dev);
-
- if (!mPrimaryHardwareDev) {
- mPrimaryHardwareDev = dev;
- LOGI("Using ‘%s‘ (%s.%s) as the primary audio interface",
- mod->name, mod->id, audio_interfaces[i]);
- }
- }
-
- mHardwareStatus = AUDIO_HW_INIT;
-
- if (!mPrimaryHardwareDev || mAudioHwDevs.size() == 0) {
- LOGE("Primary audio interface not found");
- return;
- }
-
-
- for (size_t i = 0; i < mAudioHwDevs.size(); i++) {
- audio_hw_device_t *dev = mAudioHwDevs[i];
-
- mHardwareStatus = AUDIO_HW_INIT;
- rc = dev->init_check(dev);
- if (rc == 0) {
- AutoMutex lock(mHardwareLock);
-
- mMode = AUDIO_MODE_NORMAL;
- mHardwareStatus = AUDIO_HW_SET_MODE;
- dev->set_mode(dev, mMode);
- mHardwareStatus = AUDIO_HW_SET_MASTER_VOLUME;
- dev->set_master_volume(dev, 1.0f);
- mHardwareStatus = AUDIO_HW_IDLE;
- }
- }
- }
以上对AudioFlinger进行的分析,主要是通过hw_get_module_by_class()找到模块接口名字if_name相匹配的模块库,加载,然后audio_hw_device_open()调用模块的open方法,完成音频设备模块的初始化。
留意AudioFlinger的构造函数只有简单的私有变量的初始化操作了,把音频设备初始化放到onFirstRef(),Android终于改进了这一点,好的设计根本不应该把可能会失败的操作放到构造函数中。onFirstRef是RefBase类的一个虚函数,在构造sp的时候就会被调用。因此,在构造sp<AudioFlinger>的时候就会触发onFirstRef方法,从而完成音频设备模块初始化。
我们接下来看看hw_get_module_by_class,实现在hardware/libhardware/ hardware.c中,它作用加载指定名字的模块库(.so文件),这个应该是用于加载所有硬件设备相关的库文件,并不只是音频设备。
- int hw_get_module_by_class(const char *class_id, const char *inst,
- const struct hw_module_t **module)
- {
- int status;
- int i;
- const struct hw_module_t *hmi = NULL;
- char prop[PATH_MAX];
- char path[PATH_MAX];
- char name[PATH_MAX];
-
- if (inst)
- snprintf(name, PATH_MAX, "%s.%s", class_id, inst);
- else
- strlcpy(name, class_id, PATH_MAX);
-
-
-
-
-
-
-
-
- for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {
- if (i < HAL_VARIANT_KEYS_COUNT) {
-
- if (property_get(variant_keys[i], prop, NULL) == 0) {
- continue;
- }
- snprintf(path, sizeof(path), "%s/%s.%s.so",
- HAL_LIBRARY_PATH2, name, prop);
- if (access(path, R_OK) == 0) break;
-
- snprintf(path, sizeof(path), "%s/%s.%s.so",
- HAL_LIBRARY_PATH1, name, prop);
- if (access(path, R_OK) == 0) break;
- } else {
- snprintf(path, sizeof(path), "%s/%s.default.so",
- HAL_LIBRARY_PATH1, name);
- if (access(path, R_OK) == 0) break;
- }
- }
-
-
-
- status = -ENOENT;
- if (i < HAL_VARIANT_KEYS_COUNT+1) {
-
- status = load(class_id, path, module);
- }
-
- return status;
- }
load()函数不详细分析了,它通过dlopen加载库文件,然后dlsym找到hal_module_info的首地址。我们先看看hal_module_info的定义:
- typedef struct hw_module_t {
-
- uint32_t tag;
-
-
- uint16_t version_major;
-
-
- uint16_t version_minor;
-
-
- const char *id;
-
-
- const char *name;
-
-
- const char *author;
-
-
- struct hw_module_methods_t* methods;
-
-
- void* dso;
-
-
- uint32_t reserved[32-7];
-
- } hw_module_t;
-
- typedef struct hw_module_methods_t {
-
- int (*open)(const struct hw_module_t* module, const char* id,
- struct hw_device_t** device);
-
- } hw_module_methods_t;
这个结构体很重要,注释很详细。dlsym拿到这个结构体的首地址后,就可以调用Modules methods进行设备模块的初始化了。设备模块中,都应该按照这个格式初始化好这个结构体,否则dlsym找不到它,也就无法调用Modules methods进行初始化了。
例如,在audio_hw.c中,它是这样定义的:
- static struct hw_module_methods_t hal_module_methods = {
- .open = adev_open,
- };
-
- struct audio_module HAL_MODULE_INFO_SYM = {
- .common = {
- .tag = HARDWARE_MODULE_TAG,
- .version_major = 1,
- .version_minor = 0,
- .id = AUDIO_HARDWARE_MODULE_ID,
- .name = "Tuna audio HW HAL",
- .author = "The Android Open Source Project",
- .methods = &hal_module_methods,
- },
- };
3、audio_hw
好了,经过一番周折,又dlopen又dlsym的,终于进入我们的audio_hw。这部分没什么好说的,按照hardware/libhardware/include/hardware/audio.h定义的接口实现就行了。这些接口全扔到一个结构体里面的,这样做的好处是:不必用大量的dlsym来获取各个接口函数的地址,只需找到这个结构体即可,从易用性和可扩充性来说,都是首选方式。
接口定义如下:
- struct audio_hw_device {
- struct hw_device_t common;
-
-
- uint32_t (*get_supported_devices)(const struct audio_hw_device *dev);
-
-
- int (*init_check)(const struct audio_hw_device *dev);
-
-
- int (*set_voice_volume)(struct audio_hw_device *dev, float volume);
-
-
- int (*set_master_volume)(struct audio_hw_device *dev, float volume);
-
-
- int (*set_mode)(struct audio_hw_device *dev, int mode);
-
-
- int (*set_mic_mute)(struct audio_hw_device *dev, bool state);
- int (*get_mic_mute)(const struct audio_hw_device *dev, bool *state);
-
-
- int (*set_parameters)(struct audio_hw_device *dev, const char *kv_pairs);
-
-
- char * (*get_parameters)(const struct audio_hw_device *dev,
- const char *keys);
-
-
- size_t (*get_input_buffer_size)(const struct audio_hw_device *dev,
- uint32_t sample_rate, int format,
- int channel_count);
-
-
- int (*open_output_stream)(struct audio_hw_device *dev, uint32_t devices,
- int *format, uint32_t *channels,
- uint32_t *sample_rate,
- struct audio_stream_out **out);
-
- void (*close_output_stream)(struct audio_hw_device *dev,
- struct audio_stream_out* out);
-
-
- int (*open_input_stream)(struct audio_hw_device *dev, uint32_t devices,
- int *format, uint32_t *channels,
- uint32_t *sample_rate,
- audio_in_acoustics_t acoustics,
- struct audio_stream_in **stream_in);
-
- void (*close_input_stream)(struct audio_hw_device *dev,
- struct audio_stream_in *in);
-
-
- int (*dump)(const struct audio_hw_device *dev, int fd);
- };
- typedef struct audio_hw_device audio_hw_device_t;
注:这是比较标准的C接口设计方法了,但是个人感觉还是用C++比较好,直观易读。2.3之前都是用C++实现这些接口设计的,到了4.0,不知道为何采纳用C?不会理由是做底层的不懂C++吧?!
三、Audio Hardware HAL的legacy实现
之前提到两种Audio Hardware HAL接口定义:
1/ legacy:hardware/libhardware_legacy/include/hardware_legacy/AudioHardwareInterface.h
2/ current:hardware/libhardware/include/hardware/audio.h
前者是2.3及之前的音频设备接口定义,后者是4.0的接口定义。
为了兼容以前的设计,4.0实现一个中间层:hardware/libhardware_legacy/audio/audio_hw_hal.cpp,结构与其他的audio_hw.c大同小异,差别在于open方法:
- static int legacy_adev_open(const hw_module_t* module, const char* name,
- hw_device_t** device)
- {
- ......
-
- ladev->hwif = createAudioHardware();
- if (!ladev->hwif) {
- ret = -EIO;
- goto err_create_audio_hw;
- }
-
- ......
- }
看到那个熟悉的createAudioHardware()没有?这是以前我提到的Vendor Specific Audio接口,然后新的接口再调用ladev->hwif的函数就是了。
因此老一套的alsa-lib、alsa-utils和alsa_sound也可以照搬过来,这里的文件被编译成静态库的,因此你需要修改alsa_sound里面的Android.mk文件,链接这个静态库。还有alsa_sound的命名空间原来是“android”,现在需要改成“android_audio_legacy”。
四、a2dp Audio HAL的实现
4.0的a2dp audio hal放到bluez里实现了,我找了好一会才找到:
external/Bluetooth/bluez/audio/android_audio_hw.c
大致与上面提到的audio_hw.c类似,因为都是基于audio.h定义的接口来实现的。
如果需要编译这个库,须在BoardConfig.mk里定义:
BOARD_HAVE_BLUETOOTH := true
开始还提到现在支持3种audio设备了,分别是primary、a2dp和usb。目前剩下usb audio hal我没有找到,不知是否需要自己去实现?其实alsa-driver都支持大部分的usb-audio设备了,因此上层也可调用tinyalsa的接口,就像samsung tuna的audio_hw.c那样。
五、音质改进???
可使用audio echo cancel和更好的resampler(SRC)???
--to be continued…
转自:http://blog.csdn.net/azloong/article/details/6978484
转:ANDROID音频系统散记之四:4.0音频系统HAL初探
标签:android blog http os io 使用 ar for 文件
原文地址:http://www.cnblogs.com/albert1017/p/3949398.html