Hi Will,
today I tried still harder to somehow reproduce that Xrun, but without avail.
I tried a laptop from a friend with Ubuntu 14.04. But even there I did either
get XRuns all over the place when using more complicated instruments, or when
switching buffers down to below 64. Or otherwise I only got occasional Xruns,
but without connection to PADtable rebuilding.
Same results with a Virtual machine configured to only one CPU. When using
ALSA both on Host and Guest, Alsa seems to run with 1024 whatever, even when
Yoshimi switches down the buffersize later. And no Xrun.
With pulseaudio on the Guest system I can produce Xruns, but again only
masses of Xruns or no Xruns at all.
Am 13.02.22 um 21:35 schrieb Will Godfrey:
I can't think of any reason why someone would want to change the wavetable
size/geometry in real-time, so would it make things easier if those controls
did in fact silence the part (or disable PadSynth) and then perform that
action in a low priority thread?
This would help, if adapting to different wavetable sizes was actually a
problem; yet your recent tests showed that commenting out presetsUpdated()
did not remove the Xrun -- and this indicates that computeNoteParameters()
and thus adapting the interpolation to another size is not the problem.
Anyway, your (really helpful) recent tests give at least some lead...
Am 13.02.22 um 15:10 schrieb Will Godfrey:
With those both back to normal, but a 'return' placed in BuildSceduler.h,
before FutureVal* future = retrieveLatestTarget() there are no Xruns.
Place the 'return' immediately after that call and there are Xruns.
And in retrieveLatesTarget() there is the "compare-and-swap"-Operation to
ensure that we get hold of the pointer to the future atomically, while
no one else can grab it at the same time concurrently.
We could at least try to weaken that mechanism and see what happens then...
Could you try out instead just to read the atomic variable with the lowest
possible level of memory sync order, and likewise set it to null without
caring for possible collisions with other accesses?
That means (in BuildScheduler.h, line 443, Function FutureBuild<TAB>::swap()
FutureVal* future = target.load(std::memory_order_relaxed);
if (future)
{
target.store(nullptr, std::memory_order_relaxed)
//and then proceed with the existing code
using std::swap;
TAB newData{move(future->get())}; // may block until value is ready
swap(dataToReplace, newData);
delete future;
Generally speaking, the idea is to reduce the operations step by step,
to see if there is a point where that nasty Xrun goes away.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
