Slashdot Mirror
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.
Make no mistake, this is an awesome development and I congratulate Loki on taking the initiative. I'm truly grateful.
I only have one nit to pick and it's with Slashdot. Just because the software is LGPL'ed doesn't mean it should be grouped on the GNU section and icon! That's preposterous. I believe that a much better section would have been any of: games, audio, music,...
Loki isn't releasing this library out of altruism, it's supposed to be free advertising. Once this API becomes really popular, the name 'Loki' will appear on every shrink-wrapped commercial game in the world ("this game requires OpenAL from Loki Entertainment").
Watch out.
I am glad, being the founder of OpenDK to see others spreading the word. We also have a new project: AudioDK. This hopes to be the cutting edge in AI sound.
Thank you.
the origonal OpenDK guy
" 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. " You have the last few years of the existance of Linux for you to propose your own 3d sound library and did nothing. Now Loki takes the intiative and is trying to come up with something and you comdemm them?
Ann Landers?
AudioDK with the added bonus of having the most enlightening information.
Thank you.
The Moderator is Called to duty, and he will not shirk.
He steps delicately down from Olympus, into the noisy anarchy of Slashdot.
Diligent, wise, and fair, he reads the posts.
What's this? Linux is faster and more stable than all other operating systems. Yes, that's true. A very Insightful post.
Here's a sad case. Oh, the poor lad. He says this story was posted yesterday, but somebody said that just last month about a different story. How Redundant.
Oh, and this one has a link to the Jargon File! That's clever -- who would have thought of it? Informative indeed!
Hmmm, this one claims that some people don't agree with Richard Stallman -- and that they may even be right! How absurd. Nobody could take this nonsense seriously. It's a Troll, alright.
Ahh, here's a thoughtful one. This guy says that the Contitution was written because the Articles of Confederation were too centralized, and he goes on to point out that Asians can't drive. Then he casually mentions that Microsoft created the Internet, income tax is theft, President Clinton personally murdered 80,000,000 million people in the 20th century alone, women are geneticaly incapable of learning to read or holding a job, and the Feminists have armed themselves with nuclear weapons in their quest to annihilate all life on Earth. Now, obviously some of those views are a bit extreme, but it's just not fair to penalize people for holding unpopular opinions! And besides, he's got a point there about those Feminists. Always knew they must be up to something. It's good to see somebody using his head after all these trolls. Insightful!
The Moderator's labors are complete. Slashdot is safe for another day. He retires to his cold and windy mountaintop to await the Call.
...and where your bed sleeps
and where your house lives
and I can call your phone just like that
The Advanced Linux Sound Architecture project is being developed in the Linux operating system and is released under version 2 of the GPL (GNU
general public license) and the LGPL (GNU library general public license).
Primary goals:
1.Create a fully modularized sound driver which supports kerneld and kmod.
2.Create the ALSA Kernel API which surpasses the current OSS API.
3.Maintain compatibility with most OSS/Lite binaries.
4.Create the ALSA Library (C, C++), which simplifies ALSA application development.
5.Create the ALSA Manager, an interactive configuration program for the driver.
It supports 3D audio from the kernel level.
http://www.alsa-project.org/
The Sun/MS/Java issue is as much a licensing/contract issue as anything.
While Wine reimplements Win32, it does not ADD TO IT. BIG difference between this, and what Microsoft did by "enhancing" Java.
Which is sort of the rub about many Microsoft APIs. They tend to work best with Microsoft stuff (like ADO/OleDB working best with MS SQL Server & MS Access, and not so well with Oracle).
When has Microsoft sued anyone to protect the "purity" of Win32? You talk crap.
Sun, on the other hand, could sue MS because Microsoft was using code and trademarks licenced from them. Microsoft still can, and probably will, come up with a clean-room Java implementation.
Why?
Reason #1 is security, plain and simple.
The OpenDK project could massively affect our current ideas and models of computer security. In a few years, for better or for worse, there will be a revolution in computer security, and success or failure of the OpenDK project will partially determine whether this is for the good of the crackers or for the monolithic megacorporations.
OpenGL has ALWAYS supported geometry acceleration. Crappy D3D didn't until v8 recently. OpenGL is superior in extensibility and features, you MS fudgepacking troll.
You sir, are an ignorant moron. EAX is simply an extension to the windows-specific MS DirectSound API and can therefore not be ported without DirectSound and DirectX. You spout off on all possible subjects without actually knowing what you're talking about. I'd fire you if I were your boss.
If something is licensed, it is proprietary. Actually, if something is patented, copyrighted, trademarked, or a trade secret, then it is proprietary. Something is proprietary if someone has been granted (by law) some kind of ownership rights for it. Someone has the right to control its use.
I know it feels good to think that your open software is non-proprietary, but it is not, so please stop saying it is. The people that have gotten letters from the Free Software Foundation's lawyers know that "Free Software" is proprietary. It's about time the rest of you know it and act like you know it.
The opposite of open source is closed source. The opposite of free is non-free. The opposite of proprietary is public domain. It's easy to use these terms correctly; please try.
So let me get this straight. When MS uses the legal system to protect the purity of their interface, that's a Bad Thing.
But when Sun does it (e.g., Java), it's a Good Thing?
only a slashdot moderator could have missed the irony of that
stupidity wins again!
t.
Why the incensed defenses of X?
Because next to the alternatives, especially the predominant ones, it's really not THAT bad...
Remember: I know where you live.
Wow! This sounds nice! Hear, hear...
Ugh him funny give all points to him so funny
Hmmn.. You could put this comment on every article and itd prolly apply.. but *WHY*? *sighs* Its not like this really has a place here. Just trolling for no good reason? Yeah.. this is a troll looking for a certain reaction. You got it. *rolls his eyes*
From what I've read, there isn't any intention of having OpenAL run anywhere but locally at this point. In any case, I don't really see the point of supporting that -- what kind of application would benifit substantially from sending raw 3D audio over a network?
GL:'glut' SL:'slut' we can't have that, now can we?
Just like you can have a software implementation of OpenGL (which could be written on top of DirectX), it seems that OpenAL will be able to run on any sound card, even if it doesn't have 3D sound support. If the software-only version is written on top of any existing sound card.
Obviously, to be really useful, the authors will have to at some point implement hardware specific drivers, which wouldn't use DirectSound at all.
Uh right.
Lets just ignore your very biased and unfounded 'and it is crap'.
Now I would very much like you to explain why OpenGL would be more suited for general-purpose work? The only thing I can think of is the _driver_ (not API) support for all sorts of line features.
Apart from that, DX provides a much cleaner and much more direct path to the latest hardware features, mainly geometry acceleration. In general MS is just very good in working with both the proffesional software developers and the hardware manufacturers in providing the best API possible.
(I'm sure I'll be considered a troll for this, but having worked with D3D for years now, and having been in meeting with MS about it as well, I really do feel this is true.)
Ok. Great.
So the windows world has been seeing EAX and A3D for quitte a while now. It is being used by a lot of developers to provide high quality 3D sound. The API specs are available to anyone. And Creative could just as well implement this on Linux?
Now WHY do we need a totally new API? Because it's hip to use the totally outdated gl style syntax?
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.
How about sticking to some standards people? Instead of creating a new primitive thing, and sticking Open in front of it to make the whole OpenSource community love it.
Folks, I'm sorry. I WISH that OpenGL was the be-all and end-all of Graphics Libraries. And perhaps technically, it is. But from where I sit, Microsoft's (ugh) recent statement that "the only things that use OpenGL are the Quake engine-based games" (or words to that effect) seems pretty durn close to true. This hits me as one of the big reasons that more stuff doesn't get ported to Linux (gamewise); they all use Direct3d. Even high-end 3d apps support both Direct3d and OpenGL.
HAHAHAHAHAHAHAHA!!!! No, seriously, I really think that developments like this are the coolest! I also like to see the involvement of Creative. I love it when another major company gets involved and dispels the FUD that Open Source is going nowhere.
bun-fhuinneog agam!
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.
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 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.
Mathieu Pinard
Tribsoft Inc.
The development verison of SDL has support for OpenGL and will presumably have support for OpenAL soon. So if you like, you can write everything in Open* and just use SDL as a multiplatform threading and input manager, ignoring graphics and sound.
$500 consumer hardware?!? The fastest consumer 3D hardware right now is the GeForce, which costs ~$300 in its fastest incarnation. NVIDIA was started by ex-SGIers who have a much higher regard for OpenGL than Direct3D. NVIDIA OpenGL drivers are among the best around.
Anyway. Nice to see you putting down my technical knowledge. You might be suprised by the truth. I have afterall been doing both D3D and GL (much less intensively, since I hate it) for several years. And that's in software that actually has to work on your average users machine.
I guess that's great as long as your "average user's machine" is running Windows. If its running Linux, BeOS, MacOS or any of the other up-and-coming alternative OSen you'll have a fun time porting to OpenGL which you hate so much. ;-)
The average user doesn't have the latest and greatest SGI.
Irrelevant, since you don't need an SGI to have great OpenGL performance. :-)
And about the geometry, older style hardware might be quitte happy accelerating geometry using GL. But for modern hardware in normal pricerange D3D offers a direct path to exactly what the hardware does.
Non-sequitor time. Only the most modern hardware (GeForce) provides hardware geometry support, so your statement doesn't make sense. Further all the major 3D vendors now have pretty good to excellent OpenGL implementations (NVIDIA, ATI, Matrox, S3, 3dfx).
And that is the result of carefull crafting and discussing by lots of major developers and IHVs.
Yes, with Microsoft as the ultimate judge of what actually gets included and implemented. Anyone with an eye to see realizes that Direct3D has been playing catch up with OpenGL over the last few versions. Heck, by the next version it will even include an open extension mechanism (which OpenGL has had since before Direct3D existed). No matter what Microsoft does, though, it can't fix the fundamentally crufty API, or the dependence on COM - which will leave Direct3D forever tied to Windows. Whither now, Fahrenheit? ;-)
Finally, the OpenGL ARB provides an open forum for improvements to OpenGL - one that is working well, if sometimes rather slowly. For the full scoop on OpenGL check out www.opengl.org.
BTW, I started the OpenAL effort, and I'm very glad to see it succeed after so many people's hard work!
http://opensource.creative.com
Or even:
http://www.alsa-project.org if ALSA is more your thing.
Nick
Nick
I would assume that the networking aspect would live below the core API, or at the very least you would specify this sort of thing at the context level. I've actually talked to Jim Gettys about this stuff at Linuxworld, and the ESD people. We're looking into it...
m.
"Sebastian you're in a mess. They called you King of all the Hipsters, is it true or are you still the Queen?" -- B
Every day I work with the code of developers who think that classes/interfaces are the way to go for APIs. The stuff is *horrid*. When I'm done converting a piece of Direct3D code to OpenGL, it is far and away obvious which piece of code is
a) easier for me to write
b) easier for me to maintain
c) easeir for my peers to read and understand, and thus maintain
OpenGL is a beauty of an API for several reasons, from a stricly syntactic point of view because it is data-type neutral. When I need to port Direct3D code to OpenGL, I can almost always make the data structures work the way I need them, despite the best efforts of the minds at Microsoft to introduce D3DTLVERTEX and the FVF flags (ye gods).
m.
"Sebastian you're in a mess. They called you King of all the Hipsters, is it true or are you still the Queen?" -- B
We actually looked at a bunch of audio libraries:
DirectSound*
Apple GameSprockets
QSound
BeOS Media Kit
EAX
A3D
IASIG Specifications
etc. Insofar as EAX is a set of extensions to DirectSound, I guess that doesn't count so much.
m.
"Sebastian you're in a mess. They called you King of all the Hipsters, is it true or are you still the Queen?" -- B
Actually, there is no CD API. We felt it had no place inside of a 3D spatialized audio API if we wanted to keep things clear and consistent.
Support for MP3, etc., is planned, as an optional parameter for specifying a Buffer waveform. There is an issue of canonicalization though (stereo sound doesn't make sense for noise in a three dimensional space... it's just a sound).
m.
"Sebastian you're in a mess. They called you King of all the Hipsters, is it true or are you still the Queen?" -- B
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)
Next time, read the article, OK? It was specifically said that (unlike ALSA) OpenAL would not be a part of the kernel or a module. You're saying, "Why do we need Mesa when there are already drivers for my VGA card?" OpenAL will provide functionality (3D audio) that doesn't currently exist in the sound drivers that it will sit on top of.
Causation can cause correlation
I have a dream, a dream of quake or sommat like that churning away in the foreground plinking out that sound. My audio enhanced mail program simultaneously plays a little wav to tell me that something has arrived. Off in the distance sound output of a audio tweaked top is playing away giving me some sort of feedback of the system load
Multiple sound programs working together, sniff.
And all sound routes too mind, multiple networked midi port access as well. If I recall correctly sgi had a sound library that everyone had to use to access the sound device. Microsoft now has DirectSound which does the same thing (btw: the lead developer (possibly the only one!) on DirectSound is an ex SGI employee, so DirectSound could be said to be built on the expertise and experience of SGI)
C. (spurned by XAudio, broken on the wheel of nas, crushed by lack of esd documentation, impaled on the pain tree of sound editing under linux, /dev/audio, just say no)
I sometimes write stuff
All the other networked sound methods have fallen by the wayside to my mind, the Xaudio one because the X consortium stopped work on it, nas because it had zero documentation, and against nas and esd theres the problem that there is nothing that can be done with them except play static snippets of sound.
I reckon the problem is that noone who actually knows anything about sound or serious use of sound has even investigated network sound.
If OpenAl stuff could be routed to sound daemon on a remote machine then it would appear to fit the bill perfectly. Serious sound apps using OpenAL, and OpenAl supporting a network connection.
Sigh, in a perfect world...
C.
I sometimes write stuff
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?
Most people agreed that Apple was 'dead as a coffin nail' (or whatever) a couple of years ago... then they released the iMac and sprang back to life like something out of a bad Hammer House of Horrors movie...
Now I'm not suggesting that Amiga are going to release a translucent / aqua machine (they'd get sued ;) - but perhaps there's life left in the old dog yet?
Regards,
Denny
PS, I've never used an Amiga in my life, so I know even less than usual about what I'm pontificating about :)
# Using Linux in the UK? Check out Linux UK
Police State UK - news and
Now it would be nice if a GLX-like tunnel was defined so that the destination of the sound can be determined by the display you opened with X. In fact I can see it useful to have the sound linked with an X window, so that they can have individual volume controls or be muted when iconized, without program support...
You cannot program a good OO api atop another OO api. You can program a good OO api atop a functional api, like the computer hardware, or a low-level abstraction like OpenGL. Just try it.
Trying to make the low-level portable interface "object oriented" is entirely against object orientation.
Okay, you can go back to playing with your HBRUSHES and HPENS now.
X should be replaced. But there is a tiny germ of an idea that needs to be kept. What I want is something that can tunnel over a network. This means bufferable commands. This can also greately improve performance on local machines by reducing the number of context switches. Microsoft says they need to put the graphics in the kernel because it halves the number of context switches. But a well-designed buffered command system (mostly without need for bi-directional communication that requires a sync) can reduce the number of context switches by 10,000 or more (and still leave the server in user space!).
GLX is a sample of how you can take a call-based system and lay it atop a buffered command system.
I would dearly love to see X replaced. I want antialiased and transparency everything, and it is inexcusable that I have to use a library to do even the simplest graphics!
Will there be support for rendering 3D audio in Dolby Digital and/or DTS digital output formats? I'd love to play games (and have UI effects) in real home-theatre surround.. (yes, I'd need a coax/spdif soundcard...)
Your Working Boy,
Should be OpenSL.
"audio" is to "video" as "sound" is to "graphics".
Hamish
"Wise men talk because they have something to say; fools, because they have to say something" - Plato
Damn. Too bad they didn't name it OpenSL instead...SL, SLU, and SLC are all nice names, but wouldn't it be fun to #include ;)
"What do you mean, invalid parameters? 9000Gigs of RAM and it can't answer a simple question!" -- Earthworm Jim
Whoops! Make that #include...this will teach me to preview...
"What do you mean, invalid parameters? 9000Gigs of RAM and it can't answer a simple question!" -- Earthworm Jim
Have you ever noticed that the so called "3D Sound" is in reality only 2D ?.
F.ex. if you are playing System Shock 2, there is *no way* to know if the monsters are on the steps above or below.
--
Why pay for drugs when you can get Linux for free ?
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
One interesting thing about OpenGL is that it's vendor-extendable, and it allows vendors to establish new APIs to support their various specific features. Presumably an audio analog will allow this also.
(Which brings up and interesting question about OpenGL -- how do vendor-specific additions get integrated into the standard? How are implementation disagreements handled? I assume there's some committee at SGI that handles these sorts of issues.)
--
Business. Numbers. Money. People. Computer World.
Microsoft actually takes OpenGL support fairly seriously. Without it they have no hope of competing with Sun/SGI/Linux in the 'engineering workstation' market. Cross-platform games are just a small side-effect of cross-platform engineering applications.
DirectX/Direct3D exist only to support and encourage game development on Windows, but with today's home computer market the way it is, that's where the game development would be anyway even without it. The fact that DirectX is not cross-platform is not a nefarious plot to destroy other OSes (well, maybe a goal was to destroy DOS games), it's just how Microsoft builds things.
--
Business. Numbers. Money. People. Computer World.
According to the OpenAL page they are implementing the IASIG guidelines. Aureal is a member of IASIG as is about every other audio manufaturer. Also accor ding to Jon Taylor of creative, they are planning on setting up an ARB for spec development.
Yes, wavetracing is nifty, but it is a serious CPU hit, and honestly it is not that much greater than 3D audio with EAX.
Maybe you do not trust Creative, but right now this is all we have, Aureal would be much worse frankly, they are going to release A3D for Linux, it is going to be closed, who wants that? Aureal is free to write their own OpenAL drivers for their soundcards, just as they are free to write their own EAX drivers (did they ever release these, they have been promising them for a year now).
Q.
"The company" has nothing to do with it, just as they had nothing to do with AHI. People talk about Amigas because people use Amigas, and that will probably continue to be the case until the machines die or something better comes along.
It's easier to port some things to the Amiga than it is to find something to replace the Amiga with. I am trying very hard to replace my Amiga. Last year, I bought a $3000 Mac for my brother, and also so I could scope one out a bit. I gave it a try, and decided that it just isn't the right OS for me, so I didn't buy a second one. Now I'm spending almost as much on an Athlon Linux box. I think I can move some of the Amiga's work over to that (and even do some new things with it!), but overall, it's already clear that the Amiga's place is still secure.
Oh well, maybe next year I'll be able to retire the Amiga? Frankly, I'm not holding my breath. Sometimes it seems like the whole idea of real progress in the computer industry is about as dead as the Amiga itself. And what was one of the last things that happened before the stagnation period set in? The Amiga. The personal computer revolution: 1977-1985 R.I.P. (To be fair, I'll admit that's an oversimplification which ignores NeXT (1988) and BeOS (1995). Still, it has been pretty lean pickings for the last decade and a half.)
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I will start OpenIL, but I know next to nothing of linux programming so I would need some people who wish to program for Linux.....
Anyone wishing to take part, e-mail me below!
Dan Guisinger
d.guisinger@qwlsoft.com
www.atacomm.com - The Leader in VoIP Product Distributi
I remember a previous audio library called OpenAL. Is this the same one, or is this a new one?
I'm sure this better hardware would be $5000 hardware that barely outperforms $500 consumer hardware nowadays.
Anyway. Nice to see you putting down my technical knowledge. You might be suprised by the truth. I have afterall been doing both D3D and GL (much less intensively, since I hate it) for several years. And that's in software that actually has to work on your average users machine.
The average user doesn't have the latest and greatest SGI.
And about the geometry, older style hardware might be quitte happy accelerating geometry using GL. But for modern hardware in normal pricerange D3D offers a direct path to exactly what the hardware does. And that is the result of carefull crafting and discussing by lots of major developers and IHVs.
Thanks for listening.
Oh great. I'm a troll because I think reinventing the wheel is a bad thing.
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.
Also both are not hardware specific.
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.
This is what happens all the time when doing ports between PC and various consoles.
I was thinking of more something like an NVidia Quadro, to really put on some really good competition :) I don't think NVidia was started by ex-SGIers, but there atleast are a lot of ex-SGIers working their now.
:)
MS indeed is ultimate judge about what gets implemented, but since this interaction process has started it's never really worked out in any bad way as I see it.
Geometry acceleration support is ofcourse about the API supporting it, and the hardware being on the way. Ofcourse GL supports it as well, and in it's most basic form has supported it since its existance. But the D3D methods are much more flexible. This will be even more so with DX8.
And no, there is no reason for D3D to be tied to Windows. It could be implemented on Linux. Just nobody does it. Because it wouldn't be considered very cool
Well. Just happens to be that no D3D code actually works in that way. Deal is that it's pretty rare to have geometry in your code in such a static way. It would be coming from your data files, which would contain precreated vertex and indexlists.
How do we choose an API? 1. Consumer demand. 2. features/performance 3. Ease of use to developer 4. portability. But first 3 are way more important.
And even if the code would be a clean recompile another platform, publishing it properly for another platform takes a lot of testing anyway. Testing, customer support, etcetc
And for now it indeed looks like the Windows OpenAL is just a layer ontop of DirectSound. Doesn't that basically mean you have one extra reason not to use it?
The only sortof usefull thing would be to reimplement DX on Linux. There is no reason why COM can't work on Linux. (See CrystalSpace).
I don't think you could GPL an API (although you could GPL your reference implementation). I also think you would not want this to be possible. If people or companies could restrict implementations of APIs it would not be possible in many cases to make open implementations of proprietary APIs. This would throw a serious monkey wrench in many of the efforts of the open source community.
GL geometry acceleration really couldn't get much easier:
glLoadIdentity();
glRotatef(0,1,0,rot_angle);
And that same code will run on any platform, from software-driven Pentium-100s to hardware acceleration on Onyx2 Infinite Reality racks, as quickly as the driver developers choose to optimize their drivers. I haven't worked with DX7's geometry acceleration, but from what I hear, it's considerably more obfuscated, and requires all old code to be rewritten to take advantage of it.
MS indeed is ultimate judge about what gets implemented, but since this interaction process has started it's never really worked out in any bad way as I see it.
The only problem is that Direct3D will permanently be tied down to the current hardware. OpenGL 1.1 still has features (glConvolutionFilter, glTexImage3D, etc.) that have yet to be implemented in hardware on any consumer card, and has supported geometry acceleration since its inception. Plus, if a feature isn't available in hardware, OpenGL has a guaranteed software fall-back renderer for all features in the spec - something Direct3D sorely needs. Sure, a few new features have been added to improve performance (glMultiTextureARB), but that's more a result of card manufacturers optimizing their texel units for write-only, rather than read/write. Multi-texturing can be just as easily implemented with alpha blending two images; however, when writes are 2-3x faster than reads, it's considerably more efficient to pre-alpha blend the pixel in the texel unit and write once, then to write once, read back in, and write again.
And no, there is no reason for D3D to be tied to Windows. It could be implemented on Linux. Just nobody does it. Because it wouldn't be considered very cool :)
Actually, since neither ActiveX nor the Component Object Model exist in a complete enough form for any other OS (MacOS has a partial implementation), it's easily arguable that DirectX will remain tied to Windows. Not too many operating systems have any idea what extending IUnknown is supposed to do. Hell, check the Cygnus Gnu-Win pages - it's difficult just to port the DirectX libraries to a different Win32 compiler, let alone an entirely different operating system!
What's missing before we have a full set of standardized, gaming-friendly APIs? OpenGL and OpenAL (if it lives up to its promise) provide the output, but are there analogues to the rest of DirectX (the competition)? The need for a DirectInput analogue springs immediately to mind. Does one exist?
From a developer's standpoint, these cross-platform APIs are A Good Thing but if the open platforms are limited to graphics and sound alone then Linux game dev will continue on its slow, six-months-behind-Wintel-releases course.
Smalltalk, Python, Sather, Eiffel, or a half-assed excuse for an OO language like C++?
I'd just as soon get a C API, which I can trivially wrap and call from all of the above, just like I can for OpenGL.
C is the universal solvent of software libaries. Deal with it.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I really do hope that everybody realizes that this is going to basically lead to an accelerated DirectX for open systems, except done right. It is clear that OpenAL is designed to interoperate with OpenGL, the API is very similar. (Though things need to be named alEnable instead of Enable) This smacks of DirectX. Its accelerated, integrated, low level, and fast. What more could you want? Now all thats left is to write the hardware accelerated Open2DGL (Open 2D graphics) the OpenIL (open input library) OpenSL (OpenSound library) and OpenML (Open Music/midi library.) Seriously though, these can't be far off. You have to admit, no matter how poorly implemented DirectX is , it IS a good idea. Shove the OS out of your way, directly (yet cooperativly) access hardware, and make the APIs all similar. There are a couple of things left wanting, however. There are still too many levels in between the hardware and the app. OSS on Linux should be replaced with OpenSL (OpenSound library) which would directly interface with OpenAL. All the other libraries should access hardware directly, not sit on top of native libraries. And before you say this dream API is already here in the form of SDL, SDL is nothing compared to DirectX. DirectX is basically a wrapper for hardware, offers a huge amount of control of the hardware, and takes much better advantage of acceleration.
A deep unwavering belief is a sure sign you're missing something...
Now WHY do we need a totally new API? Because it's hip to use the totally outdated gl style syntax?
Perhaps you want to be stuck with C++ indefinitely ? It's better to write a library in C because
- C has a binary standard
- C++ doesn't
So you cannot interface with C++ from the programming language of you choice, but most programming languages have the ability to interface with C. In C++ you cannot even guarantee (without CORBA/COM or some other component solution) that you can mix classes between compilers. The reason for the "outdated" syntax is to keep the namespace clean. There isn't much difference between GL::Vertex and glVertex. If you write a library in C++ you still should expose the API in plain C (handle = pointer to object).Personally I use Common Lisp and other esoteric languages (because IMHO they are better) and they can all interface with C (without ugly kludges) but interfacing with C++ would be a pain. If the interfaces were in C++ there would be a language lock-in, which I think we all want to avoid.
The way you can tell which direction a sound is coming from is by which ear hears the sound louder and which hears it first.
Actually you can tell by the way the sound is reflected from you ears, shoulders and travelling through you skull. You don't need to move to know the direction. The HRTF (head related transfer function) varies also according to the horizontal position of the sound source. It's just that the games don't implement it properly.
I get OpenGL, but why OpenAL?
(no offense meant, just curious, so hold the flames, pickles and mayo)
Want to work at Transmeta? Hedgefund.net? Priceline?
Can your IM do this?
--Have a Johsonville brat.
This is all good news. If there's something we like, it's open cross-platform APIs. It's just too bad that the Windows OpenAL will probably be supported through DirectSound instead of native drivers, as for OpenGL and Direct3D now. So you have one more reason to delete your FAT partitions and start gaming in Linux.
Expect FUD about this from your nearby Microserf.
All other PC audio companies signing up on this is good in my book and I will start buying one card a week to show my appreciation. Or maybe two. They probably deserve all my money, and somebody gotta pay when they start losing all their money supporting open standards.
Bill Gates: We cannot open the source on Windows, as people wouldn't know what they get when they buy Windows anymore.
[Aside from the obvious paradox:]
Me: Your problem is that people are beginning to realize just exactly what they really get!
- Steeltoe
http://www.debunkingskeptics.com/
Reading through the OpenAL Scratchpad I came across this point ALC/Windows are the OpenAL bindings for Win32
[RFC: a layer on top of DirectSound?
[NOTE: At first. I was wonder how this parallels OpenGL. I'm fairly sure under windows it isn't a layer on D3D.
...Is for someone to write an OpenIL (Open Input Language) to get a complete platform-independent set of gaming APIs, as the only one that now appears to be missing is grabbing user input in a consistent fashion.
Anyone want to give it a go?
Why doesn't the gene pool have a life guard?
This is good work by Loki. But why don't they or someone initiate an effort to make a DirectX equivalent API on Linux (and possibly other Unix based systems) that's self-contained, portable, fast and open source. Right now it's kind of segmented, with OpenGL -- for graphics, SDL and now OpenAL -- for sound. Are there efforts already underway to do something like this? I think it would be a good project to pursue in an effort to bring more gaming to Linux. --e!- ---
-------------------------------------------
-----------------------------------------------
Unix _is_ user friendly, it's just particular about who its friends
From what I can tell from talking to Michael Vance, the standard is as neutral as, say, OpenGL. That is to say, we're not in a position to say that OpenGL is geared more towards NVIDIA cards than towards 3dfx or ATI cards. OpenAL has been designed in the same spirit and should favor no hardware over another, in principle.
Now, if one company has hardware support for more features than another, it may seem as though the API is geared more towards the former hardware than the latter, but that's not the fault of the API.
matt
Writer, Linux Games
Curmudgeon Gamer: Not happy
3D positional audio is actually much cooler than (high performance) 3D graphics in some ways, so I can see this API quickly supplanting vendor- and platform- specific standards.
For one example, in video conferencing it is pretty well accepted that audio quality and continuity is more important than the video. If that audio were 3D positional, so that voices matched up spatially with the position of participants, you could realize a major increase in realism with a minimal bandwidth cost. As video conferencing moves toward multi-vendor, multi-platform H.323, a similiarly multi-vendor, multi-platform 3D positional audio API could be a major BUSINESS win.
Yup; as soon as companies figure out that this API is a money maker, I would expect to see it take off in a big way.
Hats off to Loki for yet another fine release.
(Hi Nix :))
I agree that the C-style focus of a NEW api today is outdated. To relate the new api to 'OpenGL'-style to illustrate how 'great' it might be, is IMHO a big mistake. OpenGL's interface is old, and born in the C world of IRIX. Today we have powerfull tools,methods, techniques and ideas how to model data plus logic in a more 'natural' way. Keeping this new API C-style, as OpenGL is, is a missed chance to do it right: an Audio API is not about just functions, so functionbased thinking is at place; it's OO for a large part. Defining it in C style is THE first big, and IMHO the deadly nail to the coffin of this unborn child, mistake of a large list to come. I can understand it's C-style because most Unix code is C-style (still), but this library is not for the past, it's for the future. The definers of the new API should have put more time into that before publishing a definition that has only slightly a chance in the C-focussed Unix world, which is narrowing every day.
And as Jurjen pointed out: there is already a set of API's doing what this should be doing. Instead of joining these forces, the wheel is re-invented again, on a windy, dusty road towards the 1.0 version, if that will be ever reached, which I doubt.
--
Never underestimate the relief of true separation of Religion and State.
This is not on topic, but let's hear it:
You post 2 examples of code no-one would use on both api's. it's useless to mention the Execution buffer and glVertex calls.
OpenGL is not a state machine. The api is in a certain state but a statemachine is something else: + = . This is not the case for OpenGL. Don't call it a state machine then. If you focus on Hardware you can declare OpenGL a good api, however OpenGL is based on the fact that it's totally hardware/windowmanager independant. Refering to hardware is therefor useless. And not right also: it's perfectly defendable to see a set of faces with materials and geometry as a set of objects. Visualizing these objects should be done using methods of these objects. OpenGL on the other hand is totally function based, C-style. Ok if you prepare yourself for a functionbased application, but horrible for applications that are Object based, like most common 3D engines (except perhaps Quake3's engine). In an OO based application you suddenly have a transformation to a functionbased api, which is, _logically speaking_, stupid.
For OpenGL the reason it's being functionbased C-style is clear, it's historical. For a _NEW_ api there are no reasons to stick with C-style functionbased designs. Just because if you have an OO based application, like a game (more and more games are OO based), 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. No crappy structs inside whatever array pointer vehicle. It makes so much sense to do it the OO way, ESPECIALLY Because more and more people are going the OO way.
I agree with you that having a cross platform api for sound would be very ok. However I HOPE you'll understand that a C-style API, which has to be born yet, has simply NO CHANCE on win32, where more and more is going to be OO/COM. So 'cross-platform' will IMHO eventually be just 'cross-Unix-platform', and it's not the fault of MS.
--
Never underestimate the relief of true separation of Religion and State.
I mentioned an example for a statemachine as currentstate + event = new state, but I used sharp brackets, so the parser skipped the 'hey these look like HTML tags' items. :) sorry.
--
Never underestimate the relief of true separation of Religion and State.
You mean that DirectSound is going to have competition? Let's see if Microsoft doesn't try to buy it or sue it.
kwsNI
Is there's so many to choose from.
That is every platform has its own sound API, so I hope this does catch on. What we really need is a port to games consoles. Ease of portability would be a great selling point.
"Assume the worst about people, and you'll generally be correct"
Sounds like a good idea dosent it.. but thinking back to when the Quake3 test was realised it sounds more and more like a bad one for a simple reson i live in Australia and i dont know what the market was like else where with OpenGL cards but the only I could find for under $300.au($180.US) was the I-740, so i bought it, then downloaded the 30 Meg test on my 28,800. After a day of trying to get it i did, and then oh no.. a 50!! meg download was needed for OpenGL. all im saying is if they bring this out, lets try and get 2 things to happen.. 1) Avaliblity on more then just top of the line cards 2) incoruage drives to be shiped with the cards suporting OPenAL.. i meen whats the point of haveing a card to suport an open standerd if no drivers are inclueded?? maybe this was jsut an intell thing.. but i doubt it
You have 5 Moderator Points!
Which Helpless Linux zealot/MS basher do you want to mod down today?
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.
> 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!
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.
http://rareformnewmedia.com/
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.
--
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.
"Sebastian you're in a mess. They called you King of all the Hipsters, is it true or are you still the Queen?" -- B
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.
"Sebastian you're in a mess. They called you King of all the Hipsters, is it true or are you still the Queen?" -- B
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.
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.
________________________________
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!
________________________________
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
San Francisco values: compassion, tolerance, respect, intelligence
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 }:-)
iSKUNK!
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?
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
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.
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!
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.
A deep unwavering belief is a sure sign you're missing something...
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.
A deep unwavering belief is a sure sign you're missing something...
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.
A deep unwavering belief is a sure sign you're missing something...
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..
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
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.
The difference between Theory and Practice is greater in Practice than in Theory.
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?
Slashdot social engineering at it's finest
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 can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
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.
"My head hurts, My feet stink, and I dont love Jesus." -Jimmy Buffett
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 :-)
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!
When his defense asked, "Which computer has Jon Johansen trespassed upon?" the answer was: "His own."
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?
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.
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
From the
OpenAL includes several separate sub-libraries:
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.
--- Hot Shot City is particularly good.