I see people ask about this on here from time to time, so I hacked up a plugin over a weekend and figured I’d publish it. There’s a native library so you’ll need Unity Pro, and the scenes might need Unity 3.4.1; I’ve included all of the source code if anyone wants to hack on it.
Afraid Im not having any luck getting this working on OS X though:
Cannot get fft example to work. It says its found 1 input, but I see nothing, regardless of whether I have line-in or mic selected as input device in the OS. I don’t see any error messages in unity, and the problem is the same with Lion and Snow Leopard. If I load an audio file into the audio player then I see bars at the bottom of the screen, but the central fft display never does anything.
Record demo crashes unity editor when using OS X Lion. It doesn’t crash if I use Snow Leopard, but Im not sure if its actually recorded anything.
I haven’t tried rebuilding the plugin, just using the downloaded binary version.
I don’t have Lion, so I don’t know if the plugin works there. From what you’ve said, I guess maybe not. The Mac version is kind of an afterthought I’m afraid. The Windows version should be fairly sturdy
Two things:
You’ll need to call StartDevice etc. yourself in the FFT scene; really there’s a missing component that wasn’t mine to release with the rest of the project. How that worked was, the missing component found a WaveInFFT component on the same object using GetComponent, then called StartDevice in ‘Start’ to start receiving samples. I guess you could call StartDevice from a ‘Start’ added to WaveInFFTDemo (be mindful of the order of calls there I guess, since WaveInPlugin needs to do some stuff in ‘Start’)
Look at the console output in the record demo; it should include the name of the file(s) that raw samples have been written to.
If I just add the line waveInFFT.StartDevice(0); to the end of the Awake function in WaveInFFTDemo.cs then it works!
Only on Snow Leopard though, the above crashes Lion in the same way the record demo did. I doubt I have the skills to fix this but I will investigate a bit anyway.
A standalone built with the ‘record’ scene doesn’t crash (actually appears to work fine)
The editor does crash; worse, the Unity bug reporter comes up but the editor hangs up and has to be force-quit so there’s no call stack for me to look at. Even worse, for whatever asinine reason, I can’t attach the Xcode debugger to the Unity application (I’ve noticed this before, and I suspect it’s a DRM thing; there’s no such problem using Windows and MSVC).
So, you’re not alone, but I don’t know what to do to help you
Thanks for trying. I spent some hours looking at the source for the plugin, but I was unable to spot anything really obvious. Looking at editor log in console wasn’t terribly illuminating to me, but this is what I got:
That’s consistent with what I see; the problem occurs somewhere in ‘GC_mark_some’. It feels like this is a mono/Lion issue (the reverse p/invoke in the plugin is something that maybe not many other people are doing, and it’s tricky with other threads calling into the mono runtime: it should work (and it appears to on other operating systems), but maybe there are problems on Lion. Anecdotally, I’ve heard that there are problems with older versions of mono on Lion. I can’t find much in the way of detail about that though).
Hey, thanks heaps for this, I am pretty stoked about getting it running since I am currently using a very round about method (Processing > UDP > Unity) to get the mic fft data.
I downloaded the project, on windows, had to upgrade it to 3.5 and I get an error saying:
Actually I got it running, got the wrong version.
Though in the FFT demo I have to add a wave/mp3 to the Audio Source to get it to work?
Am I missing something for getting the mic to work?
I think, if I remember how that demo is supposed to work; you hook up an AudioSource to play sound through the speakers, and the already running WaveIn samples the playing sound. Then an FFT is calculated for both the playing sound and the recorded sound (my idea was that both of those FFTs should look similar, since they are generated by the same sound or close to it). But you shouldn’t need to play a sound; you should be able to make a sound yourself and at least the FFT display of the microphone input should update (in that case there’s no other FFT to display, since the computer isn’t making the sound).
I thought- though I haven’t checked- that microphone input was a built in feature of Unity 3.5? So maybe you wouldn’t need my plugin at all anymore?