API discussions feedbacks

[Solido]

Just a feedback as I need to work more with the lib.

At first it seems that this is an exposed API, a front for advanced low-level capabilities.

It means that we can sugar the Flutter side to reflect Flutter and content creators patterns.

As an example, with my first use, I add to build a cache on my app before anything else.
Future<AudioSource> worked with first calls and logged me warning about the reload of existing asset.

What I would like, as a fully transparent and configurable solution, is a weak links cache.

The method used to find the asset is the key to the cache, each method can be configured to escape cache. Cache can be configured with a maximum size in keys entries and/or memory before soft release.

Another VERY important aspect the assets rights management. I want to be able to trace source and ownership of my assets.

Here's a an shot at a somewhat higher level API that would rely on all the greats low-levels features exposed but avoid each devs to rebuild the asset access part.

Cache can be preloaded with list on assets on startup.

final gameSounds = SoundCache(soloudInstance, maxMemory: 5.mb);

final settingsSounds = SoundCache(soloudInstance, cache: Cache.None);

// register is lazy, will load only on call
settingsSounds.register(
  Sound( assetURI , author:'Good Artist', link: 'link', etc));

// or preload 
await gameSounds.preload([Sound(...),Sound(...),Sound(...),Sound(...),])
// Ready!

// call loadAsset and cache AudioSource for next call if not preloaded.
// Reuse that instance later.
gameSounds.play(assetURI, loop:false); // same API but 


// My code or widget wants a cleanup.
gameSounds.dispose()...

Different part of the app get its own cache,
Some are large and always alive like the main screen,
some will be freed quickly on even won't cache like settings screens.

With these people can link their widgets lifecycle to cache.
It also offer access to right managements.

[alnitak]

Hi @Solido ,

Future<AudioSource> worked with first calls and logged me warning about the reload of existing asset.

given that when you load a sound it remains loaded till you call disposeSource() or disposeAllSources(), your SoundCache() should manage this behavior. If I understand well your thoughts and needs, the warning you are receiving is telling you that the sound you are loading is already loaded, hence the SoundCache didn't manage its disposal in SoundCache.dispose()?
For example, you load an asset somewhere:

AudioSource sound = await SoLoud.instance.loadAsset('mySound`);

that AudioSource remains loaded even if the sound is not accessible and everywhere in your code you repeat the above code, your new AudioSource will be the same:

AudioSource newSound = await SoLoud.instance.loadAsset('mySound`);

newSound.soundHash and sound.soundHash are the same and they are pointing to an unique sound (the hash is created based on the URI).

Things may be getting bad if 2 different instances of SoundCache share a sound. For instance if both gameSounds and settingsSounds have the same bip asset sound. When you call the dispose() of one of those SoundCaches, the bip gets disposed on both of them.

A tip: you SoundCache receives as a parameter the soloudInstance. You can safely remove it and use SoLoud.instance in that class.

A 2nd tip regarding SoundCache.maxMemory: the physical memory that a sound uses differs from the audio file size. It is better explained here.

But maybe @filiph could have some more insights for you because he is building a "GIANT" game using this plugin!

I hope I well covered this discussion!

[Solido]

Thanks for the feedback! I think I got clear ideas about the important parts of the plugin.
I share my instant feelings as I found them the most useful because the path I'm going through will be the same for all devs.

I may not able to reproduce it (now I use my cache) but at least I instantly triggered a bug at my first try under macos while loading the same asset sound stopped after the second call so I add to build a cache myself. Just seems overkill as a first time user and eventually every dev would have to rebuild it for themself.

I'm following VERY closely (like pixel peeping) the work of @filiph for years :)

The discussed concepts may not apply as the assets are constants but let's say there was an environnement swap or very specific units then you would want a convenient way to prioritize their sounds in memory as well as the capacities to unload them.

Another point I would like to share is the dependence to Flutter. Should there be a core that rely only on Dart and then a Flutter layer on top? I add to make an important refactor because my core in build and tested in dart and only later Flutter is build on top. So soloud is not testable in the core. Refactor so included an interface to Soloud and passing the implementation when Flutter is starting. Guess others devs working on large projects will hit that too.

I'm so glad to benefits from your work! it works very well and I'm still learning how far it can push.

[alnitak]

I may not able to reproduce it (now I use my cache) but at least I instantly triggered a bug at my first try under macos while loading the same asset sound stopped after the second call so I add to build a cache myself. Just seems overkill as a first time user and eventually every dev would have to rebuild it for themself.

Yes, even if you stop a SoundHandle, its AudioSource owner is not disposed (it remains in memory for later use, useful in games). You still need to use SoLoud.disposeSound() to remove it from mem and don't get the "already loaded" exception.
If you need to play a sound and dispose it when it finishes, you could listen to AudioSource.soundEvents. With something like:

AudioSource sound;
sound = await SoLoud.instance.loadAsset([...]);
await SoLoud.instance.play(sound);
sound.soundEvents.listen((event) {
  if (event.event == SoundEventType.handleIsNoMoreValid &&
	  sound.handles.isEmpty) {
	SoLoud.instance.disposeSource(sound);
  }
});

But maybe this is not what you want because your SoundCache has to manage sound disposal itself.

Another point I would like to share is the dependence to Flutter. Should there be a core that rely only on Dart and then a Flutter layer on top? I add to make an important refactor because my core in build and tested in dart and only later Flutter is build on top. So soloud is not testable in the core. Refactor so included an interface to Soloud and passing the implementation when Flutter is starting. Guess others devs working on large projects will hit that too.

I didn't sleep for this :).
You are right. SoLoud is a singleton and makes testing difficult. This could sound a Code smell also because it carries around the instance for the lifetime of the application.
But IMHO in this case, having a singleton is a must. The player engine is only one and letting the dev make more instances of SoLoud, will for sure raise many problems, ie: you cannot initialize the system audio device twice.
Well, I think a singleton is not evil and forcing a way to not use them to respect some design pattern rules, is close to a religious thing :)
Singletons are evil yes, mostly like when used in a multi-thread environment, but this is not our case.

When making tests, I suggest using SoLoud.deinit() before SoLoud.init() just to be sure the engine is not active and all sounds are disposed. In the example/tests dir, I made tests using a normal Flutter app. Although I don't know if it is a good solution! I am open to suggestions!

[Solido]

Singletons are not evil! they are perfect valid constructions when modeling real world interaction :)

My point was just you need a flutter project to test the lib but I would prefer a dart simpler one.

Those are just my feedback, API is working very well and I'm building on it :D

[alnitak]

Great!! I am curious, please keep me posted when your creation will be available!

However, you made me think that a higher class that manages AudioSource in groups, as for your SoundCache, could be a great idea.

[Solido]

I'll put you in the loop with great pleasure.