音频hal层总结+frameworks 概要
音频hal层总结+frameworks概要
第一部分
三个文件,其中所有类,都为根类.文件地址:
1:Audio.h有四个类
①.audio_stream_out:主要有四个成员函数: *get_latency set_volume write get_render_position 并且包含: struct audio_stream common;
②.audio_stream_in:主要有三个成员函数:set_gain(调音) read get_input_frames_lost
函数getInputFramesLost,调用checkRecordThread_l获取录音线程,然后调用线程的getInputFramesLost函数。
并且包含: struct audio_stream common;
③.struct audio_module { struct hw_module_t common; };
④. audio_hw_device包含很多成员函数
2: audio_effect.h音效文件先不表.
3: audio_policy.h策略管理
①. audio_policy:
②. audio_policy_service_ops
③.typedef struct audio_policy_module { struct hw_module_t common;} audio_policy_module_t;
④.audio_policy_device:
第二部分: STUB(模拟测试)程序
文件目录: 两个文件
1:audio_hw.c
2:audio_policy.c
这两个程序,其实就是两个Stub(模拟测试)程序.我们hal层可以参照来写.
第三部分:兼容2.3以前的程序文件目录:
1: AudioSystemLegacy.h
从namespace来看,确实4.0以后可能不用到. Using 使用名字空间表示以下代表在status_t和 AudioParameter空间可见..
2: AudioHardwareBase.h
3:AudioHardwareInterface.h
有三个类,AudioStreamOut AudioStreamIn AudioHardwareInterface
例AudioStreamIn 成员函员包括以下
其中Read和 Write函数是最关键的了.
4: AudioPolicyInterface.h
5: AudioPolicyManagerBase.h
上面两个都是音频软硬件策略文件了.
功能如:可以看出包括软硬件的策略管理.
第三部分之二(兼容2.3之前代码)文件路径:
从以下文件名可以知道程序功能:
以前的主程序,主要分为stub hw_hal a2dp policy 等四大块功能.
兼容的方法为如下:
/*
兼容以前的设计,4.0实现一个中间层:hardware/libhardware_legacy/audio/audio_hw_hal.cpp,
结构与其他的audio_hw.c大同小异,差别在于open方法:
[cpp] view plaincopystatic 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”---注意!!!
*/
第四部分:ALSA管理.代码目录:
文件结构
承接frameworks层服务端的总体接口.
如alsa_default.cpp的内容,为s_init s_open s_close等等, s_open里面调用了s_route,设置软硬件参数.
从内容上看这是amlogic在2.3之前的代码的现用程序.重点分析这一部分的数据流走向.
ALSA其实也就代表一种管理方法,简单地说就是这里的程序就是alsa , alsa就是这里.感觉和V4L2还是有一点小小的区别.
这部分代码现在google用tinyalsa来代替它,但是仍然保留了接口,可以供厂商不用tinyalsa(功能不够强大)时来代替它,只需要改一下*.mk文件即可.其实看一下也就十个文件,也不是很复杂的.当然,上层flinger和下层 kernel适配的地方同样要复杂一些.
ALSA要比v4l2复杂一些.它的内容主要是一些软件方法.而v4l2的内容是一些标准的接口命令.
同样,由于现在版本是4.0,不用这部分代码了,而用了\external\tinyalsa\.而tinyalsa则简单很多!
调用方法为: ./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。
以上除了ALSA部分以外,
全部是audio_hw的处理内容,下面讲第四部分,具体的执行者,tinyslsa.
第五部分:具体执行者 TinyALSA的分析.
1:下文件asoundlib.h.功能如下
其中: 为主体实现文件,为c语言编写的应用工具.
仅仅两个文件pcm.c和mixer.c,看来TinyALSA确实要简单很多!
而且两个文件都不大,加起来1200行代码. mixer.c主要是一些ioctl open memset等函数.
如:ioctl(ctl->mixer->fd, SNDRV_CTL_IOCTL_ELEM_WRITE, &ev);
Pcm.c主要是对数据流的一些操作;
主要函数有:pcm_bytes_to_frames; pcm_frames_to_bytes;
pcm_hw_mmap_status(struct pcm *pcm)中以下两个函数是关键函数.
pcm->mmap_control = mmap(NULL, page_size, PROT_READ | PROT_WRITE,
MAP_FILE | MAP_SHARED, pcm->fd, SNDRV_PCM_MMAP_OFFSET_CONTROL);
munmap(pcm->mmap_status, page_size);
mmap将一个文件或者其它对象映射进内存。文件被映射到多个页上,如果文件的大小不是所有页的大小之和,最后一个页不被使用的空间将会清零。munmap执行相反的操作,删除特定地址区域的对象映射。
pcm_mmap_writeàpcm_mmap_write_areasàpcm_areas_copyàmemcpy.
Mmap的写过程就是以上.
而pcm_mmap_commità pcm_sync_ptrà ioctl(pcm->fd, SNDRV_PCM_IOCTL_SYNC_PTR, pcm->sync_ptr);
这就是几个关键的pcm流操作函数,包括memcpy之内,最终由底层硬件实现具体功能.
而音频的响应速度,可以测一下 memcpy 这里的用法,看有没有启用cache等.
当然最重要的函数为:pcm_read pcm_write.
最终通过ioctl(pcm->fd, SNDRV_PCM_IOCTL_PREPARE);操作pcm->fd;
具体就到了/kernel/sound/core/pcm_native.c里面了.
如有疑问请参见以下网址:http://blog.csdn.net/myarrow/article/details/8228437
这个网址所说的alsa库调用方法,需要我们认真掌握.
附记一点,在kernel 里面也是可以使用ioctl的snd_pcm_kernel_ioctl(substream, SNDRV_PCM_IOCTL_START, NULL);
我这里在kernel中搜出来SNDRV_PCM_IOCTL_START的结果:
可见\kernel\include\sound\Asound.h这个头文件基本上定义了,所有的ALSA接口命令.
到目前为止没有看到音频格式转化函数.
第六部分: aml Kernel层代码分析
1:代码树
2:代码功能模块
3:硬件数据流及名词解析
我们从alsa在linux中的设备文件结构开始我们的alsa之旅.看看我的电脑中的alsa驱动的设备文件结构:
$ cd /dev/snd
$ ls -l
crw-rw----+ 1 root audio 116, 8 2011-02-23 21:38 controlC0
crw-rw----+ 1 root audio 116, 4 2011-02-23 21:38 midiC0D0
crw-rw----+ 1 root audio 116, 7 2011-02-23 21:39 pcmC0D0c
crw-rw----+ 1 root audio 116, 6 2011-02-23 21:56 pcmC0D0p
crw-rw----+ 1 root audio 116, 5 2011-02-23 21:38 pcmC0D1p
crw-rw----+ 1 root audio 116, 3 2011-02-23 21:38 seq
crw-rw----+ 1 root audio 116, 2 2011-02-23 21:38 timer
我们可以看到以下设备文件:
其中,C0D0代表的是声卡0中的设备0,pcmC0D0c最后一个c代表capture,pcmC0D0p最后一个p代表playback,这些都是alsa-driver中的命名规则。从上面的列表可以看出,我的声卡下挂了6个设备,根据声卡的实际能力,驱动实际上可以挂上更多种类的设备,在 include/sound/core.h中,定义了以下设备类型:
1. #define SNDRV_DEV_TOPLEVEL ((__force snd_device_type_t) 0)
2. #define SNDRV_DEV_CONTROL ((__force snd_device_type_t) 1)
3. #define SNDRV_DEV_LOWLEVEL_PRE ((__force snd_device_type_t) 2)
4. #define SNDRV_DEV_LOWLEVEL_NORMAL ((__force snd_device_type_t) 0x1000)
5. #define SNDRV_DEV_PCM ((__force snd_device_type_t) 0x1001)
6. #define SNDRV_DEV_RAWMIDI ((__force snd_device_type_t) 0x1002)
7. #define SNDRV_DEV_TIMER ((__force snd_device_type_t) 0x1003)
8. #define SNDRV_DEV_SEQUENCER ((__force snd_device_type_t) 0x1004)
9. #define SNDRV_DEV_HWDEP ((__force snd_device_type_t) 0x1005)
10. #define SNDRV_DEV_INFO ((__force snd_device_type_t) 0x1006)
11. #define SNDRV_DEV_BUS ((__force snd_device_type_t) 0x1007)
12. #define SNDRV_DEV_CODEC ((__force snd_device_type_t) 0x1008)
13. #define SNDRV_DEV_JACK ((__force snd_device_type_t) 0x1009)
14. #define SNDRV_DEV_LOWLEVEL ((__force snd_device_type_t) 0x2000)
通常,我们更关心的是pcm和control这两种设备。
5:---驱动,后续再分析,主要查看内存,及格式操作即可.也可以用通用的程序测试.
第七部分: FrameWorks层代码分析
1:文件架构
文件说明:由下至上.
audioflinger当然是核心处理文件.
Mediaserver 多媒体交互文件
Libstagefright 取代老的opencore程序功能.
Libeffects 音效处理类.
Libmedia:重点文件夹(重点说明):
BP(binder proxy)和BN(binder native)是通过binder来通信的。Bp主要是用来处理java层传下来的服务请求。然后通过transact将处理请求传给bn(通过binder)。
打开里面的这个文件夹,可以看到Bp*(承接java层本地端) Bn*(接c++远程服务端)类以及通用的流控制文件都在这里.因些可以断定audio从 jni下来之后到Hal的frameworks层的主要代码的主要代码都在这里.
包含了native及binder的两端本地 -------服务的代码.测试录音时,可以在这里增加对帧速的测试点.同时在Hal层也设立测试点,这样基本上可以判断是哪一层的音频处理的问题了.
右边这个是audio java库架层代码,jni上面一层的代码.给应用提供底层接口.
再右边这个,不用解释binder 和 jni层.
2:核心audioFlinger架构文件分析
默认的情况下,Android放音的采样率固定为44.1khz,录音的采样率固定为8khz,因此底层的音频设备驱动只需设置好这两个固定的采样率。如果上层传过来的采样率与其不符的话,则Android Framework层会对音频流做resample(重采样)处理。具体重采样的文章可以参阅以下文章:http://blog.csdn.net/zoe6553/article/details/7199543
排除掉重采样,可以发现AudioFlinger模块核心是四部分,buffer flinger mixer Policy;
具体分析flinger部分.
以上为audioflinger总的类图关系.
有以下类及主要功能:
①.class AudioFlinger : public BinderService<AudioFlinger>, public BnAudioFlinger
包括音频数据流和命令流的主要操作.
以下都是他的类中类.嵌套类中说明的成员不是外围类中对象的成员,反之亦然。嵌套类的成员函数对外围类的成员没有访问权,反之亦然。国此,在分析嵌套类和外围类的成员访问关系时,往往把嵌套类看作非嵌套类来处理。
②.class Client : public RefBase
本地端通信功能.
③.class NotificationClient : public IBinder::DeathRecipient
用于binder通信事件通知处理类.
④.class ThreadBase : public Thread
他包含四个子类:class TrackBase : public AudioBufferProvider, public RefBase
class ConfigEvent
class PMDeathRecipient : public IBinder::DeathRecipient
class SuspendedSessionDesc : public RefBase
音频frameworks层的总的线程管理程序.
⑤.class PlaybackThread : public ThreadBase
他包含2个子类:class Track : public TrackBase
如图OutputTrack
播放线程.
⑥.class MixerThread : public PlaybackThread
播放中的mixer操作.
⑦.class DirectOutputThread : public PlaybackThread
先看看AudioFlinger::PlaybackThread::addEffectChain_l函数中的处理,
函数中根据是否为DIRECT output thread,有两种处理方式:
一种是处理direct output thread:
调用函数setMainBuffer将PlaybackThread的mMixBuffer告诉给Track,即告诉Track,在AudioMixer中往PlaybackThread的mMixBuffer中copy数据。然后将effect chain的input buffer和output buffer都设置为PlaybackThread的mMixBuffer。(目的是让该effect chain不起作用?存在注释“Only one effect chain can be present in direct output thread and it usesthe mix buffer as input”)
另一种是处理非direct output thread:
new一段buffer出来。调用函数setMainBuffer将新buffer告诉给Track,即告诉Track,在AudioMixer中往新buffer中copy数据。
调用函数setInBuffer来实装chain的input buffer。(发现函数AudioFlinger::PlaybackThread::createTrack_l中其实有将chain的input buffer赋值给Track的main buffer)。然后将PlaybackThread的mMixBuffer赋值给chain的output buffer。
也就是说,Track将数据copy到自己的main buffer(即effect chain的input buffer),effect chain对数据进行处理,然后将处理过的数据赋值给自己的output buffer(即PlaybackThread的mMixBuffer)
mMixBuffer是如何被使用的呢?
从上可以看出是数据的copy的一种方式.
⑧.class DuplicatingThread : public MixerThread
AudioFlinger中有一个特殊的线程类:DuplicatingThread,从图可以知道,它是MixerThread的子类。当系统中有两个设备要同时输出时,DuplicatingThread将被创建,通过IAudioFlinger的openDuplicateOutput方法创建DuplicatingThread。
⑨.class TrackHandle : public android::BnAudioTrack
对音频播放的操作.
问题:这里的start stop和 flinger 里面的start stop 有何不同.
答:不同的内容.flinger类并没有这两个方法,在其子类中有.
从这里看出,另flinger并不只是对数据流进行操作,还提供了给上面应用的调用的接口.
⑩.class RecordThread : public ThreadBase, public AudioBufferProvider
他包含子类:class RecordTrack : public TrackBase
录音的流程和放音差不多,只不过数据流动的方向相反,录音线程变成RecordThread,Track变成了
RecordTrack,openRecord返回RecordHandle.
⑾.class RecordHandle : public android::BnAudioRecord
和TrackHandle相反的数据流操作.
⑿.class EffectModule: public RefBase
⒀.class EffectChain: public RefBase及子类class SuspendedEffectDesc : public RefBase
对音效的修正.
⒁.struct AudioStreamOut
⒂.struct AudioStreamIn
⒃.struct AudioSessionRef
/* AudioTrack对象的创建过程时,了解到,创建一个AudioTrack对象,必须指定一个SessionId,并与其他使用该SessionId的AudioTrack和MediaPlayer共享AudioEffect。
如果不指定SessionId,将会自动生成一个SessionId,AudioEffect会将该SessionId与新创建的AudioTrack对象关联起来。 别人可以通过getAudioSessionId函数取得该SessionId。
*/
还加入友元类
friend class RecordThread;
friend class PlaybackThread;