I’ve encountered a sudden and baffling issue in my FMOD-based web application, which has been running smoothly until recently. An error has started appearing, seemingly out of nowhere, linked directly to FMOD’s AudioWorkletProcessor . The error manifests when I attempt to play a sound, particularly after focusing on the app. Here’s the error message I’m consistently seeing:
Uncaught TypeError: Cannot read properties of undefined (reading ‘length’)
at AudioProcessor.process
This issue is particularly perplexing because it arises from FMOD’s internal AudioProcessor, which I haven’t modified. My app utilizes FMOD for advanced audio processing, and this setup hasn’t changed in the last two months.
Error Context:
The error occurs randomly when activating audio playback.
Refreshing the browser sometimes temporarily resolves the issue.
Attempts to troubleshoot, including switching branches, browsers, or running environments, haven’t yielded any insights.
Troubleshooting Done:
Ensured all FMOD and Web Audio API usage follows best practices.
Reviewed recent changes to both my code and FMOD updates, finding no direct correlations.
Searched for similar issues within the FMOD community and broader web development forums without success.
Given that the error bubbles up from FMOD’s AudioWorkletProcessor, I’m at a bit of a loss on how to proceed. Has anyone else experienced similar issues, or does anyone have insights into potential causes or solutions?
Any advice, debugging tips, or shared experiences with similar issues would be greatly appreciated. I’m eager to resolve this and get back to smooth audio processing in my app.
It seems that the AudioWorkletProcessor is being given an empty channel in its output buffer.
I am not sure what kind of assurances we get on the validity of the output buffer, but it looks like we might need to handle a null case.
To help me reproduce this and suggest a possible workaround for you, can you please tell me:
Thank you for the additional information, I can now reproduce this in the latest Chrome.
This seems to be a Chrome bug as @alexzzen mentioned above, but I have informed our Dev team to see if there is anything we can do about it for the time being.
I have found that I can workaround the issue by bailing out of the process function when an empty output buffer is passed in.
The file isn’t very human readable, but if you add the following to fmod.js then empty buffers will be ignored and audio should resume once the output buffer becomes valid.
...
"}",
"if (output.length == 0) { return true; }", // <- Add this line to the string array
"const bufferSliceEnd = this.bufferSize / output[0].length;",
...
There are two of these “const bufferSliceEnd = this.bufferSize / output[0].length;” lines in the file, and you should add the bail out line above both to cover all cases.
Please give that workaround a shot and let me know if you are still encountering any problems.
Thank you so much for the update and for sharing the workaround. It’s awesome that the team are taking steps to address this. The workaround you’ve provided seems like a clever approach to circumvent the problem for now.
Given the information you’ve shared, I was wondering if you’ve had a chance to test this issue on other browsers like Opera, Edge, or Mozilla Firefox as well? I’ve encountered the issue across multiple browsers, so it might not be isolated to Chrome alone. If it’s not too much trouble, could you please look into this on these other browsers as well? This could help in determining if the problem is broader than a Chrome-specific bug and if similar workarounds might be necessary for other browser environments.
If you are linking to the w32 libraries directly then your only option for now is to change your output mode to FMOD_OUTPUTTYPE_WEBAUDIO.
This would also apply to anyone building to WebGL from Unity.
I’m pleased to let you know that the temporary solution you provided is effective. I’ve noticed a slight decrease in sound quality during some refreshes, but it’s manageable at the moment.
Eagerly anticipating the permanent fix from the team. Appreciate your assistance!
it does not affect if add call setOutput(FMOD_OUTPUTTYPE_WEBAUDIO) after initialize (flag FMOD_STUDIO_INIT_SYNCHRONOUS_UPDATE is used)
it cause to error “mStartInterval is not defined” if call before initialize
This suggests the FMOD::System object is still trying to use the AudioWorklet output type, perhaps ScriptProcessorNode is no longer supported in your browser?
Otherwise, you should also be able to make the same changes to you generated .js file.
If you search for the two "const bufferSliceEnd = this.bufferSize / output[0].length;" lines and add "if (output.length == 0) { return true; }," before each of them, that should also workaround the issue.
You would have to do that every time you compile though, so for development I would suggest you downgrade your browser for the time being and only make the changes I mentioned for distribution.
Thank you for your help! We fixed generated js and it’s works (no exceptions with length any more).
But sometimes sound & music still has some glitches-noises(probably we need recheck init’s flags).
Opera One(107.0.5045.15)
Windows 10 64-bit
Chromium:121.0.6167.140
It’s not the same issue, but looks linked
I rechecked all fmod init’s flags, make some fixed, but it does not help
may be it not fmod error, but browser’s itself, so it’s just to infrom
after fix of js, 50/50 cases we have audio glitches-noises
checked game with old version of Opera - there were no any problems about month ago
old version(106.0.4998.19) works perfect 100% cases - https://youtu.be/URY9Syyb-iY
new version(107.0.5045.15) - 50% cases sound this - https://youtu.be/ZJXXPdWDU50
sorry - I can not post link to the game, it’s under development Windows 10 64-bit
These sort of discontinuities generally indicate an issue with the size of one of your audio buffers: Audio Stability (Stuttering).
Can you please try calling System::setDSPBufferSize with 2 blocks of 2048 samples and see if that helps at all? Otherwise trying a larger buffer size of 4096 might help, at the cost of some additional latency.
video abover - https://youtu.be/ZJXXPdWDU50 - it’s case 2 blocks of 2048
I have checked buffer size up to 8196 (16k - failed setDSPBufferSize)
big buffer make some affect, sounds a little better, but noises still there
PS sometimes refreshing page resolves problem for session
PSS fmod logs has not difference
Have you noticed whether all sounds are affected globally or if it’s just this background music?
It’s possible your Streaming settings require additional configuration if only the background music is stuttering. Can you please try calling System.setStreamBufferSize with a larger value, perhaps 32768 TIMEUNIT_RAWBYTES, and see if that helps with the stuttering at all?