Am 08.02.22 um 16:41 schrieb Will Godfrey:
I've been doing a bit of poking around. It seems the Xruns are being
caused by actually entering futureBuild.swap(), not the code inside it.
If I comment out all the code inside the function, then while
(obviously) there is no sound I still see all the Xruns. However, if I
comment out the *call* to it in activate_wavetable() there are no Xruns.
On Wed, 9 Feb 2022 01:34:19 +0100 Ichthyostega <p...@ichthyostega.de> wrote:
Now the important question is: what is with the Condition test...?
if (futureBuild.isReady())
Does that coincide with Xruns? could you maybe test that in isolation? I.e.
invoke the isReady(), but then only do something local within the Body of
the if-clause. eg assign some variable?
Another thing you could try is to invoke some other function on the
futureBuild object, within the body of the if-clause (instead of invoking
FutureBuild::swap(). For example call FutureBuild::isUnderway() ...
Am 09.02.22 um 12:22 schrieb Will Godfrey:
No Xruns with either of those.
...so we're facing a rather puzzling situation here.
If I understand your experiments and findings correct,
invoking the actual synchronisation primitive does *not* produce an Xrun
(the synchronisation happens within FutureBuild::isReady() and in
future.get(), i.e. within swap() ).
However, just invoking an empty function at the same point (without invoking
FutureBuild::isReady() *does* provoke an Xrun.
So *one hypothesis* would be, that the problem isn't caused by synchronisation
at all, rather by some other rearrangements done for integrating this feature.
In the PADnoteParameters::activateWavetable(), there is also a call to
presetsUpdated();
...which causes a recomputation of note parameters; obviously this didn't happen
before the change, since it is what we need to do now to overcome that 1st-note
problem.
int PADnote::noteout(float *outl,float *outr)
{
pars->activate_wavetable();
if (padSynthUpdate.checkUpdated())
computeNoteParameters();
computecurrentparameters();
...
might this cause the Xrun?
*Another hypothesis* could be that you're bitten by the "magic" built into
the x86_64 architecture to allow sloppy programmers to get away without
proper synchronisation. Basically those 64-bit CPUs are not really cache
coherent (they have a NUMA architecture, other than the original Intel x86,
which was fully cache coherent, IIRC), but there is a lot of hardware magic to
detect concurrent access to the same memory addresses and to synchronise from
CPU cache to main memory providently. In micro benchmarks I did some years ago,
I saw the speed of quite mundane computations drop to 1/4 just by some other
thread accessing the same memory addresses concurrently
Another thought: can we take MIDI out of the equation?
Is it possible to provoke the Xrun just with the virtual keyboard.
Or even better, can we provoke the Xrun with a *CLI script*?
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
