[Openal-devel] SI Releases?
chris.kcat at gmail.com
Mon Aug 13 16:06:05 PDT 2007
On Monday 13 August 2007 01:05:26 pm Eddy [the Obsessed] Cullen wrote:
> Version numbering
> Please read the Linux Program Library HOWTO at
> Basically, the micro (patch) version should be strictly incremental, so
> that sysadmins know which the latest version is.
That page isn't terribly clear. I looks like it says that you have the base
libfoo.X name, and X should be incremented whenever the interface changes.
The OpenAL API is good about keeping backwards compatibility, so does even
adding a new function while leaving the others alone, constitute a change?
> CMake and Autoconf
> Personally, I don't understand what is wrong with vanilla Make; All you
> do with CMake is introduce an additional dependency to do a job that can
> be done perfectly well if you invest the time into learning how to use
> Make properly. The Microsoft version of Make (is it nmake?) is next to
> useless and is SOOOO bad as to not even worth bothering with!
CMake can output makefiles. It can also output KDevelop project files, MSVC
project files, and others, from the same set of scripts. Make itself is
pretty poor, which is why it needs something like autotools or cmake to set
it up. In addition, autotools is a set of programs and relies on a bash-like
shell on a Unix-like system.. CMake does not. It's a single program which
doesn't rely on your shell or much of your system. Plus, it produces very
clean output, and is measureably faster than makefiles from autotools.
> Release Schedule
> Dunno if any progress has been made on this front.
> My observations of other successful OSS projects (Linux Kernel, WINE),
> is that there is a Code Czar (or Tsar) who dictates what goes into a
> release and determines the release schedule.
> It would seem that Jason is the de-facto Czar at the moment and he would
> be delegating the preparation of releases to Chris.
The main problem is time. The Linux Kernel and Wine, for example, have people
working on it and contributing every day. And while I could work on OpenAL
most days, I'm still new to this, and all my changes need to go through Jason
or someone else. And he doesn't have much time to go through everything. I
would love to get into a (semi-)monthly release schedule, but it's also not
something I think we want to force out simply because "time's up", and end up
with a release that most people can't even build or use. Maybe when things
are stablized, but there's quite a few big changes on the horizon.
> I had considered looking into it myself, but hadn't got very far with
> it. The approach I would suggest is, based on the spec, write a
> COMPREHENSIVE set of tests to confirm the functionality of the current
> implementation. A real yawn-fest, I know, but it's a do-once job.
There is already are some test programs, in the contrib/ directory of the SVN
tree. Although they don't seem to all work properly on my system (the
programs themselves, not the functionality they're testing).
> Step 2 would be to define what you want to fix in the next release and
> publish it!. This will help contributors know where to work... Clearly
> in the long term, 1.1 conformance is a high priority...
> While we're on the subject, I personally feel that the structure of the
> standards doc isn't as conducive to "working-to-specification" as it
> could be; I personally feel that more numbered headings makes it easier
> to work-to-specification. This may be just some mental blockage that I
> have (hey man, no-one is perfect, not even me! *grin*).
> If looking at a release-schedule, how about targeting 3 months to begin
> with? Something that can always be adjusted...
I had planned to start getting a release together as soon as my new capture
patches got in. I have plenty of other things ready to work on, but I'm
simply waiting until a release is made.
However, just the other day while trying to help someone with the SVN version,
I ran across a couple showstopping problems (the SDL backend crashing when
probed, compiles failing due to missing _GNU_SOURCE in some configurations,
etc).. things that are difficult to spot if you're not looking in the right
place. It would've been a disaster, IMO, if a release was made with those
> Dropping of Support for OpenAL
> Sad to hear that people are dropping support of OpenAL. I think this is
> more a PR thing than anything else; I know that Creative provide a full
> 1.1 implementation in their Windows drivers (well, for newer cards at
> least). As far as I am aware, there is no API like OpenAL out there
> (SDL, PortAudio and JACK are all low-level); it is the de-facto standard
> for 3D sound (it's even used on the XBox FFS!).
I believe most people would be satisfied with simple stereo panning and
distance attenuation, both of which are simple to do in software mixing.
I think the real reason for the drop, at least as far as Linux is concerned,
is that there hasn't been a new release in over a year, there are many
outstanding bugs, and even getting the SVN version isn't very straight
It's easy for people to assume development died, even though that's not
technically true. I've been working on what I can though, and I hope that
when I start getting out somewhat regular releases and letting people know
that bugs are getting fixed, it can be picked back up.
More information about the Openal-devel