On Thu, 3 Jun 2021 03:35:19 +0200 Ichthyostega <p...@ichthyostega.de> wrote:
>> 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... Hmmm 8 voices + 1 padsynth * 16 kit items * 16 parts = 2304 Are we getting an OsclGen call for all of these at startup, even if the item is not active? If you set 32 or 64 parts do you get 4608 and 9216 respectively? -- 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
