devbox
寸_铁
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

安卓Audio系统_android audio call

作者：寸_铁 | 2024-08-16 13:17:48

赞

踩

android audio call

一、安卓Audio框架

Audio系统主要组成部分：

  1. AudioRcorder和AuioTrack:这两个属于Audio对外提供的API接口，通过它完成音频数据的采集和输出任务
  2. AudioFlinger:它是Audio系统的工作引擎，管理着系统中的输出输入音频流，并承担音频数据的混音，以及读写硬件
  3. AudioPolicyService:它是Audio系统的策略控制中心，管理系统声音设备的选择和切换，音量控制等功能

二、关于AudioTrack.java

AudioTrack属于Audio系统对外提供的API类，如上图所示，它在java层和Native层都有对应的类。

安卓官网对其描述如下：

The AudioTrack class manages and plays a single audio resource for Java applications.

It allows streaming of PCM audio buffers to the audio sink for playback. This is achieved

by "pushing" the data to the AudioTrack object using one of the write(byte[], int, int), 

write(short[], int, int), and write(float[], int, int, int) methods.

AuioTrack的常见使用案例如下：

1、AudioTrack两种数据加载模式

AudioTrack提供两种数据加载模式：static 和 streaming

streaming模式：这种模式下，通过write()多次将音频数据写到AudioTrack中，一般用于以下场景：

  • 由于声音持续时长较长，或者音频数据特性（高采样率、每采样位数…）导致数据太大，无法一次写到内存中
  • 一边接收数据一边播放数据

static模式：这种模式下，在play()之前，一次性将音频数据写到AudioTrack中，一般用于以下场景：音频数据比较小占用内容少，UI、游戏、或铃声等

2、音频流的类型streamType

安卓系统对音频流的管理和分类，常见的streamType有：

  • STREAM_RING
  • STREAM_SYSTEM
  • STREAM_ALARM
  • STREAM_MUSIC
  • STREAM_VOCIE_CALL

类型的划分和Audio系统对音频的管理策略有关，与具体音频文件的内容没有关系

3、Buffer分配和Frame 概念

AudioTrack通过一个Buffer接收音频数据输入，所以AudioTrack的构建函数需要提供Buffer的大小。AudioTrack提供API getMinBufferSize计算最小需要的Buffer大小。可以看到getMinBufferSize传入参数：采样率、声道数、采样精度计算需要的Buffer大小。

getMinBufferSize主要调用流程：

  1. getMinBufferSize()
  2.     ==>native_get_min_buff_size(sampleRateInHz, channelCount, audioFormat);
  3.       JNI==>android_media_AudioTrack_get_min_buff_size()
  4.           ==>frameCount = AudioTrack::getMinFrameCount(&frameCount, AUDIO_STREAM_DEFAULT,
  5.               sampleRateInHertz);
  6.               ==>AudioSystem::getOutputSamplingRate(&afSampleRate, streamType);
  7.               ==>AudioSystem::getOutputFrameCount(&afFrameCount, streamType);
  8.               ==>AudioSystem::getOutputLatency(&afLatency, streamType); 
  9.               ==>frameCount = AudioSystem::calculateMinFrameCount(afLatency, afFrameCount, afSampleRate,sampleRate, 1.0f /*, 0 notificationsPerBufferReq*/);    
  10.           ==>return frameCount * channelCount * bytesPerSample;

从上面调用可以看到，要知道Buffer的大小，先要知道输入buffer需要支持缓存的frameCount，而frameCount的计算是通过AudioSystem获取输出设置的afFrameCount、afSampleRate、afLatency计算而来，实际公式为：

uint32_t minBufCount = afLatencyMs / ((1000 * afFrameCount) / afSampleRate)

这三个是什么东西呢？

  • afFrameCount--音频硬件BUFFER的大小
  • afFrameCount/afSampleRate--播放完音频硬件BUFFER中的数据需要多长时间，单位是秒。
  • afLatency--硬件延迟的最大时间

((1000 * afFrameCount) / afSampleRate)--转换为毫秒

afLatencyMs / ((1000 * afFrameCount) / afSampleRate)：在硬件延迟的最大时间，输出的framecount

什么是硬件延迟？

硬件播放硬件BUFFER里的数据，导致硬件可能有一段时间不能从客户端进程取得数据。具体表现是：audio hal层write函数阻塞不能返回，导致audioflinger的播放线程阻塞，不能消耗共享内存里的数据。客户端进程维护了一个BUFFER，它正在不停的往这个BUFFER里写数据，为了保证数据不被溢出（丢失），需要BUFFER足够大。

多大呢？

