Heads up: SDL now supports audio capture! With the latest in revision control, you can record audio from a microphone. This will go into 2.0.5.
To use: you can enumerate capture devices the same way as you normally would; that previously-unused “iscapture” parameter should be set to 1.
You open audio devices for capture as before, but with iscapture=1. The difference is your callback will fire as usual, but you are expected to read data from it–the audio from your microphone–instead of writing data to be played.
If you hate callbacks, I’ve added SDL_DequeueAudio(), which works like 2.0.4’s SDL_QueueAudio() but pulls data that is collecting from the mic.
This is implemented for darn near everything: Windows, Mac, Linux, iOS, Android, Emscripten.
(This works in Firefox and Chrome on the desktop, Chrome on Android, and not at all on Safari or iOS at the moment. WebKit does not currently offer audio capture support.)
Feedback welcome!
Also worth noting: the Mac/iOS audio code has changed from AudioUnits to AudioQueues. This fixed several problems and was more pleasant to work with.
If you have a Mac or iOS SDL game, please test the new code, even if you don’t care about recording audio.
This is wonderful news! I am a bit of a newbe and have two questions:
Is there any bare-bone tutorial on how to use sound capture in SDL?
Also, are there functions built in to get let’s say the power of the recorded sound signal?
To be clear, the Mercurial “tip” tag is the latest commit to the
repository, regardless of branch, which at this very moment in time will
get you the bleeding edge of SDL 1.2.
(default.tar.bz2 might work better? I haven’t tried.)
Just in case if anyone runs into the same kind of issue as I described above.
I fixed the problem by commenting out all calls to the function
Code:
WIN_SetErrorFromHRESULT
in the file SDL_render_d3d11.c, as well as some calls to the function
Code:
SDL_SetError
Somehow their syntax caused errors during the build process - but since their purpose is only to generate error descriptions when some routine fails, I thought removing them won’t hurt functionality. With this the code built successfully.
Question:
Does SDL_OpenAudioDevice open a recording device in exclusive mode, so that no other application can access and record from this device in parallel?
Now you would get a callback that fires regularly, just like you would
for a playback device. Instead of writing data to a buffer in that
callback, you read data from it. The callback fires when enough data has
been read from the microphone.
If you don’t like doing that, you can use a NULL callback, like that
example code does:
And it’ll hand you whatever data is available at the moment, continually
buffering more as it comes in. If you do this, you have to either call
SDL_DequeueAudio() regularly, or make sure to SDL_PauseAudioDevice()
when you don’t care about recording, or SDL will keep buffering up audio
until it runs out of memory. Naturally, the callback avoids this
problem. Just be careful about times when you’re busy doing something
that blocks, like maybe loading a new game level, that you might be
consuming memory and not realize it (and then have a lot of
needlessly-buffered audio when you come back to it later).
When you’re done recording and want to clean up, you close capture
devices the same way you always would with SDL_CloseAudioDevice().
Depending on your needs, SDL_Quit() cleans up any open ones for you when
shutting everything else down, too, and that might be more simple.
Basically, that’s all there is to it. It’s a handful of function calls
from start to finish.
Also, are there functions built in to get let’s say the power of the recorded sound signal?
We only provide raw PCM data, but you can calculate this from that. The
dirt simple way is what ioquake3 does for their VoIP power meter:
Which is strictly speaking not correct but works pretty well anyhow.
Also, what version of SDL should I get to play around with these new
features?
The latest in revision control, which will become an official 2.0.5
release in a few weeks, at most.