On Wed, 9 Feb 2022 01:34:19 +0100 Ichthyostega <p...@ichthyostega.de> wrote:
>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. > > >Hi Will, > >thanks for following up on that one. Last weekend I also tried somehow to >provoke that Xrun, but I don't seem able to reproduce that behaviour, even >with an VM using only two cores. Either I get Xruns all over the place, or >I don't get any. I just looked up my old receipts. This computer is now nearly 8 years old, and when I bought it my overriding requirement was for it to be silent - hence fanless. >> Flying by the seat of my pants here, is it possible to make the swap in a >> non-rt thread to maybe a 'plain' intermediate wavetable, and then do the rt >> swap with this? > >That would kindof bring us back to square one: we use the std::future (which >is managed within the class FutureBuild) to protect the passing of data between >threads. Thus we'd again need some sync primitive to protect the handover from >the helper-thread you propose to the actual rt-thread. Please recall that >threads can potentially run on different or the same CPU, and that without >any sync primitive, there is no guarantee that the other CPU sees the >memory content coherently. E.g. it could be that the rt-thead sees >the swap of the pointer, but not the new contents of the wavetable. >Btw, such hickups are unlikely to happen on x86 processors, but more >likely to happen on ARM or other architectures with "weak cache corherence" Apologies! I keep getting tripped up by cross-thread matters :( >However, Your observations might point into an interesting direction. > >> 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. > >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 wi within the Body >of the if-clause. eg assign some variable? > > >The reason why I am asking is as follows: >The implementation of FutureBuild::isReady() (see BuildScheduler.h line 347) >does a non-blocking wait on the future. However, while this "technically" does >not incur any blocking wait, it implies a so called "yield point". That means, >the OS scheduler *can* at that point preempt and reschedule to another thread, >and this becomes more likely if the system as such is already under pressure >(which might be the case, since, if I recall correct, your test system has >only effectively two cores, and we have at least two threads with permanent >computing or I/O activity (the ALSA thread and the Synth thread). > > >Another thing you could try (in case the call to isReady() does not give us >a lead) 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() ... No Xruns with either of those. >-- Hermann > > >PS: last weekend I was struggling to chase down some problem within the >Reverb effect, which seems to produce spurious differences in the test suite. I would think that is actually the most likely place for errors to accumulate. It massively loops, as well as calling our old friend analogfilter :( -- 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
