Am 30.05.2013 23:51, schrieb Tim E. Real: > On May 30, 2013 08:32:01 PM Florian Jung wrote: >> Am 30.05.2013 09:44, schrieb Tim E. Real: >>> Thus, are any fears of resource bloat totally unfounded? >> >> i just loaded a 400MB wav-file into MusE. >> >> RAM usage before: 1723MB >> RAM after starting muse: 1742MB >> RAM after loading a 400MB file: 1745MB >> >> as we can see, those files are *not* fully loaded into RAM. The increase >> of RAM usage can be explained by internal management structures in MusE >> (hey, we're using 20MB for an empty project), so there's no need for >> deduplication at MusE's side. >> >> -> Yes, any fears of resource bloat are totally unfounded. >> >> Greetings >> flo > > Right. Good stuff. I hope. (And the same of multiple opens on the same file?)
if opening one huge file consumes 3MB, then opening the same file four times surely won't consume more than 12MB. (which is neglectible, i have 2GB ram in my weakest machine). > This is why we have our audio pre-fetch cache thread. > Because it gives sndfile time to fetch and load the next segment from disk, > which will take a small bit of disk seek time and we can't make the audio > thread wait. With my audio streams, the prefetch thread will just call AudioStream->getData, which reads the data from the disk and does all calculations. I hope that's fine; we will probably be able to do that in multiple threads, because AudioStream is totally self-contained. No locking neccessary. > > FYI: Jack has a 'slow sync' mechanism where, if the Jack transport > is requested to start playing, even by *us*, Jack will ask via a callback > whether clients, us too, are indeed 'ready to roll' or if they need more > time to sync or fetch data or whatever, so the Jack transport can be > 'held up' from rolling. Jack calls this special state JackTransportStarting. > > We use this mechanism to seek our audio prefetch cache and make sure > it is ready to roll with the next data: > > See the method Audio::sync(), the line(s): > done = MusEGlobal::audioPrefetch->seekDone(); > > Audio::sync() is called from jack.cpp in two places: > processSync() callback, and JackAudioDevice::processAudio. could you please write some words about this into the documentation? thank you. > > > So why did we have SndFileR... I can't help thinking there was a reason, > I have to think and check, I looked at it many times... > But I suppose in effect your AudioStreams basically replaces that whole > ref functionality anyway (it has to). If we must, we would want to move > reference functionality into AudioStreams anyway, to keep things 'housed' > appropriately for ease of use, right? True. The AudioStreams will handle the resources appropriately, no external intervention needed. Only they won't aggressively try to re-use SndFiles, because this does not help, and is WRONG for FLAC files. greetings flo ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
