[AD] audio recording

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


I added an audio recorder (for PulseAudio) to the audio addon:

http://alleg.svn.sourceforge.net/viewvc/alleg?view=revision&revision=15148

To use it, you create your own buffer and pass it to recorder. Every
time it has at least N (user defined) samples ready, it sends an
event. When it runs out of space in the buffer, it sends a different
event, at which point, it is the user's responsibility to inform the
recorder of the next buffer location. (It could very well be the same
buffer.)

It seems to work fine on PulseAudio. I find this more user-friendly
than having Allegro control the buffers. I don't know how the other
drivers work, but PulseAudio uses its own internal buffer anyway. So
there's plenty of time one can waste after receiving a full-buffer
event before informing Allegro of the next buffer.

If other drivers work differently (no buffering), then Allegro would
probably have to internally manage some secret buffers to queue up
data while the user buffer is full.

I set the PulseAudio latency to an arbitrary 1/8th of a second (if I
understood the docs correctly). It defaults to ~2 seconds, which is
noticeably laggy. The lower the latency, the more resources (CPU) are
used. So basically, even if you request one sample per fragment,
you'll still have to wait around 1/8th of a second to receive it. At
that point, you'd receive an event per sample (again, if you were to
request that). If other drivers get implemented, then we probably
should revisit a way for the user to control these settings a little
bit, even if it's something generic like "low", "medium" and "high"
hints.

See ex_record.c for a simple example (that ought to be updated to use
the common.c, I suppose). Make sure your default PulseAudio recording
device is set first.

--
Matthew Leverton




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/