就是在硬件延迟的最大时间内不取数据的情况下，确保客户端进程往这个BUFFER写的数据不被溢出。可见客户端进程的BUFFER大小事音频硬件BUFFER的整数倍。

关于Frame(帧)：

一帧音频数据的大小相当于：采样点的字节数 X 声音数，如双通道，PCM16，1 Frame = 2X2 = 4字节

4、AudioTrack构造

AudioTrack构造函数主要调用：

  1.  AudioTrack(AudioAttributes attributes, AudioFormat format, int bufferSizeInBytes,
  2.              int mode, int sessionId, boolean offload)
  3.     ==> native_setup(new WeakReference<AudioTrack>(this), mAttributes,
  4.                   sampleRate, mChannelMask, mChannelIndexMask, mAudioFormat,
  5.                   mNativeBufferSizeInBytes, mDataLoadMode, session,         
  6.                   0/*nativeTrackInJavaObj*/, offload);
  7.         JNI==>android_media_AudioTrack_setup();
  8.             ==>lpTrack = new AudioTrack();
  9.             ==>New AudioTrackJniStorage();
  10.             ==> lpTrack->set(
  11.                       AUDIO_STREAM_DEFAULT,// stream type, but more info conveyed in paa (last argument)
  12.                       sampleRateInHertz,
  13.                       format,// word length, PCM
  14.                       nativeChannelMask,
  15.                       frameCount,
  16.                       AUDIO_OUTPUT_FLAG_NONE,
  17.                       audioCallback, &(lpJniStorage->mCallbackData),//callback, callback data (user)
  18.                       0,// notificationFrames == 0 since not using EVENT_MORE_DATA to feed the AudioTrack
  19.                       0,// shared mem
  20.                       true,// thread can call Java
  21.                       sessionId,// audio session ID
  22.                       AudioTrack::TRANSFER_SYNC,
  23.                       offload ? &offloadInfo : NULL,
  24.                       -1, -1,                       // default uid, pid values
  25.                       paa);

(1)关于AudioTrackJniStorage

AudioTrackJniStorage是一个辅助类，主要实现进程间的共享内存和Binder通信。

代码如下：

  1. class AudioTrackJniStorage {
  2.     public:
  3.         sp<MemoryHeapBase>         mMemHeap;
  4.         sp<MemoryBase>             mMemBase;
  5.         audiotrack_callback_cookie mCallbackData;
  6.         sp<JNIDeviceCallback>      mDeviceCallback;
  7.  
  8.     AudioTrackJniStorage() {
  9.         mCallbackData.audioTrack_class = 0;
  10.         mCallbackData.audioTrack_ref = 0;
  11.         mCallbackData.isOffload = false;
  12.     }
  13.  
  14.     ~AudioTrackJniStorage() {
  15.         mMemBase.clear();
  16.          mMemHeap.clear();
  17.      }
  18.  
  19.      bool allocSharedMem(int sizeInBytes) {
  20.          mMemHeap = new MemoryHeapBase(sizeInBytes, 0, "AudioTrack Heap Base");
  21.          if (mMemHeap->getHeapID() < 0) {
  22.              return false;
  23.          }
  24.          mMemBase = new MemoryBase(mMemHeap, 0, sizeInBytes);
  25.          return true;
  26.      }
  27.  };

AudioTrackJniStorage是主要成员函数allocSharedMem，作用就是分配共享内存。

什么是共享内存？

在linux用户空间，每个进程都有自己独立的内存空间，这个内存空间是进程的虚拟地址空间，不是真实的实际物理内存，进程之间的虚拟地址空间相互独立。有时候两个进程之前需要传输大量的数据，则需要让两个进程空间一段物理内存，linux平台提供了一套通过mmap共享内存的方式：

  • A和B分别打开同一个文件
  • A和B分别通过mmap调用指定参数，并传递给打开的fd
  • 内核中的设备描述符的驱动或内核模块完成物理内存分配，这样A\B实现内存共享

allocSharedMem中创建了MemoryHeapBase和MemoryBase。MemoryHeapBase和MemoryBase的家谱继承图如下：

可以看出，MemoryHeapBase和MemoryBase都是Binder通信的Bn端。

