You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now when one sources replaces another as the maximum number of playing sources reaches a maximum we don't retain any memory of that source having been playing. This places the onus on restarting stopped sounds that should be continuously playing on the user of Mixdown. It's also a bit odd if a high priority short sound replaces a low priority longer sound and the longer playing sound never comes back. Again putting the onus on the user to avoid reaching the maximum number of playing sounds.
Rather we should place stopped sounds and those that cannot be played due to lack of free slots into a virtualized context where their progress is tracked without actually playing the sound. Then we can make sure any virtualized sounds are started in the correct location as free slots become available.
This is going to require per frame updates of the virtual context so Mixdown will need to run in the requestAnimationFrame callback or similar to support this use.
Further due to timing attacks like Spectre the high performance counter available to JS has been made inaccurate so our timings for virtualized sounds will likely suffer. Probably most notably if a sound is played and virtualized in a loop in quick succession. So care should be taken to test and think about mitigations for these cases. For example having some debouncing for playing and virtualizing sounds.
The text was updated successfully, but these errors were encountered:
Right now when one sources replaces another as the maximum number of playing sources reaches a maximum we don't retain any memory of that source having been playing. This places the onus on restarting stopped sounds that should be continuously playing on the user of Mixdown. It's also a bit odd if a high priority short sound replaces a low priority longer sound and the longer playing sound never comes back. Again putting the onus on the user to avoid reaching the maximum number of playing sounds.
Rather we should place stopped sounds and those that cannot be played due to lack of free slots into a virtualized context where their progress is tracked without actually playing the sound. Then we can make sure any virtualized sounds are started in the correct location as free slots become available.
This is going to require per frame updates of the virtual context so Mixdown will need to run in the requestAnimationFrame callback or similar to support this use.
Further due to timing attacks like Spectre the high performance counter available to JS has been made inaccurate so our timings for virtualized sounds will likely suffer. Probably most notably if a sound is played and virtualized in a loop in quick succession. So care should be taken to test and think about mitigations for these cases. For example having some debouncing for playing and virtualizing sounds.
The text was updated successfully, but these errors were encountered: