Need alcGetCurrentContext() and alcGetContextsDevice() for library I'm writing.

[sunnystormy]

Hello!

I need those two methods in order to properly implement the destructor for my Rust library. Is there a way that they can be added, please?

Thank you!

[jpernst]

The raw alc functions are exposed by the lib in the ffi module and should be usable. I'm not sure how to expose them safely, since doing so would violate the API's invariants.

[sunnystormy]

I'm trying to use those methods, but am getting type issues because of the *const. Writing a method like

alc::ffi::alcCloseDevice(alc::ffi::alcGetContextsDevice(alc::ffi::alcGetCurrentContext()));

Still leads to the device not getting closed when the class goes out of scope.

[jpernst]

According to the openal reference, a device cannot be closed until all contexts/buffers associated with the device have first been destroyed.

[sunnystormy]

Yup. Another issue I'm having is the ability to copy references of buffers and sources into instances of my class. Otherwise, I'm going to have to generate them on the spot, which can be kind of tedious. Is there a way you can implement those traits?

[jpernst]

If you need to share a buffer among several classes I'd recommend just putting it in an Arc. Buffers and sources have internal state that would be tricky to copy.

[sunnystormy]

I'm sorry, what I meant was having a member variable inside of my class that has a copy of the buffer. For some reason, whenever I try to do this, Rust complains. The last thing I want to do is have to recreate contexts/buffers whenever I want to alter the state of my audio (pause, play, stop). One of the things I want to make sure I'm able to do with my library is have sound that can home-in on a player's location (like a missile, or cannonball). Without some kind of permanence of the data, it will be difficult to constantly reference it if I'm updating the coordinates of the source.

[jpernst]

I still don't quite understand what you're trying to do; I'd need a specific code example.

[sunnystormy]

I'll provide that sometime tomorrow. It's late here, but will be happy to share it with you once I've gotten some rest. :)

[sunnystormy]

Opened a repo here. Please take a look at the lib and give me your thoughts. As I said before, the buffer/source isn't remaining in memory to do what I need it to.

[jpernst]

Ok, I see what's wrong now. Unfortuantely, I'm not sure it can be easily fixed without redesigning openal-rs completely. I inherited this crate from the original author before rust 1.0 even came out, but my interest was only ever really in the raw FFI bindings, not the high-level wrapper which I never even used. I'd recommend just skipping the high-level parts and using the raw FFI bindings directly for everything.

If anyone is interested in redesigning the high-level API I'd be happy to transfer the crate to them, but overall interest in open-al has been very low.

[sunnystormy]

Good call! I based this code on a C++ framework I wrote with the same name. Inside of that codebase, I'm using the native methods provided. Switching to the FFI bindings will make the code consistent. Thanks again for your help!

[jpernst]

I've just pushed an update that corrects some of the const/mut pointer signatures in alc functions, that should hopefully help a little. I've also deleted the high-level API completely since it's unsound.