Is there a fastest way to get the PCM of microphone input? I’m looking at the record and customDSP examples, but since I don’t need i.e. to play back the sound, record it to disk, or perform any effects with the dsp, I am wondering whether things can be cut away or for shortcuts to increase speed.
For example, should I obtain the PCM with getMeteringInfo or directly with a custom dsp callback?
naively I’d try to:
make the sound & custom dsp, start recording and then in loop query the dsp’s *inBuffer.
The fastest most low latency way to get data from the microphone is to simply call System::getRecordPosition and Sound::lock/unlock on the sound, capturing data and writing it to your own buffer every time the cursor moves (ie from getRecordPosition). You would poll it in a loop. It would probably give you 512 to 1024 samples at a time for example, depending on the driver.
My aim is to obtain, per frame of my program, one sample which best approximates the signal during its last sampling interval. Should I simply take the middle value from ptr1? Or is there a simple method to approximate this better?
How should I determine the second parameter (the buffer length) in sound::lock?
It depends on your block size, but generally its not a good idea to pick 1 sample. It would be more accurate to take the average of a sliding window of samples. If you don’t mind the value being 1 value every 1024 samples for example (23ms @ 44khz) then you could use the RMS of the whole 1024 samples. (sum the squares of every sample then square root the whole lot) or use the max(fabs(…)) value of the window. If you want finer granularity you’d have to timestamp when the position changed, and use a millisecond timer (ie QueryPerformanceCounter) to interpolate a smaller window inside the bigger window.
http://www.fmod.org/documentation/#content/generated/FMOD_Sound_Lock.html describes the parameters. length is how much of the sound that you want captured. You can give as much or as little as you want, but it would make sense that it is not longer than the length of the sound. Also if the position + length that you provide is past the end of the sound length, you will get wraparound, and then ptr2 and len2 come into play. If you want to avoid the complication of wraparound and only use ptr1 and len1, make sure offset and length divides evenly into the length of the sound size. (ie 10240 sound length, and use offsets and lengths with multiples of 1024 which would avoid any wraparound)
to add to 2) … I would just lock from the position that getRecordPosition gave you, minus the delta that it moved by. The delta would be your length. That gives you the smallest, most recent amount of recorded data possible.
Brett:
I have a followup to Jake’s original question. Which “sound” do I lock when no saving or output is required – just an interest in capturing the microphone input? Creating a “sound” requires that I specify several parameters, but how do I set these parameters to minimize the processing of the raw microphone input (since Sound seems to be related to output, not input)?
you always need a sound - this is the memory that the recording system records to.
The parameters wont change anything to do with latency. You set it to the recording format you want (ie channels =1 if you want mono, 2 if you want stereo, pick a rate you like , ie 44khz or 48khz).
Latency is a function of where you are reading from and where the write cursor is writing to at the time. This is done with System::getRecordPosition and Sound::lock/unlock as explained.