search

kcat / alure

Alure is a utility library for OpenAL, providing a C++ API and managing common tasks that include file loading, caching, and streaming
zlib License
70 stars 20 forks source link

Please add 3D sound example #35

Closed McSinyx closed 4 years ago

McSinyx commented 4 years ago

The HRTF example currently only create the context with support for HRTF, but does not show how to use 3D sound features. Seemingly after setting 3D spatialize to On, setting position and orientation seems to have some effect, but I can't feel the audio coming from that direction (position is set to be negative of at orientation). Could you please give an example on how to use this feature?

I am so sorry to bother you about this during holiday seasons.

McSinyx commented 4 years ago

Gentle ping: I've tried setting source relative and using listener instead. Neither of them worked.

kcat commented 4 years ago

Sorry for the delay. I added a simple alure-play3d example which plays a sound while rotating it around the world origin (the default listener position). If you meed more clarification about it, feel free to ask.

McSinyx commented 4 years ago

I realized the problem was on my side (3D spatialize incorrectly set, see https://github.com/McSinyx/palace/commit/5ec6aa5edeefb6cece3bd985561a9de2b1a0479f) and fixed the problem. I'm still wondering tho, why does the 3D example does not need to specify HRTF attributes for context creation? What really requires this and what is the default value of it (and how can I find that out for other ones)?

Moreover, a bit off-topic, what constants need I expose if I want to cover all alure's functionalities? I've seen constants defined in al, alc and alure's header used.

kcat commented 4 years ago

I'm still wondering tho, why does the 3D example does not need to specify HRTF attributes for context creation? What really requires this and what is the default value of it (and how can I find that out for other ones)?

The HRTF attributes are to override the auto-detection. If OpenAL Soft is able to tell that the device is headphones (which depends on the system and backend, and the user configuration), it will automatically enable HRTF, otherwise it'll be left off. The attributes let the app override this, generally by providing an option to the user, to attempt to force it on or off regardless of whether headphones were detected or not.

Moreover, a bit off-topic, what constants need I expose if I want to cover all alure's functionalities? I've seen constants defined in al, alc and alure's header used.

The stuff in AL/alure2*.h and the context creation attributes (both standard and supported extensions) should be all you need. I can't think of anything else off the top of my head, anyway.

McSinyx commented 4 years ago

Thank you, I think I got it now. BTW, how do you manage to keep bugs away, since I don't see any logic test (Travis only seems to try to compile) for either OpenAL Soft or Alure. Both has a lot of users so you could probably rely on downstream reported bug?