Open MainCharacteroftheProblem opened 8 months ago
this is probably why those songs shit themselves is because of it being forced to one thread of course single thread performance on lots of devices comes out to jack shit
this is probably why those songs shit themselves is because of it being forced to one thread of course single thread performance on lots of devices comes out to jack shit
as someone who has a laptop made in 2018, i can agree that my audio does temporarily (and sometimes permanently) cut off as soon as i press spacebar
See #85 for one example of doing something like this.
One issue with that is that it's using
postMessage
to send data back and forth between the main thread and the audio worklet/thread. Looking around, there are recommendations to useSharedArrayBuffer
with audio worklets (e.g. here), though that complicates this even more - in particular, it makes deployment here annoying, as we can't set the necessary HTTP headers, without tricks like the one seen here.For experimenting with this, the song player may be an easier and less disruptive target. If
postMessage
happens to cause audio dropouts as part of the process of updating e.g. the playhead there, then some kind of position estimation can be done (keeping in mind that tempo modulation will screw that up, so that needs additional care), and those messages can be sent much less frequently.