[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers 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.
Peter
[1] http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___direct.html#ge4a8891e8afc80c6db7d58d5beac2092
[2] http://msdn.microsoft.com/en-us/library/windows/desktop/dd743838(v=VS.85).aspx