Open fde31 opened 11 years ago
Okay. I implemented audio streaming on the basis of the AudioTag but had to push it onto a new feature branch as it works in Chrome Canary only. Otherwise it's not possible to manipulate the received audio with the WebAudio API. Seems like the hooks for that aren't implemented in the current stable version of Chrome.
But I guess it's worth mentioning that this change decreased the memory usage about 250mb for me so might wanna discuss how to continue from here...
@fixed can you run both versions on your machine and compare the mem-usage? Does it work for you on windows, too?
I tried it briefly today and it worked fine but I also have 32gb of ram in my machine 8) (not the canary stuff, though). I am in for disconnecting the effect chain from the sources when the station is going out of range but I wouldn't delete everything (especially not the video tag as we want to have the playback position still in place).
I think we are safe to say that we will need a dedicated machine instead of a laptop at this point. I will check my hardware-dump today to see what is missing.
I also have a desktop machine getting dusty somewhere in a dark corner... but i think its not a very performant machine; roughly 10 years old. But if you miss a part, maybe I have it.
Ok. I just pushed a NEW branch test/video_memoryusage in order to test if we get significant improvement with destroying VideoEffect nodes and it turns out it doesn't make a big difference and the actual deal breaker seems to be Audio. I just a couple of different setups with huge amounts of vid/audio less no vid/only audio and etc. The memory usage increases drastically as soon as we add Audio.
I could investigate a bit further but seems like we should give Canary a deep and long testing scenario on a Windows machine and try to run the final product with the streamed audio content. Also could one checkout the VideoTest branch and watch the memory usage? One should give every branch a shot with different config files. The first config could be the one on master and on the vid test branch is a visual "heavy" one. Might be interesting to know the memory behavior on a Windows machine though as I'm only running this on a Mac right now.
Downloading Canary right now. Will report back.
Ok, Canary baseline on my Windows 7 machine is around 150mb.
master: 560mb audiotag_streaming: 350mb video_memoryusage: 380mb
okay. So let's try if it works on Canary. One should just run an long lived test (let the thing run for a about a day) and check if it's stable and if we have a memory leak somewhere.
I suggest we build the thingie tomorrow and I'll let it run for a couple of hours then and see how well Canary does the job.
I'd say we go with the video-branch. Seems ok to me with the additional RAM.
http://stackoverflow.com/questions/3258587/how-to-properly-unload-destroy-a-video-element but we have to remember the last video position for the next playback.
While working on the SlideShow component I ran the whole thing with two channels and encountered that the Chrome tab was using about 600-700MB of RAM. Ouch!
There are a couple of ways to address that:
1) Video / Images Seems like decreased video/image size isn't really helpful. According to this:
https://github.com/brianchirls/Seriously.js/wiki/Tips-%26-Tricks-for-Building-Compositions-with-Seriously.js
it might be way more efficient to delete the nodes and recreate them when used. Not sure how big the delay/latency would be when we switch on channels (onload) but if understand this post correctly node and therefore effect, source etc. stores an uncompressed frame in memory.
2) Audio Currently all sample are implemented as AudioBuffer nodes, which make them memory-resident in order to shot them quickly. This might not be necessary if I'm correct for a couple of reasons:
a) we are streaming from localhost -> low latency b) we don't fire a sample multiple times
One could address that issue by changing the AudioSample class to make use of
Shall we address these issues for the first presentation? I guess it might even be necessary due to our hardware limitations or otherwise we would have to come up with a badass RAM on the actual machine. It's not a problem on my 16GB RAM but I guess it might look different on other machines.