Audio Spectrum Data, PC vs Android

EDIT : I think we have it figured out, it was indeed a matter of the size of the buffer being processed at the time of frame draw. Breaking it up into smaller chunks and processing multiple times per frame was the fix. It would be nice if you could specify a starting index with GetSpectrumData and use the read head accordingly without needing to reprocess the sound and make multiple calls per frame, but it's a solution nonetheless.

Leaving this here in case it can help anyone else.

Hey guys,

I'm having an issue that's becoming a major roadblock to the development of our application, and I am wondering if anyone here might have some insight to help us out. We've taken a number of troubleshooting steps but still are having little luck.

Everything works fine on the PC within unity, but there is a clear difference on the Android build.

I've attached a screenshot do illustrate the difference. What's displayed is the spectrumdata[256] over the past 32 frames of data. You will notice right away the android version appears to have much lower resolution as the information seems more pixelated than in the desktop build. Our first thought was there was a buffer issue happening. we did some looking around and found this solution to try and overcome buffer read issues :

Code (CSharp):

1.      
2. int readHead = 0;
3. bool hasNewData = false;
4.  
5. void FixedUpdate () {
6.         int writeHead = Microphone.GetPosition(MicGlobal.CurrentAudioInput);
7.         int samplesToGet = (audioSource.clip.samples + writeHead - readHead) % audioSource.clip.samples;
8.         int maxSamples = Mathf.FloorToInt (audioSource.clip.frequency * Time.fixedDeltaTime);
9.         if (samplesToGet > maxSamples) {
10.             samplesToGet = maxSamples;
11.         }
12.         hasNewData = false;
13.         float[] waveform = new float[samplesToGet];
14.         if (samplesToGet > 0)
15.         {
16.             hasNewData = true;
17.             audioSource.clip.GetData(waveform, readHead);
18.             readHead = (readHead + samplesToGet) % audioSource.clip.samples;
19.         }
20. // convert data to fft here.
21. }
22.  

Obviously this is just a small section and there are variables outside of this scope, but it should give you an idea of the steps we are taking here. This just gets the waveform data however, so we tried incorporating this FFT conversion script :
https://gerrybeauregard.wordpress.com/2011/04/01/an-fft-in-c/

However, this still reproduced the same issue as though we were using :
audioSource.GetSpectrumData(spectrum, 0, FFTWindow.BlackmanHarris);

Take a look for yourself, I've included as much information as I can on screen to help debug this, and would appreciate any support you can provide.

Desktop version : notice the resolution in the window (ignore the red, that's simply a threshold)

Android Verrsion : notice the low resolution bands present

 

Would you mind posting a snippet of how you're using GetSpectrumData? I'm having trouble with it myself.

 

The getSpectrumData is actually a little broken in that it won't give accurate results on mobile. We ended up using this solution : https://gerrybeauregard.wordpress.com/2011/04/01/an-fft-in-c/ which works well on android, and on desktop/editor. you will find you may get a mirrored result though, but that's easy to workaround.

You need to use the read head workaround specified above to read the raw waveform data at the appropriate position and then use FFT2 to get the correct spectrum data