[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Wed, 4 Jan 2012 03:01:22 -0600, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> 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 haven't used it but I can see why.
> 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.
In which case the al_start_audio_recorder is a misnomer. The recording
must already be happening and al_start_audio_recorder just (starts to) copy
the data to the user's buffer.
I think the API would be simpler (conceptually) if you have explicit
functions to start/stop recording. When an event is received ("ready")
the user can call a function to synchronously copy data from an internal
buffer to a user buffer.
Alternatively, we can return a pointer to the internal buffer and let
the user operate it directly, or copy it out manually. The user then
releases the internal buffer, so it can be reused.
This is like al_(un)lock_bitmap.
Peter