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
This might be irrelevant once the player is converted to AudioWorkers, but:
Each Player implementation currently has its own ScriptProcessorNode (i.e., see call to createScriptProcessor() in Player base constructor).
In the beginning, these nodes would be added and removed from the audio graph based on playback.
That caused audible lags/audio glitches, so the solution was to leave the nodes attached to the graph once created.
This has a slight performance overhead (made more obvious with ?debug=true param) - eventually 6 audioProcess callbacks are being called at once (one for each Player implementation).
The players are all "paused" but they still have to fill the buffer with zeros on every audioProcess callback.
This seems dumb; why not create one master ScriptProcessorNode and have the audioProcess method delegate to the implementations ("do you want to write any audio")? At least this way, there is only ever one buffer being filled with zeros, and for stopped players, the audioProcess is a no-op.
The text was updated successfully, but these errors were encountered:
Instead of leaving this up to each player and creating a stack of script processor nodes, this should save idle CPU cycles when all players have been loaded. Previously, they would each have their own processor node continuously filling a buffer with silence.
Required slight adjustment to audio graph. Previously, gainNode was same as playerNode. Each player would connect its output to the provided playerNode. Now, players don't know about audio graph at all, but just fill the channel buffers passed to the processAudio() method.
This might be irrelevant once the player is converted to AudioWorkers, but:
createScriptProcessor()
in Player base constructor).?debug=true
param) - eventually 6audioProcess
callbacks are being called at once (one for each Player implementation).audioProcess
callback.audioProcess
method delegate to the implementations ("do you want to write any audio")? At least this way, there is only ever one buffer being filled with zeros, and for stopped players, theaudioProcess
is a no-op.The text was updated successfully, but these errors were encountered: