[openal] Upcoming OpenAL Soft release
chris.kcat at gmail.com
Wed Aug 13 18:44:28 EDT 2014
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
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.
More information about the openal