OpenAL Audio Library Released

Straker Skunk writes, "Loki, in conjunction with Creative Labs, has announced OpenAL, an LGPL'ed audio library for 3D sound generation. It's aimed for use in games as a cross-platform, nonproprietary means of accessing the 3D sound features on many newer sound cards. What's especially cool about it is that the API is designed with the same style, philosophy, and polish as OpenGL. Given enough time, it might very well become just as popular. " I've always been a fan of Loki and it's great to see them supporting the community - someone also sent an interview with Michael Vance, one of the developers behind OpenAL, who talks about the development of OpenAL and how it compares to other sound offerings.

Comments

Re:This can only be good in the end

[CaseyB]

I bet the API is particularly suited towards Creative chipsets.

I doubt this, simply because 3D audio hardware is very nearly a commodity item today. You can play multiple sound sources in multiple locations in 3D space, optionally with a variety of mostly standard effects (echo, reverb, etc.).

Different hardware differs only in minor ways: the number of concurrent streams supported, the quality of the effects, and how much host CPU time is required. They don't vary much in their basic feature set, so there's not much to do in an API to favour one vendor over another.

I might be more skeptical if Aureal were the company involved, as the Vortex chipset supports some extra features (geometry based wavetracing) that the Creative hardware currently does not.

Re:This can only be good in the end

[CaseyB]

> Anyway, Open Audio Library will signal the
> beginning of a true cross platform 3D audio
> system. Hopefully it provides more functionality
> than Microsofts proprietary single platfrom DirectAudio(?)
> system, otherwise it will be hard to get companies to switch over.

I don't see the benefit of doing something like that when you can just have standard sound from multiple speakers. Just take one speaker and put in on one side of the room and another and the other then you have sterophonic sound. Largely unless the sounds are intensely more complex your mind will associate the sound comming from different sources and allow for the "3d" effect.

Huh? So 3D sound isn't necessary, so we don't need an API? I think you've missed the point.

I think that making anything a standard that involves massive cpu computations or involves games in general would be a bad idea.

Do you reimplement qsort from scratch every time you write a new piece of code? Any function that provides a common functionality, regardless of nature, is a valid target for an API. Especially the ones that involve massive cpu computations, as they stand to reap the most benefit from concentrated, incremental optimization by many people.

I thought that there were already various libraries and systems to support ear poping sound on linux someting called ALSA or the like...

The best thing about standards is that there are so many to choose from. -- Andrew Tanenbaum

Yes, there's a standard, but we want a standard cross-platform standard, so we don't have to code for three different nonstandard standards!

No

[joss]

Standard IANAL disclaimer, but...

GPL relies on copyright law

An API is a specification rather than something
that you need to copy in order to conform to
the API.

You don't have the right (as far as I know) to
write a specification and say: "everybody who
produces something that fulfills this specification must abide by these conditions"
- and nor should you IMO, IP laws should be weaker, not stronger. For instance, MS has no
right to impose restrictions (apart from practical ones) on who can implement win32 api,
hence legaility of WINE.

Re:"3D sound" isn't

[Fastolfe]

The cool thing is that this supports mobile "listeners", so given the right hardware (like orientation-tracking VR goggles), you can adjust your character's head's (the "listener's") orientation with the API, thus getting a different angle on the sound. Cool stuff. :)

Of course, when we get better sound setups (with speakers above *and* below the listening plane), this API would let us take advantage of those extra speakers without needing new versions of the games.

Re:OAL -> DD/DTS 5.1?

[Fastolfe]

This is more of an API for the program to tell the hardware (or drivers) how it should render the sound. It would be up to the drivers/hardware to encode this into an output signal (be it DTS, ProLogic, analog stereo, whatever) suitable to your needs.

When will it be used.

[slim]

Someone make sure and post a story when a games company other than Loki uses OpenAL instead of DirectSound for a Windows game.

Then I'll be mightily impressed.

For now it's a noble and admirable effort. Kudos to 'em.
--

Re:A first look

[MichaelKVance]

Actually, that file is out of date, and you'll notice not on the web page :). I'm going to be updating it today.

The material/geometry stuff is not in the spec right now, because we're still discussing the issue of a canonical filter representation for surfaces, etc.

Feel free to mail me any specific questions (briareos@lokigames.com).

m.

Re:I still dont trust creative

[MichaelKVance]

The part about "orientation" isn't true at all. The first thing we did was appraise the current standardizations effort--basically look at the IASIG guidelines. The level 1 stuff is fairly straightforward: attenutation, panning, radiation cones, etc. No bones on that.

The level 2 stuff is the environmental reverb. This is approved by a whole host of companies, which you can see by visiting the IASIG website, including Aureal. You'll also note that this isn't currently a core part of the API--it's an extension (AL_ENVIRONMENT_IASIG, etc.), as we felt this might not be the Right Way to do environmental reverberations, etc., for the forseeable future.

Geometry specification is nice and clean from an API standpoint, but doesn't reflect what's really happenning on the card. When 3D sound boards are doing these geometry calculations in hardware, we can talk about the OpenAL 1.1 API or whatever.

There is also an issue of how to represent "materials". This is far from an easy task to decide.

OpenAL was a lot harder to specify than, say, OpenGL--they already had IrisGL, and they had a very straightforward silicon path--textured triangles.

m.

There's more to 3D than games...

[Millennium]

True, OpenGL's share in the games market is pretty small. But all sorts of other apps use 3D, and GL's share in these is overwhelming. Which makes sense; not so much because DirectX sucks (it does but that's not the point), but because it was designed for gaming, where GL is more suited for general-purpose work.

You seem to have fallen victim to M$ FUD; as usual they took the truth but twisted it so it's presented with a slant.

Re:There's more to 3D than games...

[PantalonesVaqueros]

OpenGL provides better "drivers" on better hardware than what is available from MS. The API is much cleaner (and after taking a quick browse of the OpenAL sight, I rather liked their API: very OpenGL-ish). DirectX, more specifically, Direct3D can't hack it for high-quality high-speed rendering. We briefly toyed with Direct3D for some visualization tools, only to realize just how kludgy the API was and promptly went back to OpenGL. The code is much cleaner. And more importantly, we can run our tools on everything from a beautiful 16-processor SGI to a PC to a Mac to some odd Linux box, to well, one day perhaps a PalmPilot (see that link from last week ). Well, okay, maybe not a PalmPilot.... :)

By the way, nice troll on the "exposing geometry features" bit. That has got to be the easiest troll for OpenGL baiters. It's just so obviously wrong that it sucks people right in. It's a bit like arguing with someone who claims gravity doesn't exist: It just hurts your head...

Then again, the number of people with related in-depth technical knowledge responding to a subject in a slashdot article can probably be counted on one hand :)

Re:Is OpenSource about replacing superior solution

[Stiletto]

Instead of just moderating you down as a troll, I've chosen to respond to this one.

Now WHY do we need a totally new API? Because it's hip to use the totally outdated gl style syntax?

Please explain what "gl style syntax" is and what exactly is outdated about it.

A3D and EAX are here. They are far more well featured. Have had bugs hammered out of them for a long time. This are PROVEN APIs.

Neither of them are open or cross-platform, and AFAIK they are both hardware-specific. This makes them pretty useless to game developers.

As a game developer, why would I want to write to an API supported on only one kind of hardware or one platform? Talk about primitive!

Hopefully A3D and EAX will go the way of RRedline and Glide.
________________________________

Re:Is OpenSource about replacing superior solution

[Stiletto]

gl style syntax is the horrid syntax you can see in OpenGL, and now in OpenAL. Thing like 'alSource3f'. Game development world on PC has pretty much moved over to classes/interfaces for APIs.

Well, I don't really see much difference between

glBegin (GL_TRIANGLES);
glVertex (0,0,0);
glVertex (1,1,0);
glVertex (2,0,0);
glEnd ();

and:

