-
Notifications
You must be signed in to change notification settings - Fork 523
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Device-less buffer support? #1006
Comments
An At best, it could be made so different devices from the same driver can share buffers, at least for OpenAL Soft, but there's no reliable way to know which devices are on the same driver. You'd also still need a device and context to create/manage the buffer; when using the router, a context is necessary so it knows which driver to forward to when the app makes AL calls. |
Thanks for the answer @kcat ! As followup, can you please clarify then how In my case toggling works. But maybe works by accident, and may not work for other system with different set of drivers? And what exactly is driver in this context? Driver, like driver, or you mean openal-backend? |
It's fine as long as the devices are handled by the same driver. If the driver uses hardware acceleration for multiple hardware devices, it's responsible for ensuring audio data is copied to the new device and the internal ID mappings are updated so it's transparent to the app. For software drivers, it's not much more than simply starting up a another output stream and having that take over mixing for the context. If the output can't be moved to the specified device for whatever reason, the function will return an error and the original device will keep working as it was. Realistically, I don't expect
Basically "OpenAL Soft", "Generic Hardware", "Generic Software", "Rapture3D", etc, are different drivers. Generally each |
Based on you explanation above, will it be possible to support sharing of |
Technically it would be possible, though it would increase the amount of lock contention when using multiple devices simultaneously. Currently two |
That's more than fine, I think, assuming that extra locking happens only when buffer-sharing is in use. |
From my understanding of OpenAL,
ALbuffer
is basically piece of cpu-memory + a bit of meta-information and should be compatible across different physical devices.Would it be possible to have maybe new extension (or is there existing one?) to allocate a buffer without any context/device and use them across different physical devices?
Problem that I'm solving;
In my engine class
Sound
, that is wrapper forALbuffer
playback data is not tied to sound physical device. However engine-level api allows toalcReopenDeviceSOFT
)Case 2 should work, except there is no openal support for it.
The text was updated successfully, but these errors were encountered: