search

Cycling74 / rnbo.example.webpage

Running a RNBO patch in the browser, using a local static web server
MIT License
88 stars 22 forks source link

Older Phone Compatibility #12

Open kokaNikoladze opened 11 months ago

kokaNikoladze commented 11 months ago

Testing my webapp on several generations of iPhone. Newer models work without issues, but starting from iPhone Xs (iOS 13.7) and backwards, get a mysterious error pointing at line 28 in rnbo.webaudio.js, saying No space between hexadecimal literal and identifier, then another error Unhandled Promise Rejection: ReferenceError: Can't find variable: RNBO.

Screenshot 2023-09-23 at 23 02 02
benbrackenc74 commented 11 months ago

It looks like we need to determine what a good minimum version of iOS and Safari would be. We will likely use this as a guide: https://webassembly.org/roadmap/

Which means that we should probably specify Safari support for Desktop 14.1+ and iOS 14.5+

kokaNikoladze commented 11 months ago

After some research I realized it has to do with Audioworklets. Is there any way RNBO can support developers with a functional polyfill? Use case - interactive shows, soundwalks, audience participation, etc. Some people show up with nun-upgradable older phones (which in a way aren't that old, they are perfectly capable of running a synth or a sampler).

fde31 commented 11 months ago

@kokaNikoladze have you verified that it is in fact caused by the use of AudioWorklets? RNBO has feature detection and falls back to using ScriptProcessorNodes if the browser does not support AudioWorklets (can also be forced at createDevice time using the type parameter) .

I'm curious as the issue you reported already happens before the RNBO framework was loaded and I assume without even trying to instantiate a device.

kokaNikoladze commented 11 months ago

@fde31 After having tried to identify the issue for two days straight, I held on to that belief for a day, might have been a protection mechanism. Now I'm unsure. The problem might be elsewhere.

kokaNikoladze commented 11 months ago

Just got a second opinion now. It looks like there might be a parsing issue in the JavaScript. Could be that newer versions of Safari handle the code gracefully, while older versions don't. Can this be related to ECMAScript specifications? Then it would be a relatively easy fix.