Has anyone else noticed that that a preload trial can sometimes freeze/stall, even on a stable/fast connection, if there are a large-ish number of files being loaded? We had a few reports from participants that they couldn't get past a preload trial, and I just reproduced the problem. The file downloads just fully stopped (not continued very slowly). It worked the second time I tried it under the exact same conditions, so it's definitely intermittent.
I think the problem is related to how the preload plugin works: it fires off all image/audio/video file requests synchronously, instead of chaining or batching them. I think the problem with this approach is that (1) the bandwidth is divided into equal parts for each file request, which means that, for lots of files, each request is much slower and thus less able to recover from intermittent network issues (dropped or out-of-order packets) before network-level response timeouts, vs having only a few files that can use more of the bandwidth, and (2) with the web audio API, the audio files are also immediately decoded (rather than just saved to disk), which is resource intensive. The reason this is intermittent would then be because there needs to be a certain combination of factors that cause the process to stall, e.g. several audio files that finish downloading around the same time, which the browser is simultaneously trying to decode, plus concurrent disk-writing for other files.
I'd like to try modifying the MediaAPI and preload plugin so that it does the following:
- Chains the requests by media type (e.g. image -> audio -> video). This would be straightforward to implement since we already have separate
jsPsych.pluginAPI.preload methods for each media type, so we can await each one.
- Within each media preload method, batch the requests by some number. This is pretty arbitrary, but 6 seems like a good limit for image files since that's the cap for open TCP connections for the same origin in HTTP1. It might make sense to have smaller batches for audio, because of decoding, and video, because they tend to be larger binaries.
- Add retry logic, possibly with reduced batch sizes (parameterized?)
After making these changes, I'd be happy to do some benchmarking to make sure that this approach doesn't negatively impact performance. I can compare preload trial durations for the new approach vs existing, using a set of different conditions (few vs many files, audio/image/video only vs combination).
Questions: @jspsych/core I hoping some of you know more about this than me and can tell me if I'm wrong about the likely cause of the issue, if there are problems with my suggested fix, or if there's anything else I'm missing.
BTW I'd be happy to incorporate any open issues related to the preload API and plugin at the same time, e.g. add a CSS loading animation option as an alternative to the progress bar (#540), fix the issue with nested arrays (#2727).
Has anyone else noticed that that a
preloadtrial can sometimes freeze/stall, even on a stable/fast connection, if there are a large-ish number of files being loaded? We had a few reports from participants that they couldn't get past a preload trial, and I just reproduced the problem. The file downloads just fully stopped (not continued very slowly). It worked the second time I tried it under the exact same conditions, so it's definitely intermittent.I think the problem is related to how the preload plugin works: it fires off all image/audio/video file requests synchronously, instead of chaining or batching them. I think the problem with this approach is that (1) the bandwidth is divided into equal parts for each file request, which means that, for lots of files, each request is much slower and thus less able to recover from intermittent network issues (dropped or out-of-order packets) before network-level response timeouts, vs having only a few files that can use more of the bandwidth, and (2) with the web audio API, the audio files are also immediately decoded (rather than just saved to disk), which is resource intensive. The reason this is intermittent would then be because there needs to be a certain combination of factors that cause the process to stall, e.g. several audio files that finish downloading around the same time, which the browser is simultaneously trying to decode, plus concurrent disk-writing for other files.
I'd like to try modifying the
MediaAPIandpreloadplugin so that it does the following:jsPsych.pluginAPI.preloadmethods for each media type, so we canawaiteach one.After making these changes, I'd be happy to do some benchmarking to make sure that this approach doesn't negatively impact performance. I can compare preload trial durations for the new approach vs existing, using a set of different conditions (few vs many files, audio/image/video only vs combination).
Questions: @jspsych/core I hoping some of you know more about this than me and can tell me if I'm wrong about the likely cause of the issue, if there are problems with my suggested fix, or if there's anything else I'm missing.
BTW I'd be happy to incorporate any open issues related to the preload API and plugin at the same time, e.g. add a CSS loading animation option as an alternative to the progress bar (#540), fix the issue with nested arrays (#2727).