2013年8月3日星期六

Recording rampVolume parameters overflow issue

 

found in the recording process is always in front of the 1s will "pop" sound of the noise. Has been tracking the search and found the Android source code has caused an overflow. stagefright in AudioSource the void rampVolume (int32_t startFrame, int32_t rampDurationFrames, uint8_t * data, size_t bytes); function (raise the volume from mute to the actual level linearly). In AudioSource's read () function reads data from the AudioRecord been calculated

 

int32_t autoRampDurationFrames =
(kAutoRampDurationUs * mSampleRate + 500000LL) / 1000000LL;

 

int32_t autoRampStartFrames =
(kAutoRampStartUs * mSampleRate + 500000LL) / 1000000LL;

 

int32_t nFrames = mNumFramesReceived - autoRampStartFrames;

 

rampVolume (nFrames, autoRampDurationFrames,
(uint8_t *) buffer-> data (), buffer-> range_length ());

 

nFrames and autoRampDurationFrames calculations which there is an overflow, kAutoRampDurationUs and kAutoRampDurationUs int64_t types of values ​​are calculated results directly cast to int32_t type. So the modified code for the

 

int64_t autoRamp = kAutoRampDurationUs;
autoRamp * = mSampleRate;
int32_t autoRampDurationFrames = (autoRamp +500000 LL) / 1000000LL;

 

autoRamp = kAutoRampStartUs;
autoRamp * = mSampleRate;
int32_t autoRampStartFrames =
(autoRamp + 500000LL) / 1000000LL;

 

int32_t nFrames = mNumFramesReceived - autoRampStartFrames;

 

rampVolume (nFrames, autoRampDurationFrames,
(uint8_t *) buffer-> data (), buffer-> range_length ());

 This would solve the rampVolume

function data processing nFrames frame sonic boom issue.

 

by analogy, the player's file size limit of the problems are caused by the overflow problem, file size, use int32_t type of place limits the size can only support up to 2G, so These places need to be modified to support file sizes int64_t allows to store files fat32 maximum 4G.

1 条评论: