Hi all, Lots of things in MusE are pretty complicated, because they involve communication with the audio thread, or because they require us to pre-allocate things outside of the audio thread and so on.
I want to question this realtime capability of MusE, please bear with me: My first point to legitimate all this is: MusE aims to be realtime capable, but *it is not*. What makes me say that? Well, even though realtime patterns are implemented in MusE (such as message passing with the audio thread, because we can't use mutexes, and pre-allocating buffers outside), they are not consequently used. Some examples: when undo()ing, this can take an undetermined amount of time inside the audio thread; it basically scales in O( number_of_operations_to_undo ), which might be large (e.g. if i have deleted 1000 events at once.). MusE might fail to meet the realtime constraints -> glitch. in many places, MusE does tempomap lookups *in the audio thread*. C++'s map structure, however, does not make any guarantees about it's worst-case-runtime. If we're unlucky, we might fail to meet our realtime constraints. (I must admit, a large part of this is my fault.) Every frame, MusE collects the events to play in the next buffer period by finding begin and end iterator in the EventList, and loops through lots of data structures. Most of these are from the STL and do not make any timing guarantees. Additionally, it's plain unnecessary. One could just increment an iterator (which, of course, still needs to be an iterator in a realtime-safe structure), and a search-in-binary-tree would only be necessary upon a seek(). The Audio thread may not allocate any memory, therefore, lots of uglyness is done to do this allocation outside of the audio thread (e.g. by the gui thread, and then only passing (smart) pointers). However, then, newly created events are inserted into a std::multimap. Which internally needs to malloc() a new node of the binary tree (or whatever internal data representation is used). Malloc is known to not fulfill any realtime constraints -> muse might glitch. Certain things are done by switching the audio thread into Idle state, which stops processing any data, and instead delivers zeros. While MusE will not fail at realtime here, this still introduces glitches. We may not do this, msgIdle must be eliminated. This puts me in a dilemma: a) we need to *massively* redesign MusE to make it realtime capable. This would involve hard separation between audio and GUI, no shared data! They should be put into different processes, even. It would probably affect GUI performance. We must restrict editing operations while playing back. Forbid tempo changes, forbid "large" event manipulations while playing. b) We drop this hard realtime thing. MusE will become a studio software which should not, but *might* glitch. We would greatly reduce code complexity by not having to respect all the corner cases. We will keep the message passing, but we will use certain realtime-breaking functions, like std::map's functions. I can't really see another way out of this. Actually, i like a), but i fear that this will be too much work; i think that would almost equal a full rewrite from scratch. Could we probably even use mutexes for synchronisation? I mean, our critical blocks when editing are pretty short, so maybe priority inversion could help us? With priority inversion, when a low-prio thread holds a mutex that is required by a high-prio thread, then it temporarily also gains high priority until the mutex is resolved; then control is given to the high-prio thread. Please discuss, I'm totally insecure about this :/ Florian
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
