If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

OpenAL

Why is khronos reinventing the wheel here? The OpenAL library already exists, is widely adopted, is royalty-free, and has the same GL-style API and extension mechanism as OpenGL. What need does OpenSLES fill that OpenAL doesn't?

Re: OpenAL

Well, you would have to talk to the Khronos members individually to get their rationale, but note that Creative is very much in the loop on this. In a general sense I'd say that folks want to see a stripped-down API targeting embedded devices, and to bring lots of IHVs into the spec process to make sure the result is well-suited to the hardware people will actually be shipping on those devices.

First of all I'd just like to confirm that Creative is still actively supporting OpenAL --- it is a very important to us on the PC and we'll be continuing to work on OpenAL for a long time.

OpenSL ES is aimed at embedded market, primarily the mobile phone market, that has different demands from its desktop cousins. As Jon says, OpenSL ES will be a cut-down API targetted specifically for embedded devices, but it will also be standardizing access to functionality that is more important on these devices.

So why not OpenAL ES and bolster support for the existing API? Who was it that said "the great thing about standards is that there is so many of them".

I like seeing a company like Khronos actively collaborating with hardware developers and the community to create decent API's, but quite frankly, their taking on too much at once. In the good old days it was OpenGL ES and then came OpenML, which was good too. When OpenVG and OpenMAX came around I thought it might be getting a little heavy. It was clear that OpenML was now on the backburner, and this was confirmed when it's Sourceforge release date was delayed by two months. And now they're taking on more projects of some questionable value.

Come one guys, concentrate on doing one thing really well before trying to do a bunch of things half assed.

Frag The Planet my website and second homeBinaural a 3D audio library using the OpenAL API and OpenML digital media

And while we're on this topic I want to know what the demand for 3D audio is in mobile "embedded" devices. Last I checked cell phones and palm pilots had nothing like stereo panning, let alone the kind of audio out that fully integrates a 3D environment. Gaming on mobile devices is a limited market altogether.

Frag The Planet my website and second homeBinaural a 3D audio library using the OpenAL API and OpenML digital media

So why not OpenAL ES and bolster support for the existing API? Who was it that said "the great thing about standards is that there is so many of them".

I like seeing a company like Khronos actively collaborating with hardware developers and the community to create decent API's, but quite frankly, their taking on too much at once. In the good old days it was OpenGL ES and then came OpenML, which was good too. When OpenVG and OpenMAX came around I thought it might be getting a little heavy. It was clear that OpenML was now on the backburner, and this was confirmed when it's Sourceforge release date was delayed by two months. And now they're taking on more projects of some questionable value.

Come one guys, concentrate on doing one thing really well before trying to do a bunch of things half assed.

Ridiculously late response, I know, but... Khronos is not a fixed set of people and companies. In fact in general there isn't a lot of overlap between the different API Working Groups, and when Khronos agrees to create a new Working Group, that tends to draw new people into the process. For example, when the OpenGL ARB merged into Khronos last fall, only a few of the ARB participants had been involved in other Khronos activities. It is not exactly a zero-sum game, at the same time we don't have unlimited manpower, so have to try and make good decisions about what to pursue.

It's true that OpenML has fallen by the wayside. That was not because the people in the OpenML Working Group abandoned it for other Khronos projects, but because OpenML did not achieve wide adoption in the industry or demand by developers. Unfortunately we can't predict whether or not an API will become successful, we can only make our best collective guess as to what the market will need, and proceed with it or not on that basis. BTW, OpenML was actually Khronos' first API - OpenGL ES came later.

It's true that OpenML has fallen by the wayside. That was not because the people in the OpenML Working Group abandoned it for other Khronos projects, but because OpenML did not achieve wide adoption in the industry or demand by developers.

I once had to develop a live video application in an embedded environment. Of course, I wanted to use standard API to make the code portable and the component reusable. Several technologies I have found: Video for Windows, Video for Linux, DirectShow (including video acceleration DXVA), and OpenML.

I spent quite some time to find out that OpenML, although standard, is not ready for development. So I have settled on DirectShow, developing a non-portable video application. And, because of some quality problems and integration/time issues, I have used Direct3D 9 as well to render the video frames.

We are going to use OpenGL for all rendering including video rendering, but this example shows that it is difficult to secure investments if the Khronos group does not provide the whole chain of media APIs like Microsoft does with DirectX. Integration is key!

nVidia shows how to integrate DirectShow and OpenGL. This I have found out quite late in the development process, too late to change from Direct3D to OpenGL.

'OpenGL' is toutet everywhere at my workplace, and everyone expects a full solution coming including video and audio of course. I hope that someone from Khronos group is going to oversee the media API development so that developers won't need to care about Microsoft DirectX anymore. DirectShow is rather complex and has issues, so video developers were glad if they can use another API. I know of complete failures to deliver some live video with overlays functionality by using DirectShow.

For 3D sound support, OpenAL is usable in practise for games, and JACK for professional audio use. I hope that the Khronos group can adapt these APIs and work together with Creative Labs and other PC audio manufacturers (C-Media, Realtek, Terratec, RME, and so on) to come to a solid foundation.

Khronos should offer separate WGs for PC and for mobile devices, and support both equally and fully. With OpenGL, it works well, so what about audio, video, and input devices? A streaming framework is needed as well, having DirectShow on Windows and GStreamer/NAM on Linux/UNIX. What a mess!