[Openal-devel] OpenAL Soft finalizing and release planning
chris.kcat at gmail.com
Wed Mar 7 11:59:19 PST 2012
My current plans are to complete the new AL_SOFT_direct_channels and
ALC_SOFT_loopback extensions either this weekend, or early next week, unless
anyone has objections*. A release will probably follow a couple weeks
Along with that, I'd like to make a call for testing. Quite a bit of OpenAL
Soft's internals have been reworked to allow for more efficient parallel
processing. That means there's less lock contention in a number of places by
using per-device mutexes, finer-grained rw-locks, and atomic operations as
opposed to the One Lock To Rule Them All of previous versions. With such
drastic changes, I really want to make sure nothing's broken, particularly for
apps that may use multi-threaded access. So far all my own testing has worked
great, but more couldn't hurt.
Also, the PulseAudio backend has gone through some minor but significant
changes in the last week. The situation with the lag and large update times (a
problem that creeps up for some people when the server's been running for a
bit) should *crosses fingers* be vastly improved. It works really good for me,
and it'd be great if other people could test this, even if you didn't have
problems before just to make sure it's still working.
ALSA has also been modified recently in a couple ways. For one, playback
better detects a capable output mode. So if you don't use PulseAudio, you can
try setting the ALSA device option in ~/.alsoftrc to your own custom device
without using 'plug', if you have one. It just may pick up the "default"
configuration with no further tweaking necessary (though no guarantees, given
how vast sound card capabilities and ALSA configurations can be; OpenAL Soft
still tries to stick with sane defaults unless it's reasonably sure something
better will work properly).
Secondly, ALSA capture offers a more direct path for capture now too, avoiding
an intermediary ring buffer if the device can support the requested buffer
length (if not, it will fall back to the older method). It's a minor thing,
but it would be nice to make sure it didn't break for anyone.
For Windows users, there's also a new mmdevapi backend. This should work
better for Vista/7 users since it won't go through the DSound layer just to
play a single stream that's going to go through mmdevapi under the hood anyway
(though mmdevapi is more stringent on the formats it can accept, which OpenAL
Soft tries to match). There's currently an issue with the Git version where
this backend may cause a crash if the lib gets unloaded dynamically (ie, via
FreeLibrary), but this will be fixed before release. Other than that, I'd like
to make sure this works on as many real Windows systems as possible.
Thanks for your attention. :) One more thing: if you do any testing, please
make note of the ALSOFT_LOGLEVEL and ALSOFT_LOGFILE env vars (described in the
newish env-vars.txt file). This will make the lib print out more info to make
sure everything is running as expected. If you run into any problems, it'd be
useful to have a trace log (log-level 3).
* I do plan to work more with Eric for his capture_loopback extension, but as
I noted in the other thread the use-case of this loopback extension is
different, and it doesn't feel right to shoe-horn them together. I will likely
implement the other extension when it's done, but 1.14's release is way past
due, IMO. I'd like to get it out before April, and I'm already fighting
against feature creep.
More information about the Openal-devel