[Openal-devel] OpenAL Soft finalizing and release planning

[Chris Robinson]

Hi guys.

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 
afterward.

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.