OpenSK Hopes To Be The Vulkan Of Audio/Multimedia

[dimko]

It's the golang & wayland arguments: OpenAL has too many features that make the API hard and buggy to implement.

Speaking from ignorance, why you have to implement every feature? Why not just use most commonly used ones that do work?

[Ancurio]

It's the golang & wayland arguments: OpenAL has too many features that make the API hard and buggy to implement.

Can you give a specific example? And also, why would you want to implement it when there's already AL-soft out there that's been used for years?

Like OpenGL, most of ALs additional features come via extensions that are optional for an implementation. I don't think the core part of AL is hugely complex, it's just buffer juggling/transcoding and positional audio for the most part.

[Ancurio]

* I meant resampling instead of transcoding (why the hell can't I edit my posts...)

[droidhacker]

Quote: "Inside every Microsoft engineer there is a opensource enthusiast trying to get out".

Hahahahaha, that's a good one.
But misses the rest of the thought; "but then Microsoft crushes it like a bug."

[starshipeleven]

What is OpenAL lacking?

Open source. (as it is now a closed project)

[starshipeleven]

* I meant resampling instead of transcoding (why the hell can't I edit my posts...)

because vBullettin is crap and does not filter post edits. Spambots were abusing this by posting innocuous stuff then editing the post into spam.
Micheael has disabled edit button for non-Premium as a temporary measure.

[Ancurio]

Open source. (as it is now a closed project)

OpenAL is a specification. The fact that Creative Technology's implementation is proprietary isn't really relevant, especially considering 99% of usage on Linux is via AL-soft.

I was asking the original poster why they felt OpenAL didn't provide them with a good audio experience.

[c117152]

Can you give a specific example? And also, why would you want to implement it when there's already AL-soft out there that's been used for years?

Like OpenGL, most of ALs additional features come via extensions that are optional for an implementation. I don't think the core part of AL is hugely complex, it's just buffer juggling/transcoding and positional audio for the most part.

Two examples from the top of my head:
1. Creative baked-in lots of APIs for effects processing that just had no place in such a library.
2. Many of the APIs abstract around functions you'd like direct access to for optimization purposes.

The reason Creative did things this certain way is simple: Patents. (1) Creative owns a lot of effect processing patents and (2) sound engineering optimizations that can't be improved upon. Letting people have the lowest possible control over memory means programmers can implement the best algorithms without depending on the hardware to do it for them.

The same could be said for Intel's x86 ISA, nVidia's APIs and Mircosoft's DirectX (and really, every product \ language they came up with) versus their different competitors over the years. They're all designed around patents and copyrights that guarantee even an open-source implementation will struggle to preform.

[stiiixy]

Doesn't this kind of hardware access/control also, theoretically, mean better latency for audio workstations? Does simply running a RT kernel give that same kind of result?

[Ancurio]

Two examples from the top of my head:
1. Creative baked-in lots of APIs for effects processing that just had no place in such a library.
2. Many of the APIs abstract around functions you'd like direct access to for optimization purposes.

The reason Creative did things this certain way is simple: Patents. (1) Creative owns a lot of effect processing patents and (2) sound engineering optimizations that can't be improved upon. Letting people have the lowest possible control over memory means programmers can implement the best algorithms without depending on the hardware to do it for them.

The same could be said for Intel's x86 ISA, nVidia's APIs and Mircosoft's DirectX (and really, every product \ language they came up with) versus their different competitors over the years. They're all designed around patents and copyrights that guarantee even an open-source implementation will struggle to preform.

I see what you mean. Are the effects processing APIs really part of core OpenAL? The specification makes no mention of them as far as I saw.

I agree that the OpenGL's way of abstracting direct access away is a bit outdated, but it's not too bad IMO, especially since system performance these days hardly bottlenecks audio performance (latency is a whole nother topic though). Thankfully there's no binding of object names; instead the OpenGL DSA style is used for passing handles directly.