On Mon, 14 Feb 2022 02:39:01 +0100 Ichthyostega <p...@ichthyostega.de> wrote:
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?
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.
Am 14.02.22 um 19:47 schrieb Will Godfrey:
Unfortunately this doesn't seem to make any difference :(
Most frustrating!
Hi Will,
since I am unable to reproduce the Xrun with my machines,
my hope for narrowing this down relies on (ab)using your machine as guinea pig.
Those continued attempts aim at narrowing down the reason why we see those
Xruns. Unless we know that reason (instead of just guessing), it is hard to
search for ways how to deal with it.
Generally speaking, I am still in search for a point to "lock in" and narrow
down. Maybe we can reach that point from /the other side/, i.e. where *no* XRun
occurs, and then gradually add in thread sync functionality?
Thus I've prepared a changeset for you: this replaces all actual thread
synchronisation primitives with "FAKE" implementations; these somehow emulate
the behaviour, but just access the shared state without any protection.
On my Github, you'll find a new branch "xrun" on top of "padthread"
In my tests here, this version kind-of works and the sound is as expected.
But it becomes rather crashy (several Segfaults) and produces garbled PADSynth
sound, as soon as I increase the parallelism (by loading several instruments
at the same time).
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
