Audio(2)-audio数据控制块audio_track_cblk_t

  • 背景介绍

AudioTrack与AudioFlinger之间的数据传输分为两种方式,MODE_STATIC与MODE_STREAM。

  1. MODE_STATIC:static方式适用于数据较小,实时性比较高的情形,比如ring,系统铃声等。这种模式下,是在AT端创建共享内存,一次性将数据copy到buffer中,然后传递到AF端。
  2. MODE_STREAM:stream方式适用于数据较大,media播放等更多其他的情况,也比较复杂。在这种模式下,共享内存是由AF创建的,然后通过生产者-消费者的模式,进行数据的传输。即AT是数据的生产者,AF是数据的消费者。这个数据读写的控制,是由struct audio_track_cblk_t来实现的,这篇文章主要来分析这个控制块的实现。

 

  • audio_track_cblk_t的创建
  1. AT与AF之间,是通过IAudioTrack接口进行交互的,而这个audio_track_cblk_t的创建,就是在AT调用AF创建IAudioTrack接口的同时创建的。
  2. AT->AF.createTrack()//在AT.play之前,必须要与AF建立联系
  3. PlaybackThread.createTrack_l() //创建AT与AF之间实际功能调用的实现者
  4. new Track() //创建Track,并把它包装在实现了IAudioTrack接口的TrackHandle中
  5. TrackBase::TrackBase()//Track的父类,创建audio_track_cblk_t的工作是在TrackBase的构造函数中进行的
    size_t size = sizeof(audio_track_cblk_t); //计算audio_track_cblk_t的大小
    uint8_t channelCount = popcount(channelMask);
    size_t bufferSize = frameCount*channelCount*sizeof(int16_t); //计算实际数据buffer大小
    if (sharedBuffer == 0) {
        size += bufferSize; //共享内存实际分配大小为:cblk + data buffer
    }

    if (client != NULL) {
        mCblkMemory = client->heap()->allocate(size); //分配共享内存,实际的实现会在其他文章中分析,这里之分析对共享内存的使用
        if (mCblkMemory != 0) {
            mCblk = static_cast<audio_track_cblk_t *>(mCblkMemory->pointer()); // audio_track_cblk_t* mCblk,指向共享内存的地址
            if (mCblk != NULL) { // construct the shared structure in-place.
                new(mCblk) audio_track_cblk_t(); //这里是C++的语法:
                             //(1)struct可以像class一样,使用new来创建。
                   //(2)new创建的对象并没有在heap上,而是特定在mCblk指向的内存上创建,这样这块共享
                             // 内存的结构就变成了: |<- audio_track_cblk_t ->| ...data buffer... |
// clear all buffers mCblk->frameCount = frameCount; //初始化cblk中的一些属性 mCblk->sampleRate = sampleRate; mChannelCount = channelCount; mChannelMask = channelMask; if (sharedBuffer == 0) { //sharedBuffer==0表示MODE_STREAM mBuffer = (char*)mCblk + sizeof(audio_track_cblk_t); //data buffer的地址,需要将audio_track_cblk_t的大小跳过 memset(mBuffer, 0, frameCount*channelCount*sizeof(int16_t)); //clear buffer // Force underrun condition to avoid false underrun callback until first data is // written to buffer (other flags are cleared) mCblk->flags = CBLK_UNDERRUN_ON; } else { //否则就是MODE_STATIC,数据buffer直接使用由AT传递过来的已经申请好的共享内存 mBuffer = sharedBuffer->pointer(); } mBufferEnd = (uint8_t *)mBuffer + bufferSize; } } else { ALOGE("not enough memory for AudioTrack size=%u", size); client->heap()->dump("AudioTrack"); return; } } else { ……………… }

 

  •  audio_track_cblk_t的声明
struct audio_track_cblk_t
{
                ...省略...
                // next 4 are offsets within "buffers"
    volatile    uint32_t    user; //user代表AT,生产者已经写了多少个frame
    volatile    uint32_t    server; //server代表AF,消费者已经读取了多少个frame
                uint32_t    userBase; //与user结合使用,使之成为一个环形FIFO
                uint32_t    serverBase; //同userBase

                // if there is a shared buffer, "buffers" is the value of pointer() for the shared
                // buffer, otherwise "buffers" points immediately after the control block
                void*       buffers; //实际数据buffer的起始地址
                      //如果是MODE_STREAM,buffers紧跟在cblk后面
                      //如果是MODE_STATIC,buffers指向sharedBuffer
uint32_t frameCount; //数据buffer的大小,以Frame为单位
          //以下3个loopXXX是与循环播放有关 uint32_t loopStart; uint32_t loopEnd; // read-only for server, read/write for client int loopCount; // read/write for client private: uint32_t mVolumeLR; //音量相关 public: uint32_t sampleRate; //采样率 // NOTE: audio_track_cblk_t::frameSize is not equal to AudioTrack::frameSize() for // 8 bit PCM data: in this case, mCblk->frameSize is based on a sample size of // 16 bit because data is converted to 16 bit before being stored in buffer uint8_t frameSize; //一单位frame的大小 ...省略... public: volatile int32_t flags;// Since the control block is always located in shared memory, this constructor // is only used for placement new(). It is never used for regular new() or stack. audio_track_cblk_t(); //cblk总是new在指定的共享内存上,而不是堆栈上 uint32_t stepUser(uint32_t frameCount); //AT更新写位置 bool stepServer(uint32_t frameCount); //AF更新读位置 void* buffer(uint32_t offset) const; //返回可写的地址 uint32_t framesAvailable(); //还有多少空间可写 uint32_t framesAvailable_l(); uint32_t framesReady(); //是否有可读数据 bool tryLock();          ...省略... };
  •  AT写数据流程
  1. framesAvailable()判断是否有可用空间 
    uint32_t audio_track_cblk_t::framesAvailable_l()
    {
        uint32_t u = user;
        uint32_t s = server;
    
        if (flags & CBLK_DIRECTION_MSK) { //以前的out标志,放在了flag中?表示AT?
    //计算读的起始位置,取读位置与循环起始位置两者中较小的 uint32_t limit
    = (s < loopStart) ? s : loopStart;
    //可读 = user - limit
    //可写 = frameCount - 可读
    //可写 = frameCount - (u - limit)
    //可写 = frameCount + limit - u
    return limit + frameCount - u; } else { ....... } }

     

  2. buffer()得到写空间起始地址
    void* audio_track_cblk_t::buffer(uint32_t offset) const
    {
       //这里传入的offset就是cblk->user,为了在有限长度的buffer内,模拟环形FIFO队列,就有了个userBase。
    //当数据写满整个buffer的大小以后,会继续增加user的值,那么user*frameSize的大小就会超过cblk->buffers+(frameCount*frameSize)
    //这时就需要userBase来进行调整,user每增加frameCount整个buffer的帧数,userBase会增加同样的大小,
    //来保证user-userBase始终小于frameCount,这样cblk->buffers + (user - userBase)*frameSize就可以得到当前的写位置,
    //这个写位置永远不会超过实际cblk->buffer + frameCount*frameSize。
    //环形FIFO的精髓就在这
    return (int8_t *)buffers + (offset - userBase) * frameSize; }

     

  3. stepUser()更新写位置
    /*获取了写位置,并写入数据后,需要更新user的位置*/
    uint32_t audio_track_cblk_t::stepUser(uint32_t frameCount) {
    uint32_t u = user; u += frameCount; //frameCount表示这次写了多少个frame, ...省略... uint32_t fc = this->frameCount; //整个buffer有多少个frame if (u >= fc) { //如果已写的frame超过整个buffer // common case, user didn't just wrap if (u - fc >= userBase ) { //userBase + frameCount小于user,就需要使userBase同样调整 userBase += fc; } } else if (u >= userBase + fc) { //同上 // user just wrapped userBase += fc; } user = u; //更新user ...省略... return u; }

     

  • AF读数据流程
  1. frameReady()看是否有数据可以读 
    uint32_t audio_track_cblk_t::framesReady()
    {
        uint32_t u = user;
        uint32_t s = server;
    
        if (flags & CBLK_DIRECTION_MSK) {
            if (u < loopEnd) { //如果还未写到循环结束
                return u - s;
            } else {
                // do not block on mutex shared with client on AudioFlinger side
                if (!tryLock()) {
                    ALOGW("framesReady() could not lock cblk");
                    return 0;
                }
                uint32_t frames = UINT_MAX;
                if (loopCount >= 0) {
                    frames = (loopEnd - loopStart)*loopCount + u - s;
                }
                lock.unlock();
                return frames;
            }
        } else {
            return s - u;
        }
    }

     

  2. stepServe()更新serve 
    bool audio_track_cblk_t::stepServer(uint32_t frameCount)
    {
        uint32_t s = server;
        bool flushed = (s == user);
    
        s += frameCount;
        if (flags & CBLK_DIRECTION_MSK) {
            // Mark that we have read the first buffer so that next time stepUser() is called
            // we switch to normal obtainBuffer() timeout period
            if (bufferTimeoutMs == MAX_STARTUP_TIMEOUT_MS) {
                bufferTimeoutMs = MAX_STARTUP_TIMEOUT_MS - 1;
            }
            // It is possible that we receive a flush()
            // while the mixer is processing a block: in this case,
            // stepServer() is called After the flush() has reset u & s and
            // we have s > u
            if (flushed) {
                ALOGW("stepServer occurred after track reset");
                s = user;
            }
        }
    
        if (s >= loopEnd) {
            ALOGW_IF(s > loopEnd, "stepServer: s %u > loopEnd %u", s, loopEnd);
            s = loopStart;
            if (--loopCount == 0) {
                loopEnd = UINT_MAX;
                loopStart = UINT_MAX;
            }
        }
        //与user类似,调整serveBase实现环形FIFO
        uint32_t fc = this->frameCount;
        if (s >= fc) {
            // common case, server didn't just wrap
            if (s - fc >= serverBase ) {
                serverBase += fc;
            }
        } else if (s >= serverBase + fc) {
            // server just wrapped
            serverBase += fc;
        }
    
        server = s;
    
        if (!(flags & CBLK_INVALID_MSK)) {
            cv.signal();
        }
        lock.unlock();
        return true;
    }

     

转载于:https://www.cnblogs.com/code-4-fun/p/3267878.html

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
深入理解Android 卷1 不是扫描版的,是全版电子书的,非PDF,可编辑,各种阅览器以打开!包括书签和同步目录! 第1章 阅读前的准备工作 / 1 1.1 系统架构 / 2 1.1.1 Android系统架构 / 2 1.1.2 本书的架构 / 3 1.2 搭建开发环境 / 4 1.2.1 下载源码 / 4 1.2.2 编译源码 / 6 1.3 工具介绍 / 8 1.3.1 Source Insight介绍 / 8 1.3.3 Busybox的使用 / 11 1.4 本章小结 / 12 第2章 深入理解JNI / 13 2.1 JNI概述 / 14 2.2 学习JNI的实例:MediaScanner / 15 2.3 Java层的MediaScanner分析 / 16 2.3.1 加载JNI库 / 16 2.3.2 Java的native函数和总结 / 17 2.4 JNI层MediaScanner的分析 / 17 2.4.1 注册JNI函数 / 18 2.4.2 数据类型转换 / 22 2.4.3 JNIEnv介绍 / 24 2.4.4 通过JNIEnv操作jobject / 25 2.4.5 jstring介绍 / 27 2.4.6 JNI类型签名介绍 / 28 2.4.7 垃圾回收 / 29 2.4.8 JNI中的异常处理 / 32 2.5 本章小结 / 32 第3章 深入理解init / 33 3.1 概述 / 34 3.2 init分析 / 34 3.2.1 解析配置文件 / 38 3.2.2 解析service / 42 3.2.3 init控制service / 48 3.2.4 属性服务 / 52 3.3 本章小结 / 60 第4章 深入理解zygote / 61 4.1 概述 / 62 4.2 zygote分析 / 62 4.2.1 AppRuntime分析 / 63 4.2.2 Welcome to Java World / 68 4.2.3 关于zygote的总结 / 74 4.3 SystemServer分析 / 74 4.3.1 SystemServer的诞生 / 74 4.3.2 SystemServer的重要使命 / 77 4.3.3 关于 SystemServer的总结 / 83 4.4 zygote的分裂 / 84 4.4.1 ActivityManagerService发送请求 / 84 4.4.2 有求必应之响应请求 / 86 4.4.3 关于zygote分裂的总结 / 88 4.5 拓展思考 / 88 4.5.1 虚拟机heapsize的限制 / 88 4.5.2 开机速度优化 / 89 4.5.3 Watchdog分析 / 90 4.6 本章小结 / 93 第5章 深入理解常见类 / 95 5.1 概述 / 96 5.2 以“三板斧”揭秘RefBase、sp和wp / 96 5.2.1 第一板斧——初识影子对象 / 96 5.2.2 第二板斧——由弱生强 / 103 5.2.3 第三板斧——破解生死魔咒 / 106 5.2.4 轻量级的引用计数控制类LightRefBase / 108 5.2.5 题外话-三板斧的来历 / 109 5.3 Thread类及常用同步类分析 / 109 5.3.1 一个变量引发的思考 / 109 5.3.2 常用同步类 / 114 5.4 Looper和Handler类分析 / 121 5.4.1 Looper类分析 / 122 5.4.2 Handler分析 / 124 5.4.3 Looper和Handler的同步关系 / 127 5.4.4 HandlerThread介绍 / 129 5.5 本章小结 / 129 第6章 深入理解Binder / 130 6.1 概述 / 131 6.2 庖丁解MediaServer / 132 6.2.1 MediaServer的入口函数 / 132 6.2.2 独一无二的ProcessState / 133 6.2.3 时空穿越魔术-defaultServiceManager / 134 6.2.4 注册MediaPlayerService / 142 6.2.5 秋风扫落叶-StartThread Pool和join Thread Pool分析 / 149 6.2.6 你彻底明白了吗 / 152 6.3 服务总管ServiceManager / 152 6.3.1 ServiceManager的原理 / 152 6.3.2 服务的注册 / 155 6.3.3 ServiceManager存在的意义 / 158 6.4 MediaPlayerService和它的Client / 158 6.4.1 查询ServiceManager / 158 6.4.2 子承父业 / 159 6.5 拓展思考 / 162 6.5.1 Binder和线程的关系 / 162 6.5.2 有人情味的讣告 / 163 6.5.3 匿名Service / 165 6.6 学以致用 / 166 6.6.1 纯Native的Service / 166 6.6.2 扶得起的“阿斗”(aidl) / 169 6.7 本章小结 / 172 第7章 深入理解Audio系统 / 173 7.1 概述 / 174 7.2 AudioTrack的破解 / 174 7.2.1 用例介绍 / 174 7.2.2 AudioTrack(Java空间)分析 / 179 7.2.3 AudioTrack(Native空间)分析 / 188 7.2.4 关于AudioTrack的总结 / 200 7.3 AudioFlinger的破解 / 200 7.3.1 AudioFlinger的诞生 / 200 7.3.2 通过流程分析AudioFlinger / 204 7.3.3 audio_track_cblk_t分析 / 230 7.3.4 关于AudioFlinger的总结 / 234 7.4 AudioPolicyService的破解 / 234 7.4.1 AudioPolicyService的创建 / 235 7.4.2 重回AudioTrack / 245 7.4.3 声音路由切换实例分析 / 251 7.4.4 关于AudioPolicy的总结 / 262 7.5 拓展思考 / 262 7.5.1 DuplicatingThread破解 / 262 7.5.2 题外话 / 270 7.6 本章小结 / 272 第8章 深入理解Surface系统 / 273 8.1 概述 / 275 8.2 一个Activity的显示 / 275 8.2.1 Activity的创建 / 275 8.2.2 Activity的UI绘制 / 294 8.2.3 关于Activity的总结 / 296 8.3 初识Surface / 297 8.3.1 和Surface有关的流程总结 / 297 8.3.2 Surface之乾坤大挪移 / 298 8.3.3 乾坤大挪移的JNI层分析 / 303 8.3.4 Surface和画图 / 307 8.3.5 初识Surface小结 / 309 8.4 深入分析Surface / 310 8.4.1 与Surface相关的基础知识介绍 / 310 8.4.2 SurfaceComposerClient分析 / 315 8.4.3 SurfaceControl分析 / 320 8.4.4 writeToParcel和Surface对象的创建 / 331 8.4.5 lockCanvas和unlockCanvasAndPost分析 / 335 8.4.6 GraphicBuffer介绍 / 344 8.4.7 深入分析Surface的总结 / 353 8.5 SurfaceFlinger分析 / 353 8.5.1 SurfaceFlinger的诞生 / 354 8.5.2 SF工作线程分析 / 359 8.5.3 Transaction分析 / 368 8.5.4 关于SurfaceFlinger的总结 / 376 8.6 拓展思考 / 377 8.6.1 Surface系统的CB对象分析 / 377 8.6.2 ViewRoot的你问我答 / 384 8.6.3 LayerBuffer分析 / 385 8.7 本章小结 / 394 第9章 深入理解Vold和Rild / 395 9.1 概述 / 396 9.2 Vold的原理与机制分析 / 396 9.2.1 Netlink和Uevent介绍 / 397 9.2.2 初识Vold / 399 9.2.3 NetlinkManager模块分析 / 400 9.2.4 VolumeManager模块分析 / 408 9.2.5 CommandListener模块分析 / 414 9.2.6 Vold实例分析 / 417 9.2.7 关于Vold的总结 / 428 9.3 Rild的原理与机制分析 / 428 9.3.1 初识Rild / 430 9.3.2 RIL_startEventLoop分析 / 432 9.3.3 RIL_Init分析 / 437 9.3.4 RIL_register分析 / 444 9.3.5 关于Rild main函数的总结 / 447 9.3.6 Rild实例分析 / 447 9.3.7 关于Rild的总结 / 459 9.4 拓展思考 / 459 9.4.1 嵌入式系统的存储知识介绍 / 459 9.4.2 Rild和Phone的改进探讨 / 462 9.5 本章小结 / 463 第10章 深入理解MediaScanner / 464 10.1 概述 / 465 10.2 android.process.media分析 / 465 10.2.1 MSR模块分析 / 466 10.2.2 MSS模块分析 / 467 10.2.3 android.process.media媒体扫描工作的流程总结 / 471 10.3 MediaScanner分析 / 472 10.3.1 Java层分析 / 472 10.3.2 JNI层分析 / 476 10.3.3 PVMediaScanner分析 / 479 10.3.4 关于MediaScanner的总结 / 485 10.4 拓展思考 / 486 10.4.1 MediaScannerConnection介绍 / 486 10.4.2 我问你答 / 487 10.5 本章小结 / 488

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值