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

Reply via email to