MemoryHeapBase的构造函数如下：

  1. MemoryHeapBase::MemoryHeapBase(size_t size, uint32_t flags, char const * name)
  2.     : mFD(-1), mSize(0), mBase(MAP_FAILED), mFlags(flags),
  3.       mDevice(0), mNeedUnmap(false), mOffset(0)
  4. {
  5.     const size_t pagesize = getpagesize();//内核内存管理以页为单位
  6.     size = ((size + pagesize-1) & ~(pagesize-1));//补全到一页
  7.     int fd = ashmem_create_region(name == NULL ? "MemoryHeapBase" : name, size);
  8.     ALOGE_IF(fd<0, "error creating ashmem region: %s", strerror(errno));
  9.     if (fd >= 0) {
  10.         if (mapfd(fd, size) == NO_ERROR) {
  11.             if (flags & READ_ONLY) {
  12.                 ashmem_set_prot_region(fd, PROT_READ);
  13.             }
  14.         }
  15.     }
  16. }
  17.  
  18. status_t MemoryHeapBase::mapfd(int fd, size_t size, uint32_t offset)
  19. {
  20.     if (size == 0) {
  21.         // try to figure out the size automatically
  22.         struct stat sb;
  23.         if (fstat(fd, &sb) == 0)
  24.             size = sb.st_size;
  25.         // if it didn't work, let mmap() fail.
  26.     }
  27.  
  28.     if ((mFlags & DONT_MAP_LOCALLY) == 0) {
  29.         void* base = (uint8_t*)mmap(0, size,
  30.                 PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset);
  31.         if (base == MAP_FAILED) {
  32.             ALOGE("mmap(fd=%d, size=%u) failed (%s)",
  33.                     fd, uint32_t(size), strerror(errno));
  34.             close(fd);
  35.             return -errno;
  36.         }
  37.         //ALOGD("mmap(fd=%d, base=%p, size=%lu)", fd, base, size);
  38.         mBase = base;
  39.         mNeedUnmap = true;
  40.     } else  {
  41.         mBase = 0; // not MAP_FAILED
  42.         mNeedUnmap = false;
  43.     }
  44.     mFD = fd;
  45.     mSize = size;
  46.     mOffset = offset;
  47.     return NO_ERROR;
  48. }

通过上面代码，可以看出MemoryHeapBase通过ashmem_create_region创建一个文 件描述符。ashmem_create_region函数由libcutils提供，在真实设备上将打开/dev/ashmem设备，并创建一个文件描述符，对文件描述符进行mmap，由内核完成共享内存。MemoryHeapBase构造完成后：

  • mBase变量指向共享内存的起始位置
  • mSize是所要求分配的内存大小
  • mFd是文件描述符

MemoryBase类代码很简单，只封装了Binder通信和一些get接口。

5、play、write、release分析

（1）play（）

主要调用：

  1. play()
  2.     ==>startImpl()
  3.         ==>native_start()
  4.             JNI==> android_media_AudioTrack_start()
  5.                 ==> lpTrack = getAudioTrack(env, thiz)
  6.                 ==> lpTrack->start();

通过JNI调用了C++ AudioTrack.cpp类的start()函数。

（2）write()

主要调用：

  1. write()
  2.     ==>android_media_AudioTrack_writeArray()
  3.         ==writeToTrack()
  4.             ==>AudioTrack::write() 或 memcpy(track->sharedBuffer()->pointer(), data + offsetInSamples, sizeInBytes);
  5.

通过JNI调用了C++ AudioTrack.cpp类的write()函数或通过memcpy 复制做C++ AudioTrack的Buffer

(3)release()

主要调用：

  1. release()
  2.     ==>android_media_AudioTrack_release()
  3.         ==>setAudioTrack(env, thiz, 0);
  4.         ==>env->SetLongField(thiz, javaAudioTrackFields.jniData, 0);
  5.         ==>*lpCookie = &pJniStorage->mCallbackData;
  6.         ==>sAudioTrackCallBackCookies.remove(lpCookie);
  7.         ==>env->DeleteGlobalRef(lpCookie->audioTrack_class);
  8.         ==>env->DeleteGlobalRef(lpCookie->audioTrack_ref);
  9.         ==>delete pJniStorage;

6、AudioTrack java空间总结

  • new 一个C空间AudioTrack,使用无参的构造函数
  • 调用set函数，把JAVA层的参数传进去，还设置了一个audiocallback回调函数
  • 调用C空间AudioTack的start函数
  • 调用C空间AudioTack的write函数
  • 工作完毕后，调用stop
  • 最后结束时，delete Native对象

三、关于AudioTrack.cpp

Java空间的AudioTrack构造时，会调用Native空间的AudioTrack的set()函数，设置参数。

调用流程如下：

  1. AudioTrack::set()
  2.     ==>createTrack()
  3.         ==>sp<IAudioTrack> track = AudioFlinger::createTrack()
  4.         ==>sp<IMemory> cblk = track->getCblk()
  5.         ==>mAudioTrack = track
  6.         ==>mCblkMemory = cblk

1、IAudioTrack

通过调用AudioFlinger::createTrack()在AF中创建track，生成一个共享内存，返回 IAudioTrack类（实际为BpAudioTrack）。IAudioTrack负责AT和AF的通信，三者关系如下：

2、共享内存及其ControlBlock

