-
Notifications
You must be signed in to change notification settings - Fork 115
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
Apply ambisonics to an audio file then to a video file result to a non playable video #84
Comments
Here is the sample to execute on a localhost: Here is the sample online: |
Notes on the samples
|
So sorry for the late response! (Was on vacation when the issue was filed...) I am not sure if I understood the problem correctly. This is what I did:
But if I access the scene 3 with the direct link, it plays the audio correctly. Did I get your problem right? |
Yes exactly. |
Have not looked at the code yet... Can you keep the audio context and the Omnitone renderer? Why do you have to re-instantiate the whole thing for every scene? The Omnitone renderer is simple and transparent, so all you need to do is the reset the rotation matrix to put it back to the initial state. There will be a tail of 256 samples from the convolution, but that's less than ~7ms. It should be trivial to reconstruct the renderer from scratch, but still there is a cost and you might want to avoid that. For each scene, all you have to do is to create MediaElementAudioSourceNode for audio or video tag and feed it into the renderer. Keep it mind that an AudioNode must be connected to the node belongs to the same audio context. |
Thanks for your feedback. I've tested with a SoundManager class which create a FOARenderer and connect it to the "global" audio context. But I've exactly the same result. Note: on some sounds or videos I'll be happy to switch between FOA and HOA renderer also, it's why I was creating and instanciating the Ambisonics renderer on each sound or video where ambisonics are required on my first test. |
Could you try it again with the latest version of Canary? I think it might have been a bug in Chrome's implementation and I fixed the issue a couple of days ago. |
Same result with a few tests with the latest Canary version. |
Okay, I think this is related to an implementation bug in Chrome. Have you had a chance to try this out in FireFox? |
My bet is changing the source of MediaElement dynamically does not go well with the attached MediaElementSourceNode (which is a Chrome bug). For the workaround/hack, I suggest you to do this:
When changing the source:
|
One more finding: if you change |
@bbaudel The example above does not work correctly any more because of the recent Autoplay policy change. Could you check it out? I would like to revisit this because the problem might have been fixed in Chrome. |
Here is the code using it. I will add a sample online soon (tested with Omnitone 1.0.6 and 1.2.1) :
https://github.com/gopro/forgejs/tree/alps-700-omnitone-fix
https://github.com/gopro/forgejs-samples/tree/alps-700-omnitone-fix
The text was updated successfully, but these errors were encountered: