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?)
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.
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.
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?
Thanks.
Tim.
Side thoughts:
We don't use the above mechanism for external midi, there's
no way to tell if an external midi device is 'ready to roll' and
vice-versa, if it initiates play there's no way for it to know if
we are ready.
Well, one could turn on the device's echo (thru) and its midi
realtime output messages, then MusE tells it to play, and we
sit and wait in MusE for a midi play or locate command message
to come back, but that's a real ugly hack, but interesting...
Normally, pure midi devices are always ready to roll easily,
not usually requiring caching of midi notes from disk and so on,
but what if that device includes audio files? Say, connecting
one PC running MusE to another PC running MusE, via ALSA.
Thankfully there is Jack-2 with network support. The Jack sync
mechanism works over a network. I've seen ALSA-over-network
projects but I don't think they're used much, and I don't think ALSA
has 'transport sync' functions which is what we're interested in here.
One could even separate the functions - transmit and receive our own
custom transport commands and responses over IP using some
custom protocol or say OSC, while midi is kept on its own interface,
say regular hardware midi or midi-over-ip or something...
------------------------------------------------------------------------------
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