createTrack()会创建一个共享内存，可以通过IAudioTrack->getCblk()获取，共享内存的头部是一个audio_track_cblk_t对象，该对象之后才是数据缓冲。

为什么要此共享内存？

在stream模式下，AudioTrack并不创建共享内存，没有MemoryHeapBase和MemoryBase，但是AudioTrack和AudioFlinger作为音频的生产者和消费者，需要有一个共享内存传数音频数据，所以安卓创造了这个ControlBlock（CB）对象。

CB实际采用环形缓冲来处理数据的读写，如下图：

audio_track_cblk_t对象有一个标识：flowControlFlag：

  • 音频输出时，flowControlFlag对应着underrun状态，underrun状态是指生产者提供数据的速度跟不上消费使用数据的速度。这里的消费者指的是声音输出设备，由于音频输出采用环形缓存方式管理，当生产者没有及时提供新数据时，输出设备就会循环使用缓冲中的数据，这样就会听到一段重复的声音。这种现象一般被称作machinegun，一般处理方式是暂停输出。
  • 对于音频输入来说，flowControlFlag对应着overrun状态，生产都变音频输入设备，消费者变成AudioRecord.

3、audioCallBack与数据软入pull与push

AudioTrack构造时，如果传入AudioCallback，则AudioTrack会生成一个AudioTrackThread线程，这个线程与数据的输入方式有关，AudioTrack数据可以通过两种方式输入：

（1）Push方式:用户主动调用write写数据，这相当于数据被push到AudioTrack

（2）Pull方式：AudioTrackThread利用AudioCallback函数，通过回调，传参EVENT_MORE_DATA，主动从用户那pull数据。

回调的事件类型有以下几种：

AudioTrackThread::threadLoop调用mReceiver.processAudioBuffer处理AudioBuffer，然后调用回调函数：

(1)处理underun

(2)循环播放通知：

（3）达到标记警戒线：

（4）pull数据处理：

4、如何写数据，关于write()

现在Audio系统中，有一个共享内存还有一个控制结构，里面有一些支持跨进程的同步变量，所以可以猜到write工作方式就是：

  • 通过共享内存传递数据
  • 通过控制结构协调生产者和消费者的步调
  1. ssize_t AudioTrack::write(const void* buffer, size_t userSize, bool blocking)
  2. {
  3.     if (mTransfer != TRANSFER_SYNC) {
  4.         return INVALID_OPERATION;
  5.     }
  6.  
  7.     if (isDirect()) {
  8.         AutoMutex lock(mLock);
  9.         int32_t flags = android_atomic_and(
  10.                             ~(CBLK_UNDERRUN | CBLK_LOOP_CYCLE | CBLK_LOOP_FINAL | CBLK_BUFFER_END),
  11.                             &mCblk->mFlags);
  12.         if (flags & CBLK_INVALID) {
  13.             return DEAD_OBJECT;
  14.         }
  15.     }
  16.  
  17.     if (ssize_t(userSize) < 0 || (buffer == NULL && userSize != 0)) {
  18.         // Sanity-check: user is most-likely passing an error code, and it would
  19.         // make the return value ambiguous (actualSize vs error).
  20.         ALOGE("AudioTrack::write(buffer=%p, size=%zu (%zd)", buffer, userSize, userSize);
  21.         return BAD_VALUE;
  22.     }
  23.  
  24.     size_t written = 0;
  25.     Buffer audioBuffer;
  26.  
  27.     while (userSize >= mFrameSize) {
  28.         audioBuffer.frameCount = userSize / mFrameSize;
  29.  
  30.         status_t err = obtainBuffer(&audioBuffer,
  31.                 blocking ? &ClientProxy::kForever : &ClientProxy::kNonBlocking);
  32.         if (err < 0) {
  33.             if (written > 0) {
  34.                 break;
  35.             }
  36.             if (err == TIMED_OUT || err == -EINTR) {
  37.                 err = WOULD_BLOCK;
  38.             }
  39.             return ssize_t(err);
  40.         }
  41.  
  42.         size_t toWrite = audioBuffer.size;
  43.         memcpy(audioBuffer.i8, buffer, toWrite);
  44.         buffer = ((const char *) buffer) + toWrite;
  45.         userSize -= toWrite;
  46.         written += toWrite;
  47.  
  48.         releaseBuffer(&audioBuffer);
  49.     }
  50.  
  51.     if (written > 0) {
  52.         mFramesWritten += written / mFrameSize;
  53.     }
  54.     return written;
  55. }

通过上面代码，可以看到数据通过memcpy传据，而消费者和生产者的协调通过obtainBuffer和releaseBuffer实现。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/寸_铁/article/detail/988442
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号