[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Wed, 4 Jan 2012 11:39:02 -0600, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> 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.
If I understood correctly, there is an arbitrarily long gap between when
the user provided buffer is filled and the next call to
al_update_audio_recorder_buffer. To avoid any skips the data must be
kept somewhere in the meantime. I guess PulseAudio, being a high level
library, provides conveniently large buffers that can bridge that gap.
We might find that the buffers are not so big with other backends.
Or we might deliberately choose smaller buffers to improve latency (as
you did with PulseAudio). The gap could be overcome in a couple of
ways. The user could provide multiple buffers, and Allegro would rotate
through them as they are filled up. Or, Allegro could simply allocate
its own buffers. In the latter case copying would be minimised if the
Allegro API returns a pointer to an internal buffer.
Peter