*COMPLETED* MapTool b89 with Streaming Sound Functionality

[wolph42]

Here my overall remarks (rev2):

- basically it works GREAT! Thank you for this awesome addon.
- I've tried a couple of commands while the ambient was playing, and it all seemed to work seemlessly. So the threading works.
- its takes quite some time before something starts playing as everytime it needs to be redownloaded again. E.g. the Chopin.wav takes 1 to 2 minutes between each loop, so an ambient sound is not really an option currently....hence caching seems the most viable
- I'm guessing that if you send a 'sound' to several clients, that each client start downloading it own version, plays it and then removes it again. The biggest issue with this is that if theres a big difference in bandwith between clients they will hear the sounds at different times. This does take out the 'drama' from 'dramatic effect'. I don't know if thats something you can have a look at, to somehow sync the sounds (although Im guessing that in that case the best option is caching once again).

c'est tout! great work, once again: thanks. (now I need Jamz to get this merged into his frankenstein build).

[Lord.Ashes]

in addition to my last post. I've added 'chopin.wav' to the repository, its 18 Mb. this to test ambient sound.

on my pc it took +/- 2 minutes after execution, before it actually started playing.

Interesting...seems like the Java Clip function may not be doing streaming...that sounds like it actually downloaded the entire file first. So I guess it isn't all that useful for background music unless you an predict that you will need it and load it in advance.

[Lord.Ashes]

Here my overall remarks (rev2):

- basically it works GREAT! Thank you for this awesome addon.
- I've tried a couple of commands while the ambient was playing, and it all seemed to work seemlessly. So the threading works.
- its takes quite some time before something starts playing as everytime it needs to be redownloaded again. E.g. the Chopin.wav takes 1 to 2 minutes between each loop, so an ambient sound is not really an option currently....hence caching seems the most viable
- I'm guessing that if you send a 'sound' to several clients, that each client start downloading it own version, plays it and then removes it again. The biggest issue with this is that if theres a big difference in bandwith between clients they will hear the sounds at different times. This does take out the 'drama' from 'dramatic effect'. I don't know if thats something you can have a look at, to somehow sync the sounds (although Im guessing that in that case the best option is caching once again).

I have not done testing with large files so I hadn't gotten to this issue. The "quote" files that I play are short and thus they loop almost back to back. Actually for quotes they loop quick enough that esthetically I would prefer a bigger gap. But I can imagine that large files would gap longer as they are re-loaded. I will look into actually looping the play instead of re-opening the file for each repetition.

Without having the audio locally (e.g. the asset implementation) I don't see how the lag would be resolved. I mean I could build in some manual caching but each new audio would need to be loaded anyway. Same goes for the dramatic effect. I guess I could have all the player load their audio and then send out some handshaking to start the audio all at once but that will get messy as soon as you have multiple players connected.

Hmm...maybe an implementation where the first time a sound is played it is downloaded from the repository but then stored locally so successive use of the audio would be quicker. Maybe even a preload command so that larger audio files could be pre-loaded to the clients before activating them locally. That could partially resolve the caching/looping issue and even partially the dramatic effect because the GM could pre-load the client and then trigger the local copies (which should eliminate almost all of the bandwidth dependency).

once again: thanks. (now I need Jamz to get this merged into his frankenstein build).

Glad you like it. I posted Eclipse Patch files (with each Rev) so it should not be a big issue to apply these mods to a custom MapTool source (I am guessing that is what "frankenstein build" is) assuming you are using Eclipse or similar for your development.

[wolph42]

I have not done testing with large files so I hadn't gotten to this issue. The "quote" files that I play are short and thus they loop almost back to back. Actually for quotes they loop quick enough that esthetically I would prefer a bigger gap. But I can imagine that large files would gap longer as they are re-loaded. I will look into actually looping the play instead of re-opening the file for each repetition.

note that 'short' sounds on my pc also take 3 seconds 'lag' before they start playing and thus have a 2-3 second gap while looping. These are typically files of 40kb. Perhaps *you* can test this by setting the repository to my dropbox, see a couple of posts up for instructions.

Hmm...maybe an implementation where the first time a sound is played it is downloaded from the repository but then stored locally so successive use of the audio would be quicker. Maybe even a preload command so that larger audio files could be pre-loaded to the clients before activating them locally. That could partially resolve the caching/looping issue and even partially the dramatic effect because the GM could pre-load the client and then trigger the local copies (which should eliminate almost all of the bandwidth dependency).

I'm all for !!

Glad you like it. I posted Eclipse Patch files (with each Rev) so it should not be a big issue to apply these mods to a custom MapTool source (I am guessing that is what "frankenstein build" is) assuming you are using Eclipse or similar for your development.

AFAIK jamz is using eclipse and indeed 'frankenstein build' is a custom mod.

[jfrazierjr]

Despite my various "naysaying", I do want to give you credit for something that "does work"(as opposed to theory/suggestions, which is about all I have had time for in a long while!). I know a number of people ask for this feature once in a while, and a number of forum regulars would like it now, so at least they have a simple alternative as long as they are up using a custom build and do the setup work.

And now that I know dropbox will actually work the way I did not think it would, I might actually use this myself for the short term.

[Lord.Ashes]

note that 'short' sounds on my pc also take 3 seconds 'lag' before they start playing and thus have a 2-3 second gap while looping. These are typically files of 40kb. Perhaps *you* can test this by setting the repository to my dropbox, see a couple of posts up for instructions.

Doh! I know why mine are playing so fast...because I am using a repository that I am hosting...so it does not have too far to go. It still has to stream it from the server but since the server is local it probably doesn't even have to leave the machine.

Now wonder I am not seeing the lag. Now that you are talking about it I recall that when I had a second computer on the network stream the audio there was a distinct lag between the local machine (running the repository) and the client.

In any case, I will look into trying to do something about the lag but for now we will be stuck with it.

[Lord.Ashes]

People speak and I listen...

------------------
REV 4.0 CHANGES:
------------------

Same link as before, just go into the Rev 4 sub-folder

* Sounds are cached if the OS allows it. If a sounds does not exist locally it is played from the repository (as before) but afterwards it is downloaded locally (if OS allows).
Next time the same sound is requested, it plays from the local source thus playing immediately instead of having to be downloaded again.
* cacheSound allows sounds to be cached (downloaded to local machine) in advance so that they are ready when they are needed. Affects all connected players.
* Looping is greatly improved. Uses the actual Clip loop function so no need to reopen/download audio for each loop.
* stopSound now takes a parameter. A value of 0 does an immediate stop (as it did before) whereas a value of 1 finishes the current repetition but does not play any additional repetitions.

This means that you will still get a longer wait the first time you request a sound (unless it was cached with cacheSound in advance) but all uses of the sounds after that should be quick.

Please note that at the moment the cache is not automatically cleared. The cached files are placed in the MapTool Resource directory. I am still thinking how to best clear the cache because you eventually want to get rid of audio files that are not longer being used but you may not want to do this after each session because if a game spans multiple sessions then you may want to reuse the same sounds.

If the caching can not be done (e.g. due to OS permissions) then the implementation should default to using the repository (as it did before). Since Java security only allows access to file system operations if you are running as an application (as opposed to an applet) the caching benefits will be lost if running MapTools as an applet. Additional security (such as the UAC in Windows) may also apply. I have not tested all the conditions under which it will not run. I have tested on Win 8 machine running MapTool as a application.

If you find combination that don't seem to work, please let me know...I may not be able to do anything about it but it will give me an idea of how many people can and how many people can't use this solution.

[wolph42]

Nice !!!

Well then, you're nearly done I would say. This only leaves '.mp3'

[Lord.Ashes]

Nice !!!

Well then, you're nearly done I would say. This only leaves '.mp3'

To try and appeal to more people, I would eventually like to add asset support...so that players have a choice. However, I think this is beyond my skills at this moment...I would need to study the MapTool source code a lot more to implement that and, at the moment, I don't have time for that.

However, is someone wants to take my code (I have posted the Eclipse Patches for each Rev) and run with it to add asset support then I am all for it. I will look into the MP3 issue...MP3 support would be a lot nicer than only WAV.

[Lord.Ashes]

POTENTIAL BUG (Rev 4):

If someone has time, can you please confirm the follow (I am at work so I can not do it right now):

The caching of sounds after they are played from the repository occurs in the individual channel Thread so they should not block MapTool while they are caching. However, I just realized that the cacheSound Macro Function currently runs in the main Thread and thus it might be blocking depending on how the download function is implemented.

Can someone try to use the cacheSound() Macro Function with a larger sound file and see if they can use MapTools immediately afterwards (i.e. the download is not blocking) or if MapTool "freezes" for the duration of the download (caching).

If no one checks this by tonight, I will do a check myself. If need be, it should not be difficult to fix...However it may take me to the weekend to get a chance to fix it (if a fix is necessary).

[Lord.Ashes]

COMING SOON (aka The Wish List):

* Command(s) for turning caching on and off (i.e. for users that may be using a public computer, they can turn caching off)
* Command(s) for clearing the cache

As I said, I would prefer not to clear the cache automatically (e.g. on session end) because games (that re-use the same sounds) may span multiple sessions.
As such I think the best practice, for now, is to provide commands for clearing the cache.

Maybe I will (also) implement a configuration setting which would tell MapTool to automatically clear the cache on exit if the setting is active. This way
the user will have the most flexibility regarding the cache.

USER WISH LIST:

If you want to suggest some additional features (besides asset based sounds), especially if they don't appear to be too complex to implement, you can post a BRIEF suggestion in this Thread. However, if you want to discuss some additional features or how to best implement them, please use the other Thread so that we keep this Thread as clean as possible. Thanks.

[Azhrei]

Maybe I will (also) implement a configuration setting which would tell MapTool to automatically clear the cache on exit if the setting is active. This way the user will have the most flexibility regarding the cache.

MapTool has this problem in general. There's no way for MT to clear the assetcache, for example.

I think the user should be able to specify both a "soft limit" and a "hard limit". The soft limit is when MT starts warning the user about the space consumed by the cache. The hard limit is the point at which MT starts deciding what to delete (and with an option to just go ahead and do it). The user could set a soft limit of 2GB (or whatever) and a hard limit of 2.5GB. When they hit 2GB, they get nagged about it. When they hit 2.5GB, MT starts deleting elements from the cache, starting with the oldest ones, and skipping any asset that is in use by the currently loaded campaign.

Oh well. Something for the future.

[Lord.Ashes]

Maybe I will (also) implement a configuration setting which would tell MapTool to automatically clear the cache on exit if the setting is active. This way the user will have the most flexibility regarding the cache.

MapTool has this problem in general. There's no way for MT to clear the assetcache, for example.

I think the user should be able to specify both a "soft limit" and a "hard limit". The soft limit is when MT starts warning the user about the space consumed by the cache. The hard limit is the point at which MT starts deciding what to delete (and with an option to just go ahead and do it). The user could set a soft limit of 2GB (or whatever) and a hard limit of 2.5GB. When they hit 2GB, they get nagged about it. When they hit 2.5GB, MT starts deleting elements from the cache, starting with the oldest ones, and skipping any asset that is in use by the currently loaded campaign.

Oh well. Something for the future.

Too bad...I was hoping that MapTool already had some function for clearing the assetcache and then I would have just "borrowed" that folder for my sound cache and let the existing code do all the work for me But since the functionality does not exist, as of yet, I guess I will have to code it myself.

[JamzTheMan]

Lord.Ash, suggestion. If you are using the same "asset" folder as MT, and you are going through the effort of creating something, can you put it in a separate patch?

If it can be used for all cache/asset items, it would be a welcomed addition to 1.3 and maybe Az can add it in.

[Lord.Ashes]

Lord.Ash, suggestion. If you are using the same "asset" folder as MT, and you are going through the effort of creating something, can you put it in a separate patch?

If it can be used for all cache/asset items, it would be a welcomed addition to 1.3 and maybe Az can add it in.

Sure thing. I'll make the patch based on a clean MT-1.3.b89 so that it does not include all my sound patching.