AudioPolicyService是策略的制定者,AudioFlinger是策略的执行者, 所以: AudioPolicyService根据配置文件使唤AudioFlinger来创建Thread Thread : AudioFlinger.cpp (frameworks/av/services/audioflinger/AudioFlinger.cpp) Threads.cpp (frameworks/av /services/audioflinger/Threads.cpp) Tracks.cpp (frameworks/av/services/audioflinger/Tracks.cpp) audio_hw_hal.cpp 来加载) 打开对应的output(通过AudioFlinger来open output) ? 5 AudioFlinger启动过程分析 注册AudioFlinger服务 被AudioPolicyService调用以打开厂家提供的so文件 加载哪个so文件? 文件名是什么?
内部某个结构关联起来,这样AudioFlinger才可以处理系统中所有的音频。 ::mLock held AudioFlinger::PlaybackThread *AudioFlinger::checkPlaybackThread_l(audio_io_handle_t output 再看下创建共享内存 registerPid(clientPid): sp<AudioFlinger::Client> AudioFlinger::registerPid(pid_t pid) { ::Client::Client(const sp<AudioFlinger>& audioFlinger, pid_t pid) : RefBase(), mAudioFlinger (); } status_t AudioFlinger::TrackHandle::start() { return mTrack->start(); } void AudioFlinger
HAL 从设计上来看,硬件抽象层是AudioFlinger直接访问的对象。 这说明了两个问题,一方面AudioFlinger并不直接调用底层的驱动程序;另一方面,AudioFlinger上层模块只需要与它进行交互就可以实现音频相关的功能了。 因而我们可以认为AudioFlinger是Android音频系统中真正的“隔离板”,无论下面如何变化,上层的实现都可以保持兼容。 3、AudioFlinger继承libmeida中的接口,提供实现库libaudiofilnger.so。 4、Audio的硬件抽象层提供到硬件的接口,供AudioFlinger调用。Audio的硬件抽象层实际上是各个平台开发过程中需要主要关注和独立完成的部分。
() ->AudioFlinger::PlaybackThread.createTrack_l() ->new AudioFlinger::PlaybackThread::Track::Track -> new AudioFlinger::ThreadBase::TrackBase::TrackBase ->AudioFlinger::Client.heap() ->new MemoryHeapBase AudioFlinger::Client.heap()以及new Allocation,接下来一一分析:2.1.1 AudioFlinger::Client构造函数AudioFlinger为每个客户端进程创建一个 AudioFlinger::Client,以进程pid作为key,创建AudioTrack需要关联到具体的AudioFlinger::Client,代码如下:sp<IAudioTrack> AudioFlinger 2.1.2 AudioFlinger::ThreadBase::TrackBase::TrackBase构造函数AudioFlinger::ThreadBase::TrackBase构造函数代码如下:AudioFlinger
请求过来的,接下来就看下AudioFliner的实现: size_t AudioFlinger::getInputBufferSize(uint32_t sampleRate, audio_format_t return status; } 可以看到这里面果然主要做了上面猜想的2件事,接下来主要看下调用AudioFlinger创建Record,在看之前可以继续猜想下在AudioFlinger中需要做哪些事情 ::mLock held sp<AudioFlinger::RecordThread::RecordTrack> AudioFlinger::RecordThread::createRecordTrack_l ::Client::Client(const sp<AudioFlinger>& audioFlinger, pid_t pid) : RefBase(), mAudioFlinger (audioFlinger), mPid(pid) { mMemoryDealer = new MemoryDealer( audioFlinger->getClientSharedHeapSize
/blog.csdn.net/jinzhuojun/article/details/53456196 ■ 资料 Audio ■ Android 音频系统:从 AudioTrack 到 AudioFlinger AndroidO audio系统之AudioPolicyService分析(三) 其中openOutput and openInput 参考 Android 音频系统:从 AudioTrack 到 AudioFlinger AudioFlinger 服务接口” openOutput打开输出流设备 配置文件: https://blog.csdn.net/ly601579033/article/details/103172056
在AudioFlinger的setStreamVolume中调用了PlaybackThread的setStreamVolume. 每个AudioTrack在创建时会注册到AudioFlinger中,AudioFlinger在AudioPolicy的辅助下,为每个AudioTrack对象建立与某个具体的工作线程的对应关系,并通知这个工作线程创建了一个 由AudioFlinger把所有的AudioTrack进行混合(Mixer),然后输送到AudioHardware中进行播放。最多可以创建32个音频流。 AudioTrack通过setVolume设置音量后,会记录入共享内存中,然后由AudioFlinger去读取。 所涉及到的音频系统子模块包括AudioService、AudioPolicy和AudioFlinger,每个子模块都用各自的数据结构缓存了stream音量,持久化在设置数据库的system表中或者XML
/frameworks/av/services/audioflinger/AudioWatchdog.cpp #define LOG_TAG "AudioWatchdog" //#define LOG_NDEBUG /frameworks/av/services/audioflinger/AudioFlinger.h /frameworks/av/services/audioflinger/AudioFlinger.cpp 在AudioFlinger.h中MixerThread中有个AudioWatchdog的sp对象 class MixerThread : public PlaybackThread { public : MixerThread (const sp<AudioFlinger>& audioFlinger, AudioStreamOut* output /AudioFlinger.cpp AudioFlinger::MixerThread::MixerThread(const sp<AudioFlinger>& audioFlinger, AudioStreamOut
首先从播放线程的拉起开始,这儿以PlaybackThread为例, 由于PlaybackThread是以智能指针形式存在的,因此在创建后,会调用onFirstRef,因此这整个流程从这个函数开始: void AudioFlinger run(mThreadName, ANDROID_PRIORITY_URGENT_AUDIO); } 最后会执行run,这个方法会进行调用threadLoop,这个方法比较长,我们分段看下重点部分: AudioFlinger ::mScreenState changes uint32_t screenState = AudioFlinger::mScreenState; if (screenState 中的pause实现: void AudioFlinger::PlaybackThread::Track::pause() { ALOGV("%s(%d): calling pid %d", __ 因为在AudioFlinger中创建Track的时候就分配了一块共享内存,并把内存fd 通过binder共享给了调用方,这样调用方就可以直接在这块内存上获取可用内存了,具体实现如下: status_t
源码介绍 线程运行流程 先看下RecordThread的创建: AudioFlinger::RecordThread::RecordThread(const sp<AudioFlinger>& audioFlinger 还记得采集线程是被智能指针管理的,首次引用时会自动调用onFirstRef void AudioFlinger::RecordThread::onFirstRef() { run(mThreadName 接下来继续看下Record的start: status_t AudioFlinger::RecordThread::RecordTrack::start(AudioSystem::sync_event_t 的Record的时候创建的,可以再回顾下相关的位置: record = audioFlinger->createRecord(input, output, &status); // 创建 = FAILED_TRANSACTION || --remainingAttempts <= 0) { ALOGE("%s(%d): AudioFlinger could not
其中一大原因在于ALSA和AudioFlinger的通信方式。具体来说AudioFlinger将音频缓冲区“推送”到 ALSA。“推送”会导致调度问题,从而无法保证音频质量。
可以用生产消费者角度看,underrun就是生产者的速度赶不上消费者的速度了,对 于音频,那么就是在音频播放的时候,应用提供数据的速度赶不上AudioFlinger读取的速度了。 而AAudioStream的open 方法就是创建AudioRecord对象,并且注册设置参数,这时候就会在AudioFlinger中也创建一个对应的AudioRecord对象,并分配对应的缓存。 ,再到AudioFlinger看下: status_t AudioFlinger::openMmapStream(MmapStreamInterface::stream_direction_t direction 接下来调用interface的createMmapBuffer来创建共享内存: status_t AudioFlinger::MmapThreadHandle::createMmapBuffer(int32 nullptr : &attr, &tempHandle); // When AudioFlinger is passed a valid port handle then it should
第 7 章 阐述了 Audio 系统中的三位重要成员 AudioTrack、AudioFlinger和AudioPolicyService 的工作原理 。 本章拓展思考部分分析了 AudioFlinger 中 DuplicatingThread 的工作原理,并且和 读者一道探讨了单元测试、 ALSA 、 Desktop check 等问题。 Android 系统架构 该书籍所分析的各个模块除未涉及 Kernel 外,其他三层均有所涉及,它们分别 是: Native层 包括 init、Audio系统(包括AudioTrack、AudioFlinger
,包括3D应用程序,OpenGL, OpenCL, Vulkan等 了解一种或多种开源多媒体框架,例如 Wayland/Weston, Gstreamer, DRM, SurfaceFlinger, AudioFlinger
For details, consult the audio resampler source code in AudioFlinger.
frameworks/av/media/audioserver/main_audioserver.cpp frameworks/av/media/audioserver/audioserver.rc 启动AudioFlinger
This will cause the native * services (SurfaceFlinger, AudioFlinger, etc..) to be started.
nativeZygoteInit 函数) nativeZygoteInit 调用后,接着,三个重要的 static 函数就要被执行了:init1 - 完成本地Service(SurfaceFlinger、AudioFlinger
而 MediaRecorder 是基于 AudioRecorder 的 API (最终还是会创建AudioRecord 用来与 AudioFlinger 进行交互) ,它可以直接将采集到的音频数据转化为执行的编码格式
IServiceManager> sm = defaultServiceManager();//step 2 ALOGI("ServiceManager: %p", sm.get()); AudioFlinger