Feature #1326
Show progress of loading test (in background)
| Status: | Resolved | Start date: | 2015-07-13 | |
|---|---|---|---|---|
| Priority: | Urgent | Due date: | ||
| Assignee: |  Nicholas Jillings | % Done: | 0% | |
| Category: | - | |||
| Target version: | - |
Description
Especially important for online tests: show how many fragments left to load.
'In background' part: it should be possible to start the test already (and have unloaded fragments greyed out or delay playback until the clicked fragment is loaded.
History
#1
Updated by Brecht De Man over 8 years ago
- Assignee set to Nicholas Jillings
- Priority changed from Normal to Urgent
I understand now the 'in the background' part is not straightforward in the case of looping (although I imagine a workaround could be implemented to get the looping information upfront, then already allow playing back 'green' sliders).
As it can take a while to download the sliders, it's quite important to at least tell the user the interface is loading the samples, as it might be construed as 'not work' if it takes, say, a minute to load.
#2
Updated by Nicholas Jillings over 8 years ago
- Status changed from New to In Progress
The buffer objects in the buffer pool (audioEngineContext.buffers) now have a progress attribute which reports the percentage download of a media file using an in-built event. The difficulty now is getting those on the page and is more a design point than anything else. Do we have any design ideas for APE and MUSHRA interfaces?
#3
Updated by Nicholas Jillings over 8 years ago
- Status changed from In Progress to Resolved
All interface objects now MUST have an updateLoading function which can show the rate of download of any buffers still waiting. The interfaces will get the enable() function call when the audioObject linked to them has received the buffer (which occurs after loudness calculations).