Re: [AD] audio recording

[ Thread Index | Date Index | More Archives ]

On Fri, 6 Jan 2012 02:51:52 -0600, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> On Wed, Jan 4, 2012 at 5:17 PM, Thomas Fjellstrom
> <tfjellstrom@xxxxxxxxxx> wrote:
> > 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.
> >
> I agree.
> However, ultimately, as long as you can tell Allegro how often to
> report new samples and what size of buffer to use, it won't really
> matter if Allegro uses an internal or user buffer. e.g., If a person
> could inform Allegro to use one 8MB buffer and send an event every
> 1000 samples, that would be no different from using an external buffer
> and pointing Allegro to it.
> So the distinction between an internal buffer and user buffer is
> almost irrelevant in terms of decreasing the amount copying. But there
> are two cases I was trying to avoid:

The minimal amount of copying occurs when reading out of a buffer which
is filled directly by the driver/hardware.  For ALSA
snd_pcm_mmap_begin[1] returns an array of pointers to mmap'd regions.
I've not yet found an example which reads from those regions, but
apparently it's possible.  I don't think it's possible to use an
arbitrary, user-provided memory location.  But, I don't know if we need
this level of detail in our API.

The Windows waveIn API works by queueing up buffers to be filled with
waveInAddBuffer[2].  Once a buffer is filled the application gets a
notification.  If there is no buffer available then data is dropped.
I suggest that al_update_audio_recorder_buffer is changed to queue up
additional buffers.




Mail converted by MHonArc 2.6.19+