[Openal-devel] Loopback API design question

[Erik Hofman]

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 
> card.
> 
> 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 
> enumeration.
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.

Erik