[Lmuse-developer] GUI latency considerations

[Florian J. <fl...@wi...>]

Hi

ABSTRACT:

It is "GUI performance" XOR "crackle-free playback".
Currently, MusE focusses on "crackle-free" only, neglecting "GUI
performance". (Using message passing, delegating work to the audiothread)
With my proposal, we could offer "crackle-free" whenever needed, but can
also offer "GUI performance" when currently not playing back (i.e. most
of the time!)

tl;dr: skip this until ====SNIP====

i'm currently doing a great rework of:
- the Undo system
- the way GUI-actions are synced with the audiothread
- clone parts
and much more...

I have removed the ModifyPart Undo operation. When you now want to
modify a Part's beginning, length or name, you do not any more create a
copy of the part, modify that, and then replace the old part with the
modified copy, but you just submit a ModifyPartTick. The audio part will
parse and execute that message then.

However, i want to make this message passing *obligatory*. No GUI part
may have the possibility to directly write into audio-thread-managed
data. (I.e., all GUI routines may only receive const references to the
EventLists.)

This arises one problem: someevent->setSelected() must be handled by the
audiothread as well. This makes things similarly slow as moving notes in
the score editor. For every operation, we've to wait for the audio
thread to process it.

====SNIP==== interesting part starts here:

Now i'd like to speed this up:
When the song is not playing or recording, the audio thread does not
access its parts in any way, right?

We could lock a mutex whenever we're playing back, and release it when
transport is "stopped".

Then, song->applyOperationGroup() can tryLock() this mutex.
(tryLock locks it, if possible. if not, it does not block, but
immediately return!)
If locking succeeds (i.e., if transport is stopped), then the changes
can be applied in the GUI context without any harm. And this is *fast*.

If locking does not succeed (i.e. transport is playing), then we have to
go over the Audio::sendMessage, and wait for the audiothread to execute
our changes.



There's only one race-condition: When applyOperationGroup() has locked
the mutex, but audio would like to start playing in the very same
moment. MusE can use the transport framework to tell the transport
master "please wait some milliseconds, i'm still initalizing...", so
this won't be an issue.




I'd really like to hear your opinion about this (further work depends on
this).

This would enable us to clean up huge part of muse, I even dare to say
this can be the first step towards a easy-to-maintain muse3!

And it would improve GUI performance notably, especially on setups which
are not trimmed towards minimum audio latency (e.g. MIDI setups!)


in await for your reply, Tim, Robert and Orcan,
flo