Am 28.01.2014 22:27, schrieb Dennis Schulmeister: > 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.
The audio thread is never accessing the model. Never. The audio thread does never lock any mutexes. Instead, the prefetch thread accesses the model, and locks on mutexes. The prefetch thread only fills the ringbuffers that are consumed by the audio thread. But these ringbuffers always hold more data than the audio thread will actually consume in the next frame. That's why it's not a problem when the prefetch thread has to wait on a mutex. The number of remaining frames in the ringbuffer will fall down, but because the ringbuffer is chosen large enough, there will be no dropouts. After the prefetch thread has acquired the lock, it can re-fill the ring buffer with enough data. This concept actually works, ardour is doing it like that. And consider that locking on mutexes is *way* less problematic than waiting for disk access. And have you had any disk-access-related dropout in muse yet? > > 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. Keeping a working copy around is a waste of resources. And because the audio thread never touches the model, as noted above, we have absolutely no problem to simply do mutex locking and editing the one working copy we have. Consider that with multiple working copies, we would need to synchronise all audio streams (you cannot random-access a .OGG file), which would massively complicate things (i even think that it's impossible.) Cheers, flo > > 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 >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
