<div dir="ltr">well, i did mention that it was PD 0.49 but i did experiment with a lot of different versions - 64 bit, 32 bit vanilla as well as CEAMMCs distribution in 32 and 64 bit. so, point taken. so far seems be fairly decent. this patch mainly does sample or synth based live playback - it's not heavy on FFT functions as yet.<div><br></div><div>thanks for the tips!</div><div><br></div><div>best,</div><div>scott</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 27, 2019 at 11:29 AM Christof Ressi <<a href="mailto:christof.ressi@gmx.at">christof.ressi@gmx.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">In pd's regular scheduler, the main thread computes audio and pushes the samples to a lockfree ringbuffer. The actual audio callback runs in a different thread and polls samples from the ringbuffer as needed. This mechanism is important for Pd because the audio thread performs many unbounded operations which are not real-time-safe. This is a consequence of its deterministic architecture.<br>
<br>
On the other hand, an application like supercollider has very strict rules about what shall be done on the audio thread, so audio can be computed directly in the audio callback. Non-realtime operations are performed asynchronously in a worker thread. Both threads communicate via a lockfree command FIFO. One could say that Supercollider's architecture is indeterministic. This indeterminacy can be partially overcome by scheduling commands in advance using timestamps. So there's again a trade-off between latency and accuracy.<br>
<br>
Christof<br>
<br>
> Gesendet: Freitag, 27. September 2019 um 19:31 Uhr<br>
> Von: "Martin Peach" <<a href="mailto:chakekatzil@gmail.com" target="_blank">chakekatzil@gmail.com</a>><br>
> An: Pd-List <<a href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a>><br>
> Betreff: Re: [PD] stability of PD on Windows?<br>
><br>
> On Fri, Sep 27, 2019 at 12:24 PM Christof Ressi <<a href="mailto:christof.ressi@gmx.at" target="_blank">christof.ressi@gmx.at</a>><br>
> wrote:<br>
><br>
> > > For me the audio is distorted unless I also tick "Use Callbacks".<br>
> ><br>
> > Really, even if you use an ASIO driver? I never had the experience that<br>
> > "Use Callbacks" improves things, on the contrary. Also, it's worth noting<br>
> > that with "Use Callbacks", the "delay" parameter doesn't do any thing, the<br>
> > latency can only be set with the ASIO block size.<br>
> ><br>
><br>
> I don't know which ASIO driver I'm using, maybe it came with the interface<br>
> (I selected "ASIO:Focusrite USB 2.0 Audio Driver" in the dialog). I tried<br>
> various delays with no callbacks and now I get no distortion with a delay<br>
> of 11 or more and block size 64. With Delay less than 11 the audio is<br>
> chopped up.<br>
> Without callbacks, I get clicks and dropouts occasionally if I do things<br>
> with the mouse. That's why I assumed it was the better choice. (Doesn't<br>
> audio processing always use callbacks anyway? Otherwise the program must<br>
> sit in a loop serving samples. What callbacks are these?)<br>
><br>
> Martin<br>
> _______________________________________________<br>
> <a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
><br>
<br>
<br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
</blockquote></div>