[openal] Upcoming OpenAL Soft release

[Chris Robinson]

On 08/13/2014 02:35 PM, Peter Hunnisett wrote:
> The only issue I know of is that capture doesn't work (massive underrun
> problems)  on Windows/Cygwin/PortAudio due to the small number of
> default buffers provided by PortAudio (16 samples provided when
> paFramesPerBufferUnspecifiedis used) and the fact that their callback
> thread only seems to wake up every 5ms or so (which would require 50+
> samples for 11kHz sampling) on my machine. I haven't talked with
> PortAudio but I kind of see it as their problem or a driver problem as I
> would expect a default value to work.

Yeah, PortAudio should be able to ensure it can keep up with itself. I 
would try to make the backend specify sane buffer metrics, but the 
PortAudio API doesn't really give enough control for that -- at most you 
can specify a "suggested latency", but that's pretty much just a measure 
of how long it'll take to get from the card to OpenAL Soft, and nothing 
about the period size (how long between audio updates) and the buffer 
size (how much audio can be stored in total before it has to be read or 
become lost).

Honestly, I'd like to be able to get rid of the PortAudio backend since 
it doesn't give as much control as I'd like, and just recommend using a 
backend that's a bit more native to the target system (mmdevapi, dsound, 
and winmm for windows, alsa and pulseaudio for linux, etc).

>  From the OpenAL side of things, it would be handy to have some kind of
> way to configure how much latency could be handled on capture either
> through the API or in the config file to work around the problem. I
> suspect that might not be viewed as a quick little change to add in.

Unfortunately, yeah. A redesigned capture API is something I want to do, 
one that lets you open a device and query it for its capabilities 
without having to commit to a format, sample rate, and buffer size 
first. But I still haven't got a design that I'm happy with.