[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Wed, Jan 4, 2012 at 7:53 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On Wed, 4 Jan 2012 03:01:22 -0600, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
>> 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.
>
I don't really follow your reservations. It's true that the
implementation may be silently recording to "/dev/null" in the
background as soon as the recorder is created if that improves
responsiveness, but to me that's a detail that is irrelevant as long
as you are aware (by reading the manual) that creating the recorder
might "lock" the device.
My thinking was that when it comes to recording, you would want as
little copying about as possible, especially if you want real time
recording. To me, making Allegro manage the buffer just means I have
to use yet another API just to set up the type of buffers I want.
For drivers that don't have any natural OS buffering (if there are
any) nothing really has to change, other than prematurely notifying
the user that the buffer is full. The new buffer would sit around in a
"next buffer" pointer until the actual buffer was full. The
event/functions could be renamed to be more appropriate if that is the
case, but it wouldn't really add any complexity.
--
Matthew Leverton