On Tue, 28 Jan 2014 10:48:38 +0100 Florian Jung <[email protected]> wrote: > > Yes of course, if we use locks, then gather up all changes that we possibly > > can and then apply them in one quick burst inside a lock. > > Just... I don't know if that's as quickly done as said. > > Depends on your view of "quick". > > It will not be as quick as we would need for realtime operations. It > would be too slow if the *audio* thread would wait for this lock. > > But the audio thread doesn't. The *prefetch* thread waits for this lock, > and thus, we may take up to half as long as our prefetch queue is.
Are you sure about this? As long as the model is in inconsistent state that audio thread can't reliably access it. But then, acquiring a mutex in the audio thread will be a sure receipt for dropouts. I see the point with undo/redo. And as Tim points out, that it already provides the infrastructure for a "list of changes to be applied" on the model. But even with this list I think there should be a "working copy" of the model objects. If a pointer swap can't be atomic one could pass the new model pointer to the audio thread through the ring buffer. Dennis ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
