3
votes

I am using AudioRecord.read to capture PCM data to bytes. However, I found that it restricted to initialize the AudioRecord object with at least 3904 buffers. Where the sampling rate is 44100. Since I need to perform FFT of the data so I increased the samples to 4096. As a result, the callback runs every 40-60ms by setPositionNotificationPeriod to 500. Since a further decrease the duration doesn't make any changes. I'm wondoring if it is the fastest callback time with below configuration?

Sampling Rate: 44100

Channel: Mono

Encoding: PCM 16 BIT

BufferSize: 4096

(Im not sure if it is 4096 or 2048 since I read 4096 bytes every time and it can only fill 2048 2bytes buffer)

even 40-60ms is acceptable, I then perform FFT which eventually block each callback around 200-300ms. And there is still many noise affecting the accuracy. I'm using these source code: FFT in Java and Complex class

Is there any other choice that perform fast, reliable and consume less memory processing FFT? I found that the above classes new too much objects and pop up loads of gragarbage collection's messages.

In conclude, I have 3 questions:

  1. Is the initial bufferSize equal to the buffers that I can read from the .read method?
  2. Is 40-60ms the limitation to capture audio data with 44100 sampling rate?
  3. Could you suggest some FFT library so that I can have a better performance in processing FFT? (I think if it is better to use C code library?)

Sorry for my bad english, also thank you for spending your time on my question.

P.S I tried it on iOS and it can just take 512 samples with 44100 sampling rate. So every callback takes around 10ms only.

1
@Dan, Good question. I am trying to do some signal processing as well in real time. Sample rate and other input configurations are the same. My issue is that i am taking way too long for processing the incoming samples i.e the time between two subsequent reads is very less. I was wondering if you have similar issues and how you go about solving this. TIAVJ Vélan Solutions
Do you mean your calculation taking too long, as a result you can't complete the process within two callbacks? I believe that the audio processing method shouldn't take too long ,otherwise you may fail to process every buffer in every callback. Also, NEW as less as object that you can. So you can eliminate that the CPU keep handling memory management processes.Dan
what are 'buffers' in your 3904 buffers? I'm sorry I'm a noob to audio processing. I'm guessing it's a space reserved for storing audio data until it can be played back?bad_keypoints

1 Answers

0
votes

Regarding question #3: Maybe not as fast as a native library, but I've started using these classes, and they seem to be fine for real-time work (although I am reading from files, not the microphone): FFTPack.

The most common native library is KissFFT, which you can find compiled for Android as part of libGDX.