Background audio loading

[nielsm]

Allow audio loading/decompression to take place in a background thread, so you can still work on the subtitles while the audio is being loaded.
The audio display should not appear before the audio was completely loaded, and all items in the Audio menu should be disabled. (Perhaps add a "Cancel audio loading" to it while loading.

To avoid interrupting/confusing the user, the audio display should not appear the instant the audio loading is finished, but instead the complition of the audio loading should be made clear in some other way, so the user can select when the audio display will appear. (Another possibility would be to first display it after a few seconds without input activity in Aegisub.)

An alternative to hiding the audio display while loading would be to display it immediately, and use it as a progress indicator similar to how Medusa does. All audio features would still be disabled while loading this way.

[nesu-kun]

a loading progress bar should be added to the status bar, could have a context menu that allows you to cancel, or a clickable label.

[ArchMageZeratuL]

I suspect that Avisynth might die a horrible death if used in threads, that is, if I'm loading the audio while messing with video, even if they use different environments.

Hopefully, Avisynth audio mode will die once the lavc mode is coded. Equinox is the one to bug for it.

[Jeroi]

I take my words back. I would like this idea of loading audio at backround and have a indicator which say that you can now add audio view. There could be a config option load audio directly or background for user to define which way to load audio.

[Ereza]

Well, on my laptop with 256 MB of RAM it takes about 5 minutes to load an 1:30 hours movie, so it would be nice to have it implemented in some way.

[TechNiko]

Aww that would be nice.

[IcemanGrrrr]

even for short eps, waiting for 2 minutes to load the audio is 2 minutes wasted :P

[nielsm]

Revisiting this, if it's still interesting (well, it kind-of is, dunno how much though) a suggestion for UI would be similar to those "security advisory bars" in recent Firefox and IE versions, those yellow bars at the top.

While audio is background-loading, display a small bar instead of the audio display. The bar has loading progress and a Cancel button. When loading is finished the bar starts pulsing or similar and the Cancel button gets replaced by an Open (or similarly labelled) button that will replace the load-bar with the actual audio display. This combines clear feedback of progress and completion with a relatively non-intrusive non-space-wasting interface.

But if Avisynth is really that thread-unsafe maybe it's a bad idea after all. (Is it even unsafe if you have a script environment not shared with any other threads in the application? Avisynth itself shouldn't hold any kinds of global state that could interfere.) I don't think Avisynth disappears from Aegisub any time soon...

[ArchMageZeratuL]

Myrsloik would probably know more about Avisynth threading. If it's feasible, I think that we should do it as jfs suggested.

[IcemanGrrrr]

nice idea, but I would skip the "open button" step and open the audio display automatically upon completion

[nielsm]

The point of having an "Open" button to finish audio loading is such that the interface doesn't suddenly jump around while the user might be working. It could easily confuse the user, and maybe make them mis-click somewhere if not paying attention.

[IcemanGrrrr]

Yes that may be true...
To solve this side effect, just open the audio frame, and have the "progress bar" use the exact same space than the audio display.
Then, the automatic open won't change the place of other UI objects.

[nielsm]

Actually this could be implemented in the current framework, I just realised.

Implement a new caching audio provider that keeps track of how much of the audio is available. This one should act as an adaptor for other audio providers, i.e. it takes an existing audio provider as parameter to its constructor.
The adaptor provider (BackgroundCachingAudioProvider perhaps) gets the various properties from the source provider, importantly the stream length in number of samples, and allocates a disk file big enough to keep the cached audio data. This should probably be done using mapped memory, but that's a detail.
The background caching provider keeps track of how much has been decoded so far. A thread is spawned, this thread runs a decode-update loop with the source provider, decoding a chunk of audio, writing it to the cache file, then updating the caching provider's status. The thread just ends and cleans up after itself (deleting the source provider object) when it's done.

When a chunk of audio is requested from the caching provider, one of three cases are possible:

• All of the audio requested has been decoded and is available. Fill it into the provided buffer.
• None of the audio requested has been decoded. Fill the buffer with silence.
• The range contains both decoded and undecoded part, split it into two and handle according to the above.

This does bring a problem with the handling of the audio spectrum display and its cache. I don't have a solution for this worked out right now.

[verm]

Setting to milestone:3.0.0

[verm]

Bump 3.0.0 tickets to milestone:3.0.0 (2.2.0 is becoming 3.0.0)