Re: [yoshimi-user] Some optimization patches for Yoshimi
- From: Kristian Amlie <kristian@xxxxxxxxxx>
- To: yoshimi-user@xxxxxxxxxxxxxxxxxxxxx
- Date: Sun, 07 Oct 2012 01:56:25 +0200
On 10/06/12 19:45, Will J Godfrey wrote:
Not wishing to be critical and I *really* want to encourage development, but how
does the behave under heavy usage?
Presumably the effect is to put a larger block of data manipulation inside a
lock. Could this cause xruns with more 'aggressive' voice patches?
Master Synth? Hyper Matrix?
I was actually wondering the same thing myself when I moved the locks,
but came to the conclusion that this should not be possible. The reason
is that the whole code section is supposed to be finished within one
single jack period. This can be seen by looking at where MasterAudio()
is called from, which is ultimately from the jack process callback
(JackEngine::processCallback). The code inside this callback is the only
code that can cause an xrun (by running for too long), and claiming or
releasing an internal lock will not change this. In fact, xruns should
be less likely now, since less time is spent locking.
The only negative effect I can possibly see is that the timing of
incoming MIDI events may be slightly delayed, since the code that
delivers those events is using the same lock from a different thread.
Since the lock is only released at the end of the process callback now,
the other thread may have to wait a little longer. But the wait is
guaranteed to be shorter than one jack period, so this is still *very*
short (a few milliseconds at most), and there wasn't really any
guarantee that it would be any faster with the old approach: For
instance, if you had one single very demanding voice, the lock would be
held during the whole rendering of this voice, which would also delay
the MIDI timing.
I'll try to find time to check this out myself tomorrow, but I don't seem to
have much success applying patches :(
Hmm, strange... Did you try git-am?
--
Kristian
Other related posts:
