AudioTrack与AudioFlinger的sharebuffer

       AudioTrack作为音频数据的生产者,AudioFlinger是消费者,会有一块共享内存用于传输pcm数据,这块共享内存在AudioTrack创建时候就开辟好,主要就是在AudioTrack的set方法,该方法中调用了createTrack_l创建IAudioTrack,createTrack_l的作用主要就是创建出一块share buffer,供AudioTrack写入和AudioFlinger读取。同时还会根据是否在参数中传入callback函数来决定是否创建AudioTrackThread,用以以callback的形式来要数据,但无论是这种callback形式还是直接write的形式都需要通过createTrack_l创建的share buffer。

createTrack_l的主要工作有调用AudioFlinger的createTrack,创建sharebuffer和Audioflinger对sharebuffer进行控制的对象AudioTrackServerProxy,客户端AudioTrack则有相对应的控制对象AudioTrackClientProxy。

步骤为:

1.获取输出线程PlaybackThread,先通过AudioSystem::getOutputForAttr获取输出的信息,再通过checkPlaybackThread_l获取到PlaybackThread,PlaybackThread是在系统启动初期audioflinger和audiopolicy服务起来的时候就一同被创建。

lStatus = AudioSystem::getOutputForAttr(&input.attr, &output.outputId, sessionId, &streamType,
                                            clientPid, clientUid, &input.config, input.flags,
                                            &output.selectedDeviceId, &portId);



PlaybackThread *thread = checkPlaybackThread_l(output.outputId);
        if (thread == NULL) {
            ALOGE("no playback thread found for output handle %d", output.outputId);
            lStatus = BAD_VALUE;
            goto Exit;
        }

2.调用获取到的PlaybackThread的createTrack_l函数来创建Track对象,在Track对象内部会创建sharebuffer

track = thread->createTrack_l(client, streamType, input.attr, &output.sampleRate,
                                      input.config.format, input.config.channel_mask,
                                      &output.frameCount, &output.notificationFrameCount,
                                      input.notificationsPerBuffer, input.speed,
                                      input.sharedBuffer, sessionId, &output.flags,
                                      input.clientInfo.clientTid, clientUid, &lStatus, portId);

3.最后创建TrackHandle,返回给AudioTrack,TrackHandlebao包含了上一步创建的track的信息

PlaybackThread的createTrack_l函数中调用了new Track来创建share buffer

track = new Track(this, client, streamType, attr, sampleRate, format,
                          channelMask, frameCount,
                          nullptr /* buffer */, (size_t)0 /* bufferSize */, sharedBuffer,
                          sessionId, uid, *flags, TrackBase::TYPE_DEFAULT, portId);

Track的父类TrackBase对象,sharebuffer即在这里创建,其中audio_track_cblk_t是这个buffer的头,头记录了很多例如AUdioTrack和AudioFlinger读写指针位置的关键信息,在读写过程中不断使用到。

