[Openal-devel] RFC: OpenAL audio recording extension.
valenzuela at treyarch.com
Tue Jan 27 07:31:16 PST 2004
On Jan 26, 2004, at 11:55 AM, Ryan C. Gordon wrote:
>> Issues as I see them:
>> Should there be an additional token requirement for alcOpenDevice
>> informing it that recording will be necessary?
> Ideally, I'd have liked to avoid a seperate OpenDevice entry point for
> capture at all, but I don't feel that trying to encode everything into
> alcOpenDevice()'s device name is a good decision, either.
Well, IIRC some backends benefit from knowing whether they want to be
used as write or read/write. But the implementation dependent nature
of the device specifier probably makes that too messy anyway.
> I'd like to see something akin to the way we feed arbitrary attributes
> to alcCreateContext() being used with an alcOpenDevice-replacement in
> some future revision of the AL spec for several reasons, not the least
> of them being that you could cleanly reuse the entry point for both
> input and output. But for now, I think fully seperating alcOpenDevice
> and the capture extension is the best route.
Something akin to the ALint array syntax would be good then, I think.
>> 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
> My thoughts on this:
> 1) I think that we should bend over backwards to make sure the
> application doesn't _ever_ have to do any conversion or resampling
> outside of AL (for reasonable cases, at least). Potential aid from
> future hardware implementations aside, a given AL implementation is
> going to be better positioned to contain extremely optimized and
> debugged code for this very specific purpose. For example, a Windows
> developer that just wants to process input from a microphone is going
> be annoyed about writing an SSE-based converter, but doubly so when he
> ports to the Mac and has to do it again with Altivec, etc...game
> developers should spend their time developing games and not audio
Any application which captures audio has to do something with it.
They can either play it directly (in which case AL converts
it in alBufferData), or some sort of post processing is going to
So, okay, we don't want to force them to convert it if they don't
want to. But there's no combination of options to say
"just give me the default," and no provision for reporting what
those defaults are.
Well, the more I think about it, the more it seems like there's
no point in allowing the application to defer to "default"
mixing parameters. The smallest stumbling block would be the
fact that there's no idiomatic way for the implementation to
tell the application what those defaults are.
> 2) Generally speaking, you want to process captured audio in one format
> of your choice and be done with it...this cuts down on codepaths and
> corner cases in the app itself. If you can't tell the implementation
> that you want a specific format at a specific sample rate, then a lot
> the under-the-hood ugliness of AL is dumped into the app...in such a
> case, every parameter matters.
I guess silent conversion *to* the canonical mixing format sets the
precedence, so silent conversion *from* the canonical capture format
seems harmless enough. Especially since I can't think of a clean way
to report the promoted frequency/format/etc.
>> 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.
> If you mean one capture thing per device, I agree. If you want to mess
> around with all sorts of state, then you're really drifting away from
> audio capture and closer to a "render-to-buffer" extension...which is
> also very interesting, but isn't the slippery slope we're on at the
> moment. :)
Well, in that point all this implicit conversion would probably have
to be addressed just for the performance :) But lets leave that for
some later day.
>> The problem with sync and async contexts seems messy though. What
>> sort of latency guarantees should alcCaptureStart make?
> I have no idea. :(
> Something like CoreAudio feeds something like 1024 stereo Float32
> samples per callback by default at 44100 (but you can change this).
> Something that is queueing on the hardware until a buffer is totally
> full before sending it over the bus might queue more and then have the
> available samples it reports jump much higher.
> FWIW, I implemented the extension in my implementation. It's
> "ALC_EXT_capture" for now...the string doesn't clash with the Loki
> "AL_EXT_capture" token and uses alc's extension query entry point
> anyhow. This will be hitting CVS probably today. It currently writes
> "THIS EXTENSION IS SUBJECT TO CHANGE!" to stderr when you open a
> device, though, and I'm still perfectly willing to make changes...I
> wanted to discuss this less abstractly, though, so I laid down some
Okay. How about alcCaptureStart starts at the next process context
"synchronization point" in synchronous contexts and the equivalent
in async ones? alcCaptureSamples will do what then? Start the copy
from the internal buffer from the synchronization point forward?
More information about the Openal-devel