v = &buffer.vertexes[0];
v->x = 0; v->y = 0; v->z = 0; v++;
v->x = 1; v->y = 1; v->z = 0; v++;
v->x = 2; v->y = 0; v->z = 0;
c = &buffer.commands;
c->operation = DRAW_TRIANGLE;
c->vertexes[0] = 0;
x->vertexes[1] = 1;
c->vertexes[2] = 2;
IssueExecuteBuffer (buffer);

besides the amount of code needed in each case. OpenGL is a state machine, and it's API reflects this. Most if not all hardware (graphics and sound) are all basically register-based state machines, so OpenGL and OpenAL resembles the hardware's characteristics more closely.

Also both are not hardware specific.

I stand corrected. How then do your game developers choose an API to use? Certainly ease of use and portability should play a role!

And as a game developer, I can tell you, we couldn't care less about the API porting across. If we publish on another platform, this takes a fair bit of cash anyway. A programmer to rewrite specific lowlevel code is hardly an issue.

But it doesn't have to be this way. Good programmers will not tie their code to a single platform or a single architecture, especially if they know their program is to be ported later. Writing to spec on a portable API means less money and effort will be needed when the program is eventually ported.

Having a cross-platform sound API is going to be a major timesaver. Perhaps EAX or A3D or DirectSound will be used as the "low-level" guts for the Windows version of OpenAL--who knows!
________________________________

Don't drink and Moderate!

[orcrist]

Did the moderator who marked this offtopic even read the thread?

Does he/she understand what an analogy is?

Does he/she even understand what the topic is?

Moderators please put more thought into moderation, instead of just jumping the gun to get rid of those moderator points. Note that the poster in question has a default score:2 so maybe (just maybe) they are not prone to offtopic comments. Meanwhile there are many score:0's on this post, some of which deserve to be 1's.

In other words:
Have you read the moderation guidelines?

Chris

Re:o no...

[Straker Skunk]

you want to talk to an api that understands things like 'here is the geometry objecttree, here are the sound objects'. And all sound properties/data are stored with these soundobjects

With respect to OpenGL, that's what you use a scene graph for (e.g. Inventor). OpenAL, like OpenGL, is intended to be a low-level (yet platform-independent) interface to the hardware. What you want is something higher-level.

Also, remember that OO is not the be-all end-all of programming approaches. OpenAL would be a lot less flexible and useful if it were implemented that way (as, say, a set of fully-OO C++ classes).

Re:This can only be good in the end

[Straker Skunk]

I read that there is an API for reading CD audio and playing it (how many more CD Players do we need :-) ?). Does OpenAL include support for mp3, MSAudio, Liquid Audio, Barry's Mega Audio, etc, or include hooks for these to be implemented, perhaps by third party software such as XMMS? Or am I getting a bit to specific...

Eep! You don't want all that junk in the API. That'd be akin to OpenGL having glSomething calls to decode GIF images, PNG's, JPG's, 3D file formats, etc.

What make the approach they're taking really nice is that the API is staying clean. They're not trying to throw everything under the sun into the library-- they're keeping its scope razor-sharp, and leaving application-specific concerns like those to other libraries.

That way, you don't run into library overlap, which is incredibly bothersome if you're trying to write elegant code. (E.g. when you're using GLib, do you go with printf(), or g_print()? I hate having to decide things like that)

Kudos to Loki for following the footsteps of one of the most beautiful API's in existence, and for committing to keep it that way. I just know I'm going to write an OpenGL+OpenAL program someday, and I'm going to enjoy it immensely }:-)

IMHO very good news.

[CodeShark]

I like this -- alot, just like I liked OpenGL when I first ran across it, even though I'm still not much of a hack when it comes to 3D graphics. (It's there if I need it, but not my bread and butter.)

That said, what I'd really like to be able to do is to drive these uber-kewl 3D sound cards from MIDI more effectively, and if I could to all of my MIDI work from Linux, that would give me the final reason I need to banish M$ software from my home machine permanently.

Is there an Open API for MIDI under Linux, and if not, would any /. readers be interested in starting one over on CodeForge?

Re:GPL and API's

[Xenu]

You might be able to copyright the names of the functions in the API. Computer manufacturers have claimed copyright on the assembly languages that they create for their systems. Assuming the copyright is valid, that doesn't stop someone from writing their own assembler, it means that you have to change the assembler's instruction mnemonics to something other than the manufacturer's mnemonics. You could do the same thing with an API, although on some operating systems there is the problem of dynamic linkers looking for ASCII strings containing function names to bind API calls.

Re:Amiga : Dead as a doornail?

[hattig]

The Amiga won't ever pop back as a consumer machine, not for a while at least, although the next Amiga OS already has ports of Quake ]|[ and Unreal Tournament (according to UK Amiga magazine AmigaActive anyway). Hopefully there will be a good system around soon, and there is a lot of interesting technology involved.

Then there are lots of next-gen AmigaOS replacements occurring, some of them are actually making headway now, such as AROS. Other interesting ideas include trying to get the Linux Mac emulator (than runs on Linuxed Macs) to run on PPC enabled Amigas... That would be fun. Amigas have a wealth of OS's available to them, OpenBSD is the latest, others include Linux, NetBSD, QNX (well, it must run on the hardware, but it won't be released for a while I am sure), AmigaOS (never!) and probably a lot more.

Interestingly, the next-gen Amiga OS was going to be called Aqua - until Apple released their new UI. The Amiga has had a pretty rough year, even by the Amigas standards! Hoefully Tao will improve the fortunes, and maybe they should take a gander at OpenAL as their sound system. Sony also have relationships with Tao...

Re:This can only be good in the end

[hattig]

Good, the best way to advance is to take the best from all of the competitors, or to even encompass them all... and being more modern you can leave out the older parts that are not relevant anymore.

I read that there is an API for reading CD audio and playing it (how many more CD Players do we need :-) ?). Does OpenAL include support for mp3, MSAudio, Liquid Audio, Barry's Mega Audio, etc, or include hooks for these to be implemented, perhaps by third party software such as XMMS? Or am I getting a bit to specific...

Dolby AC3 support would be nice as well... I suppose I should take a gander at the API!

OpenAL and the uses of 3D sound.

[be-fan]

For all of you who are complaining that 3D sound has no uses aside from games; well, yea, whats your point? It is meant for games. Unlike 3D graphics, there really isn't very many uses for 3D sound, even in media fields. Even 3D audio movies/videos will probably be using dolby or something. But by that arguement, theres no use for a $300 pair of speakers hooked up to your computer either. But what if you just like sound? There is more to using computers than programming. Believe it or not, gamers aren't lazy bastards who won't do real work. Computer gaming in enjoyable, and the 3D sound sounds really nifty! If everything were about practicality, people would all be using FVWM at home. But most people don't because most people have some sense of asthetics.

Re:OpenX, SDL and OpenAL

[be-fan]

Are you crazy! Hasn't GLX caused enough trouble already! Shouldn't X be allowed to die and not have added features that keep people chained to it? And what about OSs that don't use X. You do realize that some OSs have gotten out of the '80s, keeping OpenAL tied only to X based OSs would be a BadThing(TM) Plus it adds another layer of abstraction to the API. Can't you UNIX people do anything directly without defining performance robbing features that 5% of the population ever uses? On a side note, if Linux is all about choice and freedom, then why is it that everytime sombody says something bad about the abomination that is X, people get mad? And why is it the only windowing system widely available on Linux?

Re:Is OpenSource about replacing superior solution

[be-fan]

Why would you put it on top? The API could just directly work with the hardware. If COM were implemented on BeOS, even though Be uses an OO API, DirectX would still convievable work.

OpenGL API style.

[be-fan]

There are a couple of people bitching about how OpenAL uses the OpenGL API style and not an OO API. Then the dumbasses on the other side retailiate by condemming everything that is OOP. Neither are right. OpenGL is a pretty beautiful API. Though it is C style to the extreme (even structs are rare) it ranks right up their the Be's API which is C++ (but not a multiply inherited extreme.) Use the right tool for the right job people. Low level libraries like OpenGL are more or less fine as procedural APIs. Ideally, they would be encapsulated into an object to make contexts easier to manage and choose, but thats about it. Making the whole over-riding the virtual function may work for an OS, but really isn't necessary for a low level API. You see stuff like GTK and Win32 and X be really clumsy because the stuff that they do really begs for an OO API. Then you see some stuff and you wonder what they developer was thinking when they made it OO. The main reason, though, that OpenAL is the style of OpenGL is because of integration. Its simply more elegant to have graphics, sound, etc. APIs have the same type of interface.

Re:GPL and API's

[Cuthalion]

can an API be GPL'd the same way that code is?

You mean to say that if someone changes it they must release source code to the changes?

The GPL does not make sense for this kind of thing. It is a license that was specifically written to apply to computer programmes, and while its concepts may be generalizable beyond that, the GPL is legally worded to address specific issues of distribution of programmes and their source code.

M-x less-pedantic-mode

You mean can an "open" license be applies to this API? What would that do? An implementation of this API is already LGPL'd, so you CAN go ahead and extend or modify the API if you like..

Re:Unfortunately

[Cuthalion]

I would have prefered that all Linux developer got to define a standard with everyone, but one established developer prefer to be alone on the spotlight.

That's now how open source innovation typically works. The way new stuff usually happens is somebody wants a programme* to exist and implements it first, rather than spending 8 months saying "Hey, I want everyone in the world to tell me how to write the programme I want to use".. Once they have it doing something, they say "Hey, this is cool, anyone want to contribute?" and then the ball gets rolling.

*Libraries, protocols, API's, etcetera all count too.

GPL and API's

[gonar]

can an API be GPL'd the same way that code is? that is to say, if I were to develop an API, called OpenXXX with a certain package of functions, could I GPL the API so that anyone who wants to can implement the underneath any way they want, but any development or extension to the API must also be GPL?

what I'm thinking about is M$ standard "embrace, extend, destroy" model for implementing standard APIs.

Re:GPL and API's

[kwsNI]

Didn't Ron Jeremy already develop OpenXXX?

Seriously though, why couldn't you GPL an API? If you write it, you can liscense it however you want. If you want to open source it, I'd say go for it.

kwsNI

Re:This can only be good in the end

[slashdot-terminal]

This is a good move by Loki and Creative, although Creatives involvement might put off other audio companies from wanting to use it - I bet the API is particularly suited towards Creative chipsets.


Well duh if you ran a company and you were working on a standard wouldn't you create one that your programmers and hardware technicians actually knew how to use?

Anyway, Open Audio Library will signal the beginning of a true cross platform 3D audio system. Hopefully it provides more functionality than Microsofts proprietary single platfrom DirectAudio(?) system, otherwise it will be hard
to get companies to switch over.

I don't see the benefit of doing something like that when you can just have standard sound from multiple speakers. Just take one speaker and put in on one side of the room and another and the other then you have sterophonic sound. Largely unless the sounds are intensely more complex your mind will associate the sound comming from different sources and allow for the "3d" effect.

John Carmack should love this, him being a fan of cross-platform APIs and OpenGL etc.


I think that making anything a standard that involves massive cpu computations or involves games in general would be a bad idea. Imagine if the standards for C++ were designed by a group of PC game peddlers I really don't think your would like that very much.

Apples audio libraries probably aren't available for Linux, only Macs and Windows at the moment, and I don't know much about the Mac Sprockets or whatever they are called libraries, but I thought I should mention them so that it
didn't look like I only thought that DirectAudio was the only competitor.

I thought that there were already various libraries and systems to support ear poping sound on linux someting called ALSA or the like but I wouldn't know because my computer never has been able to say a word to me (I think it's mute)

Now to wait the three years for the Amigas Audio system, AHI, to support this :-)

To my understanding this company was about as dead as a coffin nail (according to the Dickens phrase). So why do people persist in talking about them?

Re:Unfortunately

[slashdot-terminal]

It could have been fun, if it could have been open to ALL Linux developers.

I think that using Loki's API isn't going to make your program less useful or able to compete with say a game produced by Loki. People have games that are compiled for win32 and most likely use Visual C++ does that mean that Microsoft is winning in the game market? Hell no.

Instead Loki president attitude was near to go away and make your own things.

I assume you meant the possesive form of opinion attributed to Loki in that case you would use Loki's but that's for another day. It's really hard to interpret that statement.

I don't see them stopping you from using their API they will not break your fingers.

While everyone is on party of this big announcement, we are forced to choose between:

- Implement yet another 3d sound library
- Follow Loki path, and hope to survive in the shadow of Loki
- "Gold old stereo is enough!!!"
- License a proprietary Windows library like Miles Sound System

I also assume you meant to say Loki's in the second point.

Also what is a Gold stero. Most of mine are usually grey or tan.

You could also use an already existing API for 3d sound if that's your cup of tea and make it better if you can't use it. I most likely don't have the technical expertice to code my own 3d sound API so I would probably use Loki's.

Re:Unfortunately

[WhyteRabbyt]

It could have been fun, if it could have been open to ALL Linux developers. Instead Loki president attitude was near to go away and make your own things.

Fun had nothing to do with it. Loki had a problem so they built a solution. They built an opensolution. Thats a good thing. They built a cross-platform solution. That was better still.

I would have prefered that all Linux developer got to define a standard with everyone, but one established developer prefer to be alone on the spotlight.

Did you read the interview? OpenAL was a stalled project. Loki took it up because no-one tried to get any further with developing it.

Would you be telling ESR that you would have preferred 'that all Linux developer got to define a standard with everyone' for Fetchmail because you didnt like 'one established developer prefer to be alone on the spotlight'

You have an itch, you scratch it. Thats the point.

Show me the bandwidth

[Sax Maniac]

Does anyone know if OpenAL's reference implementation will support a GLX-like network protocol? Or will it cheat and assume the app is running on the local machine? The information on the website seems real thin.

If they go the protocol route, will it be an X server extension, or some custom daemon?

I want to have my cake and eat it too- hardware acceleration *and* run over the network. Witness running GL apps over the net to a non-GLX server. Barf, transmitting pixels on the wire.

Unfortunately, the current crop of hardware-accelerated drivers cross-network is fairly difficult to install. It took me a long time get get a TNT, running GLX on Linux. (hint: nVidia's instructions don't work- goto Mesa3d.org and use those). Until this gets resolved, I really can't see any Linux games reaching end-users.

I still dont trust creative

[evilned]

Creative labs sued Aureal last year over sound PCI sound technology, in an attempt to keep aureal from continuing to make their chips for pci sound. Well they lost, and damned near had the patent overturned when it was shown that all of the prior technology leading to the patent had not been documented in the patent application, and that several of the parts of the implentation were not present in aureal's technology. The lawsuit was one of those, "we patent what is being done, not how to do it" sort of things that normally brings huge numbers of posts on slashdot, saying how evil this corporation is.

With that in mind, Creative has been good about keeping their EAX for windows fairly open, and they opened their sound drivers for linux, while Aureal still has only partially opened their code. Open code or not, looking at the API specs for OpenAL, its pretty obvious that this is oriented towards the SB Live cards. It looks to implement the same sort of setup as EAX, depending on a reverb engine, as opposed to the wavetracing setup that A3D uses. If you want to hear the difference between the two setups, play Half-Life on a EAX card and then try it on an A3D card. Its a huge difference. The A3D style, is much better IMHO. The positional audio sounds much more realistic. Still A3D 2.0 and higher (1.0 doesn't support wavetracing) isn't open, and no linux equivalent exists. Creative beat them to the punch on this one, and even opened it up. Still, dont be deluded into thinking that they are doing this for the good of the community, it is at least as much to crush aureal, as it is to improve 3d sound in Linux.

Re:This is the second library called OpenAL

[MichaelKVance]

Yes, there was a previous API, but it never really got past a header/specification. We took up the name and worked with some of the original people behind the first two iterations.

m.

This can only be good in the end

[hattig]

This is a good move by Loki and Creative, although Creatives involvement might put off other audio companies from wanting to use it - I bet the API is particularly suited towards Creative chipsets.

Anyway, Open Audio Library will signal the beginning of a true cross platform 3D audio system. Hopefully it provides more functionality than Microsofts proprietary single platfrom DirectAudio(?) system, otherwise it will be hard to get companies to switch over.

John Carmack should love this, him being a fan of cross-platform APIs and OpenGL etc.

Apples audio libraries probably aren't available for Linux, only Macs and Windows at the moment, and I don't know much about the Mac Sprockets or whatever they are called libraries, but I thought I should mention them so that it didn't look like I only thought that DirectAudio was the only competitor.

Now to wait the three years for the Amigas Audio system, AHI, to support this :-)