AudioFlinger::ThreadBase::TrackBase::TrackBase(...)
{
...
if (mCblk != NULL) {
        new(mCblk) audio_track_cblk_t();
        switch (alloc) {
        case ALLOC_READONLY: {
            const sp<MemoryDealer> roHeap(thread->readOnlyHeap());
            if (roHeap == 0 ||
                    (mBufferMemory = roHeap->allocate(bufferSize)) == 0 ||
                    (mBuffer = mBufferMemory->pointer()) == NULL) {
                ALOGE("not enough memory for read-only buffer size=%zu", bufferSize);
                if (roHeap != 0) {
                    roHeap->dump("buffer");
                }
                mCblkMemory.clear();
                mBufferMemory.clear();
                return;
            }
            memset(mBuffer, 0, bufferSize);
            } break;
        case ALLOC_PIPE:
            mBufferMemory = thread->pipeMemory();
            // mBuffer is the virtual address as seen from current process (mediaserver),
            // and should normally be coming from mBufferMemory->pointer().
            // However in this case the TrackBase does not reference the buffer directly.
            // It should references the buffer via the pipe.
            // Therefore, to detect incorrect usage of the buffer, we set mBuffer to NULL.
            mBuffer = NULL;
            bufferSize = 0;
            break;
        case ALLOC_CBLK:
            // clear all buffers
            if (buffer == NULL) {
                mBuffer = (char*)mCblk + sizeof(audio_track_cblk_t);
                memset(mBuffer, 0, bufferSize);
            } else {
                mBuffer = buffer;
#if 0
                mCblk->mFlags = CBLK_FORCEREADY;    // FIXME hack, need to fix the track ready logic
#endif
            }
            break;
        case ALLOC_LOCAL:
            mBuffer = calloc(1, bufferSize);
            break;
        case ALLOC_NONE:
            mBuffer = buffer;
            break;
        default:
            LOG_ALWAYS_FATAL("invalid allocation type: %d", (int)alloc);
        }
        mBufferSize = bufferSize;
.....
}

new Track在构造函数体内,会创建AudioTrackServerProxy,用作AudioFlinger这边的buffer操作,回头再看AudioTrack的createTrack_l函数中也创建了AudioTrackClientProxy对象用于AudioTrack的buffer操作。

共享内存开辟出来之后,AudioTrack就可以将数据写入这块内存,而这个过程就是AudioTrackClientProxy对象获取sharebuffer可用空间,再将数据copy到这块内存上,AudioTrack的obtainBuffer函数调用AudioTrackClientProxy的父类对象ClientProxy的obtainBuffer方法

 

 

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 从Audiotrack到Audioflinger是Android音频系统中的两个重要组件。 Audiotrack是一个用于播放音频的类,它可以创建一个音频缓冲区并将其发送到音频输出设备进行播放。它是一个应用程序级别的组件,通常用于播放音乐、语音和其他音频文件。 而Audioflinger是Android音频系统中的一个系统级别的组件,它是一个音频引擎,负责管理所有音频输入和输出。它接收来自应用程序的音频数据,并将其传递给音频硬件进行处理和播放。它还负责处理音频路由、音量控制和音频效果等功能。 因此,从Audiotrack到Audioflinger可以看作是从应用程序级别到系统级别的转变,是Android音频系统中的两个不同层次的组件。 ### 回答2: Audiotrack和Audioflinger都是在Android系统中用于音频播放的重要组件。Audiotrack用于创建和播放音频流,而Audioflinger用于管理多个应用程序之间的音频流和混合。 Audiotrack是一个Android中的音频类,可以用于播放音频流。它可以在Android系统中创建一个音频流,并且可以改变音频流的属性。Audiotrack的主要作用是把音频数据从应用程序的内存传输到Android系统的音频支持部分。 而Audioflinger是位于Android的音频架构中的一个子系统,负责管理系统中所有音频的播放和捕获。它的主要作用是把来自不同应用程序的音频流与硬件设备联系起来,并且确保能够同时正确播放不同的音频流,避免互相干扰。在音频流的处理上,Audioflinger足够强大,它可以动态地混合多个音频流,并且可以控制音量,频率和均衡器。 从Audiotrack到Audioflinger的发展,反映出移动设备音频处理技术的不断发展和进步。在早期的Android系统中,为了实现音频播放,开发者们需要使用OpenSL ES这样的第三方库进行音频处理。随着Android系统版本不断升级,Audiotrack和Audioflinger成为系统中的基本音频功能,大幅提升了音频处理的效率和质量。Audiotrack和Audioflinger的不断完善与升级,也为一些音视频应用开发提供了强有力的支持,这样应用程序可以在播放,录制和处理音频时得到更好的用户体验。总之,随着技术的不断进步,那些基础的音频组件不断完善回馈给大家的是更好的用户体验。 ### 回答3: Audiotrack是Android系统中一个用于音频输出的类,它提供了许多方法,如setLoopPoints、setPlaybackParams、setStereoVolume等,使开发者可以在自己的应用程序中控制音频播放的各个方面。使用Audiotrack,程序员可以将音频数据写入到该类的缓冲区中,然后Audiotrack会将缓冲区中的数据转换为声音,并输出到音频设备中播放。 但由于Audiotrack只是用于输出音频数据,并不能处理来自不同应用的音频数据,这就需要一个用于管理和处理应用程序之间的音频数据交换的系统服务。因此,Android系统中还有一个系统服务叫做AudioFlingerAudioFlinger位于系统服务层,是Android系统中的一个核心组件。它的主要责任是管理音频任务,处理音频数据和控制音频设备等,是整个Android系统中最底层的音频管理和处理服务。它可以与多个音频驱动程序(如ALSA,OpenSL ES等)进行通信,支持多流、多线程音频数据流的处理,可以同时处理不同应用程之间产生的音频数据。 当应用程序使用Audiotrack播放音频时,AudioFlinger会接收来自Audiotrack的音频数据并将其传递给音频驱动程序,然后由音频驱动程序将数据送往声卡,最终将音频数据转化为声音输出。 总之,Audiotrack和AudioFlinger都是Android系统中至关重要的音频处理组件。Audiotrack是用于控制音频输出的应用级组件;AudioFlinger是系统级组件,用于管理和处理多个应用程序之间的音频数据交换,从而完成音频设备的控制和音频数据的处理。两者紧密协作,为用户提供一个高效更好的音频服务。

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值