Question on openal js implementation #19182
-
https://github.com/emscripten-core/emscripten/blob/main/src/library_openal.js Hi, First, the Emscripten OpenAl implementation is super efficient, it really leverages what the web spec has to offer and it's really good to be able to use HRTF with such convenient API. Amazing work there! I have a question about getting the offset of a source and queueing. Is queueing multiple buffers of varying length a valid thing to do with the open Al implementation in Emscripten? From reading the code it looks ok and I can't really tell any problems when testing. The reason I ask is because I am comparing with a different implementation where it looks like this is not possible, but unless I am testing this incorrectly, it looks like it's ok to do it here. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
I don't recall such a limitation, and don't immediately see one in the code, so I'd guess it should work. But @juj would know for sure. |
Beta Was this translation helpful? Give feedback.
-
Queueing multiple buffers of different length each is ok, there are no specific restrictions to the queued buffer lengths. One note is that this general strategy where multiple buffers are queued to be played/"stitched" continuously back-to-back is an abuse of the Web Audio API. I.e. it is not a use case that is supported by Web Audio API, and browsers have had issues in the past with producing seamlessly joined audio in this manner. When we reported those issues as bugs, they were rejected as "this should not be expected to even work". However from those conversations we have been told that if one makes sure that the audio sampling rate of the stitched audio buffers matches the sampling rate of the AudioContext that is being used, then there is the best chance of avoiding audio crackling at the seams. Otherwise the audio backend will need to perform resampling, but it does not have the knowledge to do such resampling that across buffer seams, so the joined audio buffers may crackle at the transition edges between multiple buffers. Audio Worklets is the extension feature to Web Audio API that is intended to provide seamless audio synthesis to JS&Wasm code. If you run into issues with the OpenAL buffer stitching method, check out https://emscripten.org/docs/api_reference/wasm_audio_worklets.html for more info. |
Beta Was this translation helpful? Give feedback.
Queueing multiple buffers of different length each is ok, there are no specific restrictions to the queued buffer lengths.
One note is that this general strategy where multiple buffers are queued to be played/"stitched" continuously back-to-back is an abuse of the Web Audio API. I.e. it is not a use case that is supported by Web Audio API, and browsers have had issues in the past with producing seamlessly joined audio in this manner. When we reported those issues as bugs, they were rejected as "this should not be expected to even work".
However from those conversations we have been told that if one makes sure that the audio sampling rate of the stitched audio buffers matches the sampling …