Hi guys, 2015-02-03 12:51 GMT+01:00 Andrew Deryabin <[email protected]>: > 03.02.2015 04:46, Tim E. Real wrote: >> On February 1, 2015 06:08:27 PM Andrew Deryabin wrote: <..> >> As mentioned Florian wanted to start a new MusE based on lockable lists, >> of the kind like say Boost I think, but he said another one I can't recall. >> Currently instead of locks we just verrry carefully time EVERYTHING. >> It means we just hope that any desired realtime operations commands >> can be completed before the next callback, else xruns. >> All real time operations commands MUST be done through the GUI >> which waits until (a group of) real time operations have completed. >> You can't even initiate a real time operation from ANOTHER thread, >> it must be done through the GUI for correct synchronization. >> We have some reverse help with RT -> GUI messaging with the use >> of QSocketNotify. Thankfully it ALSO provides a synchronization >> mechanism in that these are GUI event loop messages so we know >> our GUI thread is 'clear and ready' for the message.
Wow, I didn't know we used QSocketNotifier. I'm on a small crusade to remove platform specific implementations (to ease possible porting to OSX and Windows) and I'm right in the middle of finding solutions for the current implementations using poll. I'll look at these then. > Since I started to work on MusE, All demos that I did were made in debug > build of MusE running under gdb session. And when breakpoint is > triggered in rt thread context some strange things can happen. For > example if I wait for some time (say 40-50 seconds) before continuing, > it always leads to horrible cracks until muse internal frame pointer > catches up with jack one. Also MusE can drop events of midi tracks > completely saying something like "currentFrame > endPos" or so error > messages, though live midi input is working right. Is this behavior is > related to this synchronization scenario or it's something else? I can > make a video of this effect. Some years ago when I was using the internal fluidsynth more (I still do use it for many songs), there was a bug where this currentFrame > endPos would be printed. Some wrap around of a counter I think, I never could isolate the reason. It happened if I left MusE running for a day or two so it wasn't a major problem. <...> >> OK Cool, I had read about those functions but never thought >> to use them, in my broad search on lockable lists and so on. >> Now they make a lot of sense in this light. >> >> Not sure about the assembly, I find linux assembly really hard >> to follow in after many years of assembly coding in windows. >> >> Tested: With one of my audio/midi songs tonight, seems OK. >> Will keep an eye out for trouble. > Ok. This is good. I checked - this asm code is translated to near > exactly the same asm as for gcc atomic ops with one exception that those > functions are using `lock xchgadd` instead of `lock add`, for example. Just one note, during my crusade I noticed there are some QAtomic classes, maybe we should offer these as an alternative in the generic case? Unless we are already generic enough, but I would think the assembler parts won't compile with MSVC. Regards, Robert ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
