Am 24.01.2014 06:20, schrieb Tim E. Real: > On January 22, 2014 10:37:55 PM Tim E. Real wrote: >> >> Relax, you are right. >> >> It has taken me a long time but I realize now that the way MusE handles >> processing is wrong. >> >> To make a long story (which follows) short, we'll do it the right way, >> something like this: >> >> https://github.com/jackaudio/jack2/blob/master/example-clients/capture_clien >> t.c >> >> Rough blueprint: >> ============== >> >> The Jack process callback should do one job only: >> Move data into and out of the Jack ports. >> >> You know all that crap we do in our process callback? >> That's gotta be moved outta there into OUR audio thread. > > No! > > Man, I hate to flip-flop... but I'm /reversing/ my position regarding > our Jack process callback. We CAN'T use another thread to > transfer data to the callback. > > It is *right* the way it is. Really :
okay, that was the only point i questioned and wanted to come back later ;) Yup, doing stuff in the process callback is actually how things are done. However, I think we do too much in there. Seeking the correct MIDI position (multimap::upper_bound) is not the task of the audio thread, that's the task of some seeking/butler/prefetch thread. It's not like it isn't broken. It's only not broken the way you described it ;) How about multiprocessing? We should really support this. Actually, processing all the plugins could -- if done right! -- be split between the prefetcher and the audio thread. The prefetcher prefetches and precalculates all tracks where no input is routed to, while the audio thread does exactly the same thing for all tracks where input is actually routed to (because it must pipe this input through the plugins as well). > Today I dug deep for answers: > ... > As I said before, I agree there are some things we can do to speed it up. > Another is maybe splitting the work up between different process calls. > We can use certain Jack functions to determine how much time is left > in the process call before we gotta get outta there. Multithreading. > Another is using mutex or trylocks as you say. > I noticed even Ardour and some of the Jack examples use it WITHIN the > process. > I'm not sure. Wouldn't we need to lock our data OUTSIDE of the process? We must lock in both threads: In the audio thread (i.e. everything which is called from process() or descendants), and in the GUI thread. Yeah, locking. I'm not sure whether we should not just abandon this message passing thing and just use mutexes. YES, we will *lose* realtime capability *while editing*. Glitches may occur, priority inversion might happen. > I mentioned this great discussion about locks and real-time: > http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing > Kinda scared me off mutexes and such. Yes, mutexes are bad for realtime. But, do we actually need realtime always? I mean, when I'm editing while I'm playing back, then i do not need a 100%-guarantee of glitch-free-ness. Of course, they *should* not happen to often, but *might*, which is not a problem in those situations usually. Hmmm. Tim: How about creating a design document step by step before starting to do anything? Yes? No? Cheers, flo
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
