Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache URL audio #15

Open
bsutton opened this issue Jun 30, 2020 · 0 comments
Open

Cache URL audio #15

bsutton opened this issue Jun 30, 2020 · 0 comments
Labels
enhancement New feature or request

Comments

@bsutton
Copy link
Owner

bsutton commented Jun 30, 2020

It should be noted that we already have the Downloader class that can download a file with progress information.

A number of users have requested the ability to cache URL audio data so that subsequent playbacks are not delayed.

Currently the Track class has been designed to avoid the user having to manage any resources Sounds needs to internally allocate for a Track (e.g. cached for url data).

If a Track where to auotmatically cache the URL data then we would have to exposes a 'release' method on the Track class to allow users to indicate when we should clear the cache.

Whilst an out of the box caching experience sounds nice it does raise questions about exactly how it should be implemented and what the UI should look like when pre-caching audio.

QuickPlay is a good example as it doesn't have a UI so the user will simply not see/hear anything as the audio gets cached.
The ShadePlayer is also an issue because again we have no way to indicate via the UI that we are caching the data (this might not be true potentially the shades do have a method of playing directly from a URL).

Our own widget SoundPlayerUI already supports loading the URL data and reflecting the download progress in the UI (vai a percentage spinning progress indicator).

It feels like it might be better if we gave the user an explicit caching mechanism and they then build the UI to suite their purposes.

Internally we use Track._prepareStream to download URL data.
We could just expose this externally and then also expose Track._release. I'm not a big fan of this as the release method will suggest to users that they need to call release all of the time which isn't the case.

So what about a caching class

class TrackCache
{
      Stream<Progress> cacheTrack(track);
      release(track);
     releaseAll();
}

When you call cacheTrack it returns a stream which could be passed to a StreamBuilder to allow a user to build a widget that reflects the caching progress.

It should be noted that we already have the Downloader class that can download a file with progress information.

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant