On Tue, 1 Jun 2021 18:31:20 +0200 Ichthyostega <p...@ichthyostega.de> wrote:
And -- next surprise -- after the seed(0) the PRNG-Values are 100% the same
in the test sound sequence produced with the new test function. Just the
*generated sound is not reproducible*.
So for now all we know is: there must be some evil nasty little thing
hiding somewhere in the code, and this "thing" manifests itself when
running with the ALSA backend, but not when running with
Jack-Freewheeling.
Am 01.06.21 um 18:56 schrieb Will Godfrey:
As far as I understand, freewheeling pays no attention to time, just operates
commands in the sequence they arrive, so I wonder if there is some time
related oddity.
Hi Will,
Hi Kristian,
...and this nasty little thing seems to hide itself quite well in the code.
For one, it is rather hard to boil down the setup to something so simple that
it is reasonable to trace. Most non-reproducible sounds I found, tend to show
up with the Pad-Synth, which is rather challenging to understand as far as
data flow is concerned. Also, I couldn't spot an easy pattern regarding which
features are actually affected. Anyway, after several experiments I have
now a setup with a very simple Add-Synth, which exhibits random phase.
Next thing I did is to mark each instance of the PRNG with an ID string
and an ongoing (static) instance counter. This allowed me to print a trace
of each PRNG seeding and usage during a 100ms run with my new test function.
What is immediately clear from diffing these traces: we are drawing some values
from some harmonic PRNG instances prior to re-seeding them with a reproducible
value from the main-PRNG. And -- depending on the timings prior to starting
the test, these values are thus nondeterministic. After the reseeding, the
rest of the sequence is deterministic. So this at least explains why the
specific setup of the yoshimi instance (Alsa vs Jack/Freewheeling) matters,
and also why just some seemingly arbitrary features seem to be
non-deterministic.
However, I am still having a hard time when it comes to identifying the
problematic code path; there are several instances involved and the
data flow is rather confusing. But at least I'd say we have a clear
lead now why we observe non deterministic behaviour while in theory
everything should be deterministic.
As a side note: during the startup-phase my static instance counter in
the PRNG instances count up to > 2000. Which indicates that we somehow
are creating 2000+ OscilGen object instances for no good reason, just
while the Audio backend is running idle, prior to sounding the first
note. Which just again shows us that a clean-up of the storage allocation
would be a promising goal for optimisation.
-- Hermann
PS: I am out on travel for a visit the coming day...
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
