[Openal-devel] Loopback API design question
erik at ehofman.com
Sun Mar 4 02:08:36 PST 2012
On Thu, 2012-03-01 at 08:22 -0800, Chris Robinson wrote:
> On Wednesday, February 29, 2012 10:43:17 AM Erik Hofman wrote:
> > The way I envision this is that setting refresh disables real-time
> > rendering (I could live with another way of telling the library to do
> > so). This way the rendering step is triggered when calling the
> > alcCaptureSamples function, just prior to returning the data.
> This seems closer to the behavior of setting ALC_SYNC to true. On Loki's
> implementation, that would mean you had to call alcProcessContext to actually
> do the mix synchronously (where it would then automatically be sent to the
> device). I'm not sure if any other implementation did anything with the flag,
> though. Creative and OpenAL Soft always set it to false, and OSX seems to
> actually error if you try to query it.
Yeah but ALC_SYNC is sort of abandoned because no-one really know what
to expect from it if I recall correctly.
> > This would indeed require a device, being it a software renderer or a
> > hardware accelerated one. In both cases it's just a matter of rendering
> > up to the point the data is sent to the physical device and then instead
> > of doing so returning the processed data to the caller application.
> I still don't like the idea of hijacking a device that's expecting to play
> audio and "stealing" the data away from it before it gets a chance to. It's a
> potential waste of resources as there could be a hardware device open, but
> left unused because the app is reading the mix instead of giving it to the
> I'd rather behavior like that go towards a device-level foldback extension,
> where the app can capture audio that the card is actually playing.
Alright I have this implemented for my own OpenAL implementation (using
a different ALC_AAX_capture_loopback extension) but will not implement
non-real time behavior until there is consensus. It would be nice to
hear feedback from others before we proceed.
> As an aside, I'm considering using a string parameter for
> alcLoopbackOpenDeviceSOFT. My reasoning is, it appears the enumeration list
> given by ALC_DEVICE_SPECIFIER is effectively a list of drivers, not devices.
> "Generic Software", "Generic Hardware", etc. Even for opened devices, it
> returns the name of the driver it belongs to. A string will allow for opening
> a loopback device on a specific driver without having to actually open a
> device. So, I think I'll let the function work with the names returned by
This triggered the thought that we might need loopback device
enumeration using ALC_ALL_LOOPBACK_DEVICES_SPECIFIER in case we should
proceed with the capture_loopback extension.
More information about the Openal-devel