Re:This can only be good in the end

[tjwhaynes]

This is a good move by Loki and Creative, although Creatives involvement might put off other audio companies from wanting to use it - I bet the API is particularly suited towards Creative chipsets. A 3D Open API at this early stage should be something almost any company should be looking hard at. If at the moment it has features that favour Creative, then it is up to Aureal to get in there, do some spade work and add and help form the API to be more balanced. From the sounds of it, the audio geometry processing that A3D 2.0 does is under consideration by the OpenAL team, so if Aureal sees this as a worthwhile opportunity (and I think they should) they should contribute. Like the argument over open/closed source drivers, these big audio card companies make their money from the hardware - getting widespread acceptance of that hardware by making sure that it is widely usable is essential, and OpenAL can only help in getting these cards working in more environments on more platforms. But it does require the companies to seize the moment and help build the API.

Cheers,

Toby Haynes

GPLed

[javilon]

The specification is LGPLed. This should reassure other card vendors.

Also, it is quite telling that they whent for LGPL straight away.

It is probably the best way to create a "de facto standard" if you are not one of the big 5 or 6 software powerhouses. It is much better than waiting for a standards body to go through a formal process that would take years.

It would be great if now the OS comunity has enough power to start setting up the first draft for future standards, instead of the big bad gorillas!

All output, no input

[Animats]

Although the OpenAL logo is a microphone, the package doesn't offer any input support; it's all output. Maybe the logo should be a speaker.

Useful input-side tools are mixers, noise reduction, conference bridges with adaptive echo cancellation, and such. Those are tools you need for high-quality voice over IP. Anybody doing that?

Loki raises the bar again

[Skyshadow]

IMHO, out of all the commercial Linux-product (as opposed to distro maker) companies out there, Loki is probably doing the most to promote the standards of OSS.

Think about it: How many companies jump onto the Linux bandwagon and just toss out a couple of closed-source programs? How much easier would it be for Loki not to release their stuff?

In short, thanks, Loki.

----

A first look

[mav[LAG]]

Nice looking library with lots of potential. It's about a 500k download and compiles out of the box on my RH 6.0 installation. There's no INSTALL and the configure scripts are lurking in the OS-specific directories but they work fine. Make and make test work fine - make install doesn't but I haven't checked why. All the test programs run like a charm on this SB Live! Value and some of them are pretty damn impressive.
From the ./docs/specification.html file:

OpenAL includes several separate sub-libraries:

• AL - core audio library services, including specifying listener orientation; environment geometry and material characteristics; sample data; and source orientation, radiation, and other characteristics.
• ALU - a utility library for AL which provides functionality for doing sample conversion, preset material properties, and a compatability layer for doing simple stereo audio from within AL's 3D spatial framework.
• ALC - a platform specific library for managing OpenAL contexts, including resource sharing, locking, and unlocking. This includes, but is not limited to, ALC/Linux and ALC/Windows.
• ALUT - a cross-platform library for creating an OpenAL context, with support for simple file loading. It also provides a simple API for accessing CD audio.

  It looks like the developers have thought carefully about the spec and managed to combine a clean API with lots of flexibility. Environments can be defined in terms of geometry and materials and "listeners" can have position, velocity and orientation, leading to all sorts of cool stuff like doppler effects and sound radiosity. And yes, if you know OpenGL it takes about ten minutes to get your head around OpenAL.
  Great job Loki.