Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix

OpenAL Audio Library Released 134

Posted by Hemos from the code-wants-to-be-free dept.
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.
This discussion has been archived. No new comments can be posted.

OpenAL Audio Library Released More

OpenAL Audio Library Released

Comments Filter:

  • Re:OpenX, SDL and OpenAL (Score:1)

    by Anonymous Coward
    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.

  • Re:There's more to 3D than games... (Score:1)

    by Anonymous Coward
    I'm sure this better hardware would be $5000 hardware that barely outperforms $500 consumer hardware nowadays.

    $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 [creative.com]
    Or even:
    http://www.alsa-project.org [alsa-project.org] if ALSA is more your thing.

    Nick
  • Does anyone still doubt that paid Microsoft trolls visit Slashdot?
  • 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.
  • I don't really see how you could say that. While we worked on the Linux software mixer and wrote a chunk of the API, the NPO actually will administer the licensing, etc. We'll just have one chair on that committee.

    I mean, come on, it's LGPL :).

    m.
  • 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.
  • 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.
  • 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.

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

  • I think I could die happy if I see networked audio in my time

    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)

  • Any plans to allow network transparency as an option for the library? It would be a wonderful opportunity to implement this now. At least allow the possibility though some mechanism to implement it, if not as a core principle of the library, at least as a possibility in a specification appendix.

    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.

  • 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 [linuxuk.co.uk]

  • Direct X is pretty split up into libraries as well. The equivalent in Linux would be to concatenate this library with Xlib and call it "libmultimedia". It does not change the interface to the functions at all.

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

  • Pardon me, but you are obviously an idiot who has never programmed a real application.

    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.

  • I think you misunderstood. X is crap, the biggest problem with Linux acceptance. It is inexcusable that no advanced graphics (like draw an rgb image) have been added in 20 years.

    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,

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

    Instead Linus Torvalds 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 operating system
    - Follow Linus path, and hope to survive in the shadow of Linus
    - "Gold old MINIX is enough!"
    - Buy a proprietary Microsoft operating like Windows 2000

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

    Aw! Diddums!

    Hamish


  • Should be OpenSL.

    "audio" is to "video" as "sound" is to "graphics".

    Hamish
  • 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 ;)

  • Whoops! Make that #include<sl/SLUT.h>...this will teach me to preview...

  • 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 ?

  • 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.)
    --
  • 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.
    --
  • 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 [iasig.org]accor ding to Jon Taylor of creative, they are planning on setting up an ARB for spec development. [creative.com]

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

  • 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?

    "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.)


    ---
  • 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
  • Yeah, but the funny part is that your ears are only pseudo-3d also. 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. From that it tries to figure out which direction the sound is from. Then you'll tilt your head a little and it can triangulate where the sound is by getting another data point. But with just one listening position, you can't really tell whether something is up or down (your ears aren't up-down symetrical, so you might be able to tell a little). So if your character is standing still, they wouldn't be able to tell whether the monsters were up or down anyway. Perhaps the characters need to bob their heads more.
  • 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.
  • 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.

    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.
  • Comment removed based on user account deletion
  • 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.

  • 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

    1. C has a binary standard
    2. 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.

  • Maybe I just don't get it, but what do we need "3D audio" for? I always notice it on boxes for crummy wintel sound cards, but I don't think I've ever actually used an application that uses it...

    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?

  • 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.
    Excuse me? You have obviously never played half life with a3d 2.0 and a good set, or even two sets, of speakers. There is a world of difference between a good 3d sound api and plain old stereo.
  • 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
  • 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?
  • 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!
    -------------------------------------------- ---
  • 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.

    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 [linuxgames.com]

  • Kinda hits you in an "of course" sort of way doesn't it? Combine the biggest supporter of Linux gaming, the most influential sound card maker, and a truly open license: put them all together and what's not to like?

    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.

  • This is such good news. I have started working on an audio editing app for manipulation 3d sound, but without an api it's been slow going. This weekend I'm gonna pick apart this api, learn it inside and out, and start coding.

    Hats off to Loki for yet another fine release.

  • Is it better this was *never* released?

  • lol No not an attack. :-) I can see why you are sort of annoyed by the situation it just did seem somewhat inflammatory. My apologies :-) (usually it *is* a troll or flame :p )

  • Okay I figured this for a flame also and everyones jumped on the flame this comment mentality but after a little thinking and a small discussion I believe he has a valid point.

    Given the circumstances and NDA's or whatever it still does not matter.

    Granted Loki did do this openly and thats a helluva a lot better than many companies would do and this qualifies as open source there is still the matter of initial design that was *very* closed.

    How would you feel if 6Months into a project yet another be all end all API comes out? What do you do? Reimplment? Redo all your sound code? Stick with what you got?

    I think everyone is a bit hasty to flame including myself. Loki IS being a bit sensational and I do agree they are not the *only* game company out there. Sure they did a lot and they were one of the first but dont get all defensive for them without at least learning both sides of the story..Thanks

    JA

  • Scuse me..? Whats stopping you from starting your own API open to everyone? Stop flaming and complaning and do somethin better.

  • Scuse me...

    Creative Labs weren't able to talk much about 3d and Linux... sound like nda.

    We also talked to another sound card company that were not able to work to much on Linux at this time.

    This was not flaming, but a way to explain our choices to be able to make a good decision.

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

    Sorry: "Good old stereo"
  • As I have written (and sorry if some beleive it is a flame), we have 4 choices, and OpenAL is one of them.

    I'm sorry if Linux users got my comment as a attack to Linux.

  • (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.

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

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

  • Cool. (Score:1)

    by kwsNI ( 133721 )
    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.
  • 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.

  • > 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 (Score:2)

    by joss ( 1346 )
    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.

  • 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.
  • 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.
  • 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.
  • 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.
  • 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 [slashdot.org]?

    Chris
  • 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).
  • 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 }:-)
  • 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?

  • 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.
  • 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 [aros.org]. 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 [tao-group.com] will improve the fortunes, and maybe they should take a gander at OpenAL as their sound system. Sony also have relationships with Tao...

  • 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!

  • 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.
  • 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?
  • 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.
  • 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.
  • 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..
  • 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.
  • 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.
  • 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?
  • 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.

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

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

  • 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 (Score:3)

    by MichaelKVance ( 1663 ) on Thursday March 09, 2000 @06:10AM (#1215284)
    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 (Score:3)

    by hattig ( 47930 ) on Thursday March 09, 2000 @04:44AM (#1215285) Journal
    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 :-)

  • GPLed (Score:3)

    by javilon ( 99157 ) on Thursday March 09, 2000 @05:00AM (#1215286) Homepage
    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!

  • Re:This can only be good in the end (Score:3)

    by tjwhaynes ( 114792 ) on Thursday March 09, 2000 @04:56AM (#1215287)

    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

  • Re:There's more to 3D than games... (Score:3)

    by PantalonesVaqueros ( 120772 ) on Thursday March 09, 2000 @06:12AM (#1215288)
    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 :)

  • All output, no input (Score:3)

    by Animats ( 122034 ) on Thursday March 09, 2000 @09:04AM (#1215289) Homepage
    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 (Score:5)

    by Skyshadow ( 508 ) on Thursday March 09, 2000 @04:44AM (#1215290) Homepage
    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 (Score:5)

    by mav[LAG] ( 31387 ) on Thursday March 09, 2000 @05:27AM (#1215291)
    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.

Slashdot Top Deals

Invest in physics -- own a piece of Dirac!

Close