[Openal-devel] RFC: OpenAL audio recording extension.

[J. Valenzuela]

On Jan 15, 2004, at 2:09 AM, Ryan C. Gordon wrote:

>
>> This idea appeals to me as it is very similar to queueing buffers for
>> output.  The expected format would be the format of the buffer (some
>> method would have to be created to check if a specified format is
>> supported, but that could be done with a single new call).  The size 
>> of
>> the buffer and the format determines the latency your application 
>> desires
>> -- the shorter the buffer (and the higher the sampling rate and bit
>> depth), the sooner you'll find that the buffer is "processed."
>
> My concern is that it makes it unreasonable to stack-allocate your
> buffer. There's a certain ease in loading data into a local buffer when
> there's enough to be interesting, processing it, and throwing it
> away...unless that function is going to block until the "buffer" 
> becomes
> "processed", it can't be done this way.
>
> Granted, you may not want to stack-allocate hundreds of kilobytes, but
> if you're just piping incoming data from AL to some other API, like
> Speex, this would be a perfectly sane approach. At the app level, you
> might just want to dump a stream of bytes every frame (regardless of
> size and availability) between libraries and be done with it.

This is one of the areas where callback style interfaces really
simplify things.  Given that we eschew callbacks in general, the
buffer queueing stuff is tempting.  But the old capture extension
used a weird sort of buffering thing that was IMHO messy.  Let's
keep a simple interface.

Issues as I see them:

Should there be an additional token requirement for alcOpenDevice
informing it that recording will be necessary?

Assuming deferred opening in write is fine, I don't think
alcCaptureOpenDevice as explained should have any conversion facility.
I'd prefer either an internalFormat style hint or an ALint array pair
so that implementations could fill out parameters that actually
matter.

I'm for state-esque tokens for querying "state," with the caveat
that there should only be one capture thing, it won't have a name,
context independent etc.

The problem with sync and async contexts seems messy though.  What
sort of latency guarantees should alcCaptureStart make?

--
jv