Announcement

Collapse
No announcement yet.

OpenSK Hopes To Be The Vulkan Of Audio/Multimedia

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • c117152
    replied
    Originally posted by Ancurio View Post
    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.
    "3.5.2. Velocity Dependent Doppler Effect" Is an explicit one. There's a lot of frequency and amplitude operations that could be generalized but were wrapped around to suit Creative hardware. Those are a bit more subtle and need some background in sound engineering to spot.

    Originally posted by Ancurio View Post
    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.
    OpenGL represents the hardware of it's age. It wasn't intentionally poorly abstracted in malice like DirectX or OpenAL. And over time, they've corrected and re-fractured the problem spots as they surfaced with varying degrees of success.
    However, old APIs are old APIs and lately they've failed to keep up with the hardware. It started with GPGPU like CUDA and OpenCL that just couldn't be contained under OpenGL. Then the embedded people didn't want to support decades old instructions so they asked for EGL Finally stuff like the Xeon Phi came out... So. the Khronos concluded it's time to clean house came up with Vulkan.
    Is OpenGL bad? No. It's simply outdated for many use-cases. In the graphics sphere, it could even be said that 99% of programmers will never use the Vulkan capabilities to optimize their code. But for commercial game engine developers, emulators, compute and so on... The Vulkan features matter.

    Leave a comment:


  • Ancurio
    replied
    Originally posted by c117152 View Post

    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.

    Leave a comment:


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

    Leave a comment:


  • c117152
    replied
    Originally posted by Ancurio View Post

    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.

    Leave a comment:


  • Ancurio
    replied
    Originally posted by starshipeleven View Post
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Ancurio View Post
    * 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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Ancurio View Post
    What is OpenAL lacking?
    Open source. (as it is now a closed project)

    Leave a comment:


  • droidhacker
    replied
    Originally posted by [email protected] View Post
    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."

    Leave a comment:


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

    Leave a comment:


  • Ancurio
    replied
    Originally posted by c117152 View Post

    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.

    Leave a comment:

Working...
X