On Mon, 14 Feb 2022 02:39:01 +0100 Ichthyostega <p...@ichthyostega.de> wrote:
> >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 Unfortunately this doesn't seem to make any difference :( Most frustrating! For the sake of completeness. This machine is running devuan chimaera and the laptop is on debian bullseye. I keep them both up-to-date Also I run Rox Desktop with Openbox window manager. -- Will J Godfrey https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel