㈠ 直播时有杂音滋滋滋是什么原因直播杂音怎么回事
我们重点看看直播过程中出现的杂音、噪音和回声等问题。
相比于视频而言，音频要敏感得多，视频画面有噪点、马赛克都还是可以勉强被接受，而声音一旦有任何瑕疵，人耳都会特别容易感觉到，而且难以忍受。
问题现象
常见的音频问题现象描述如下：
- 电流音，爆音，滋滋声或者嘟嘟声
- 声音断断续续，听不清楚
- 回声，能听到自己说话的声音
问题排查
1.参数配置问题
上面也有提到，音频是一个特别敏感的东西，涉及到许多参数配置，一旦配置不太匹配，就会导致声音听起来非常诡异（比如：采样率是 32000Hz 的音频，给播放器配置为 8000Hz 或者 44100Hz，就明显会出现音频慢放或者快放的效果）。
常见的音频参数和基本原理，可以参考文章：《android音频开发（1）：基础知识》
我们只需要注意的是，无论是采集和播放，都要给系统的 API 以及第三方的库配置正确的参数，如：采样率、位宽、声道数等等。
2.代码层面的原因
常见的代码层面的问题有如下几种：
- 音频 buffer 大小不匹配，一段 1024 bytes 的音频，放到了 2048 bytes 的数组，导致尾部有随机数
- 音频 resample 重采样的算法问题，导致采样出来的数据出了问题
- Android 的 ByteBuffer 取出数组，是不能直接用 .array() 方法的，而需要用 .get() 方法
- iOS 系统，其他 app 通过系统 API 更改了 AudioSession 采样率的配置
追答
3.网络波动
视频是一帧一帧连续的图像构成的，在播放过程中，如果无法按时渲染，则会出现卡顿的效果；如果丢失几帧画面，则会出现快进效果。
而音频是流式的，虽然也被切分为了一个个音频帧，但如果无法按时播放或者连续丢失较多的音频帧，则会明显听到断断续续的声音出现。特别是在弱网、丢包率高等不稳定网络环境下，很容易出现这种情况。
4.回声消除
回声一般出现在同时有音频的采集和播放的场景，比如：连麦互动、混音返听等等，采集到的音频通过扬声器又播放出来了，同时又被采集了进去，从而产生了回声或者啸叫声。
这样的场景下，一般需要通过系统的回声消除 API，或者第三方回声消除库（如：speexdsp，webrtc 等）进行处理。
注意：很多 Android 机型硬件自带的回声消除效果并不是很好。
5.混音越界
音频的 PCM 数据，通常用 short 数组来存放，当我们做一些多路音频的混音功能的时候，如果不注意处理 short 类型的大小越界，则往往带来爆音的问题。下面是一段参考 webrtc 的混音代码，专门针对混音越界做了简单处理，
㈡ android直接播放pcm语音为什么会有噪音
最近在做手机客户端用G726编码库向机台发送语音消息的DEMO，弄了一周左右才解决.
中间碰到的问题贼多，主要是用AudioRecord采集声音的时候，然后用AudioTrack播放经常会出现噪音，这样的情况让人实在是无法接受。
后来查谷歌实在是没折了，于是再次翻查了下sipdroid的代码，发现sipdroid在采集声音后，每次都会调用一个函数，于是我猜测，这个函数应该跟去除噪音有关，于是写了个DEMO，测试了一下，发现噪音还真消除了.
噪音消除算法:
void calc1(short[] lin,int off,int len) {
int i,j;
for (i = 0; i < len; i++) {
j = lin[i+off];
lin[i+off] = (short)(j>>2);
}
}
自己录制PCM，播放PCM的DEMO。
㈢ Android 多媒体音频开发中怎么将PCM转成ADPCM
Adensoft Audio MP3 Converter
Adensoft.Audio.MP3.Converter是一款强大的音频转换工具，能将当前主流的音频格式如WAV PCM, WAV ，GSM, ADPCM, DSP ,MP2,WMA ( win Media Audio ),Ogg Vorbis,VOX ( Dialogic ADPCM ),RAW ( PCM, A-LAW, U-LAW ),MPC (MusicPack),AVI (audio track),G.721,G.723,G.726,AIFF ，AU (UNIX audio format)无损的转换成mp3（支持批量转换）。软件同时提供良好的人机界面和完整的tag编辑功能。
㈣ android中mediamuxer和mediacodec的区别
Android中MediaMuxer和MediaCodec用例
在Android的多媒体类中，MediaMuxer和MediaCodec算是比较年轻的，它们是JB 4.1和JB 4.3才引入的。前者用于将音频和视频进行混合生成多媒体文件。缺点是目前只能支持一个audio track和一个video track，而且仅支持mp4输出。不过既然是新生事物，相信之后的版本应该会有大的改进。MediaCodec用于将音视频进行压缩编码，它有个比较牛X的地方是可以对Surface内容进行编码，如KK 4.4中屏幕录像功能就是用它实现的。
注意它们和其它一些多媒体相关类的关系和区别：MediaExtractor用于音视频分路，和MediaMuxer正好是反过程。MediaFormat用于描述多媒体数据的格式。MediaRecorder用于录像+压缩编码，生成编码好的文件如mp4, 3gpp，视频主要是用于录制Camera preview。MediaPlayer用于播放压缩编码后的音视频文件。AudioRecord用于录制PCM数据。AudioTrack用于播放PCM数据。PCM即原始音频采样数据，可以用如vlc播放器播放。当然了，通道采样率之类的要自己设，因为原始采样数据是没有文件头的，如：
vlc --demux=rawaud --rawaud-channels 2 --rawaud-samplerate 44100 audio.pcm
回到MediaMuxer和MediaCodec这两个类，它们的参考文档见http://developer.android.com/reference/android/media/MediaMuxer.html和http://developer.android.com/reference/android/media/MediaCodec.html，里边有使用的框架。这个组合可以实现很多功能，比如音视频文件的编辑（结合MediaExtractor），用OpenGL绘制Surface并生成mp4文件，屏幕录像以及类似Camera app里的录像功能（虽然这个用MediaRecorder更合适）等。
这里以一个很无聊的功能为例，就是在一个Surface上画图编码生成视频，同时用MIC录音编码生成音频，然后将音视频混合生成mp4文件。程序本身没什么用，但是示例了MediaMuxer和MediaCodec的基本用法。本程序主要是基于两个测试程序：一个是Grafika中的SoftInputSurfaceActivity和HWEncoderExperiments。它们一个是生成视频，一个生成音频，这里把它们结合一下，同时生成音频和视频。基本框架和流程如下：
首先是录音线程，主要参考HWEncoderExperiments。通过AudioRecord类接收来自麦克风的采样数据，然后丢给Encoder准备编码：
AudioRecord audio_recorder;
audio_recorder = new AudioRecord(MediaRecorder.AudioSource.MIC,
SAMPLE_RATE, CHANNEL_CONFIG, AUDIO_FORMAT, buffer_size);
// ...
audio_recorder.startRecording();
while (is_recording) {
byte[] this_buffer = new byte[frame_buffer_size];
read_result = audio_recorder.read(this_buffer, 0, frame_buffer_size); // read audio raw data
// …
presentationTimeStamp = System.nanoTime() / 1000;
audioEncoder.offerAudioEncoder(this_buffer.clone(), presentationTimeStamp); // feed to audio encoder
}
这里也可以设置AudioRecord的回调（通过()）来触发音频数据的读取。offerAudioEncoder()里主要是把audio采样数据送入音频MediaCodec的InputBuffer进行编码：
ByteBuffer[] inputBuffers = mAudioEncoder.getInputBuffers();
int inputBufferIndex = mAudioEncoder.dequeueInputBuffer(-1);
if (inputBufferIndex >= 0) {
ByteBuffer inputBuffer = inputBuffers[inputBufferIndex];
inputBuffer.clear();
inputBuffer.put(this_buffer);
...
mAudioEncoder.queueInputBuffer(inputBufferIndex, 0, this_buffer.length, presentationTimeStamp, 0);
}
下面，参考Grafika-SoftInputSurfaceActivity，并加入音频处理。主循环大体分四部分：
try {
// Part 1
prepareEncoder(outputFile);
...
// Part 2
for (int i = 0; i < NUM_FRAMES; i++) {
generateFrame(i);
drainVideoEncoder(false);
drainAudioEncoder(false);
}
// Part 3
...
drainVideoEncoder(true);
drainAudioEncoder(true);
} catch (IOException ioe) {
throw new RuntimeException(ioe);
} finally {
// Part 4
releaseEncoder();
}
第1部分是准备工作，除了video的MediaCodec，这里还初始化了audio的MediaCodec：
MediaFormat audioFormat = new MediaFormat();
audioFormat.setInteger(MediaFormat.KEY_SAMPLE_RATE, 44100);
audioFormat.setInteger(MediaFormat.KEY_CHANNEL_COUNT, 1);
...
mAudioEncoder = MediaCodec.createEncoderByType(AUDIO_MIME_TYPE);
mAudioEncoder.configure(audioFormat, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE);
mAudioEncoder.start();
第2部分进入主循环，app在Surface上直接绘图，由于这个Surface是从MediaCodec中用createInputSurface()申请来的，所以画完后不用显式用queueInputBuffer()交给Encoder。drainVideoEncoder()和drainAudioEncoder()分别将编码好的音视频从buffer中拿出来（通过dequeueOutputBuffer()），然后交由MediaMuxer进行混合（通过writeSampleData()）。注意音视频通过PTS（Presentation time stamp，决定了某一帧的音视频数据何时显示或播放）来同步，音频的time stamp需在AudioRecord从MIC采集到数据时获取并放到相应的bufferInfo中，视频由于是在Surface上画，因此直接用dequeueOutputBuffer()出来的bufferInfo中的就行，最后将编码好的数据送去MediaMuxer进行多路混合。
注意这里Muxer要等把audio track和video track都加入了再开始。MediaCodec在一开始调用dequeueOutputBuffer()时会返回一次INFO_OUTPUT_FORMAT_CHANGED消息。我们只需在这里获取该MediaCodec的format，并注册到MediaMuxer里。接着判断当前audio track和video track是否都已就绪，如果是的话就启动Muxer。
总结来说，drainVideoEncoder()的主逻辑大致如下，drainAudioEncoder也是类似的，只是把video的MediaCodec换成audio的MediaCodec即可。
while(true) {
int encoderStatus = mVideoEncoder.dequeueOutputBuffer(mBufferInfo, TIMEOUT_USEC);
if (encoderStatus == MediaCodec.INFO_TRY_AGAIN_LATER) {
...
} else if (encoderStatus == MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED) {
encoderOutputBuffers = mVideoEncoder.getOutputBuffers();
} else if (encoderStatus == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) {
MediaFormat newFormat = mAudioEncoder.getOutputFormat();
mAudioTrackIndex = mMuxer.addTrack(newFormat);
mNumTracksAdded++;
if (mNumTracksAdded == TOTAL_NUM_TRACKS) {
mMuxer.start();
}
} else if (encoderStatus < 0) {
...
} else {
ByteBuffer encodedData = encoderOutputBuffers[encoderStatus];
...
if (mBufferInfo.size != 0) {
mMuxer.writeSampleData(mVideoTrackIndex, encodedData, mBufferInfo);
}
mVideoEncoder.releaseOutputBuffer(encoderStatus, false);
if ((mBufferInfo.flags & MediaCodec.BUFFER_FLAG_END_OF_STREAM) != 0) {
break;
}
}
}
第3部分是结束录制，发送EOS信息，这样在drainVideoEncoder()和drainAudioEncoder中就可以根据EOS退出内循环。第4部分为清理工作。把audio和video的MediaCodec，MediaCodec用的Surface及MediaMuxer对象释放。
最后几点注意：
1. 在AndroidManifest.xml里加上录音权限，否则创建AudioRecord对象时铁定失败：
<uses-permission android:name="android.permission.RECORD_AUDIO"/>
2. 音视频通过PTS同步，两个的单位要一致。
3. MediaMuxer的使用要按照Constructor -> addTrack -> start -> writeSampleData -> stop 的顺序。如果既有音频又有视频，在stop前两个都要writeSampleData()过。
Code references：
Grafika: https://github.com/google/grafika
Bigflake: http://bigflake.com/mediacodec/
HWEncoderExperiments：https://github.com/OnlyInAmerica/HWEncoderExperiments/tree/audioonly/HWEncoderExperiments/src/main/java/net/openwatch/hwencoderexperiments
Android test：http://androidxref.com/4.4.2_r2/xref/cts/tests/tests/media/src/android/media/cts/
http://androidxref.com/4.4.2_r2/xref/pdk/apps/TestingCamera2/src/com/android/testingcamera2/CameraRecordingStream.java