[ Thread Index |
| More lists.liballeg.org/allegro-developers Archives
On Wed Jan 4, 2012, Peter Wang wrote:
> 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>
> > >> 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.
Though now we have buffers in the sound card/driver, then in things like PA,
then in allegro, and then again likely in the user code. I'm not sure we want
to go that route. Remove as many buffers and copying as possible.
> --- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> complex infrastructure or vast IT resources to deliver seamless, secure
> access to virtual desktops. With this all-in-one solution, easily deploy
> virtual desktops for less than the cost of PCs and save 60% on VDI
> infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox