This has nothing to do with callback mode, as such. it is a general
performance note included to illustrate the various things that I
discovered, often with much debugging of PD itself, which affect
performance.
Ok, I see. Note that *receiving* messages is more or less fine because
the I/O
On Thu, 24 Aug 2023 at 14:12, Christof Ressi wrote:
> Perhaps. But I was definitely able to manually bump the priority without
> sudo.
>
> I don't doubt that you can manually bump the priority; that doesn't
> necessarily mean that Pd itself can do it.
>
> BTW, if Pd fails to raise the thread
Perhaps. But I was definitely able to manually bump the priority
without sudo.
I don't doubt that you can manually bump the priority; that doesn't
necessarily mean that Pd itself can do it.
BTW, if Pd fails to raise the thread priority to RT, you should get the
following error message in the
On Wed, 23 Aug 2023 at 23:24, Christof Ressi wrote:
> I actually get fewer xruns in callback mode,
>
> This sounds highly unlikely. Maybe your "delay" setting is too low? Or Pd
> is not actually running with realtime priority?
>
I spent a lot of time testing this on an ancient laptop running a
I actually get fewer xruns in callback mode,
This sounds highly unlikely. Maybe your "delay" setting is too low? Or
Pd is not actually running with realtime priority?
I also bump the sound-generation process up to realtime priority.
Pd itself already tries to raise the thread priority; if
For what it's worth, I actually get fewer xruns in callback mode, but I am
running computation-heavy externals for much of my sound design so YMMV. I
also bump the sound-generation process up to realtime priority.
On Wed, 23 Aug 2023 at 15:39, Joseph Larralde
wrote:
> Wow, thanks again
Ah, I thought you were talking about the "polling mode vs callback mode"
thing. Yes, the API docs should mention in which context a function may
or may not be called.
For example, functions that can be safely called in perform routines may
be annotated with something like "\qualifier
Well, I don't mean documentation all internal mechanisms but, in this case, it
might have been helpful to at least note *which* functions should or shouldn't
be called in which situations. For instance, I note which libpd functions *not*
call when DSP is running.
> On Aug 23, 2023, at 5:30
5:05 PM, pd-dev-requ...@lists.iem.at wrote:
Message: 1
Date: Wed, 23 Aug 2023 17:04:41 +0200
From: Christof Ressi
To:pd-dev@lists.iem.at
Subject: Re: [PD-dev] why must one never send a message from a perform
routine ?
Message-ID: <7a96c4d0-10ec-1d18-b016-df0304498...@christofressi.com>
lists.iem.at>
> Subject: Re: [PD-dev] why must one never send a message from a perform
> routine ?
> Message-ID: <7a96c4d0-10ec-1d18-b016-df0304498...@christofressi.com
> <mailto:7a96c4d0-10ec-1d18-b016-df0304498...@christofressi.com>>
> Content-Type: text/plain
Glad that I could help! Very little of this is really documented
(accurately). Personally, I figured this out by reading the source code.
Ideally, we should improve the official documentation in
http://msp.ucsd.edu/Pd_documentation/x3.htm#s1.0. Some things are
outdated, misleading or just
Wow, thanks again Christof, this greatly improves my understanding of
Pd's engine.
Indeed, I never use callback mode because everytime I did in the past I
got some xruns, but had no clue about what was happening behind the scene.
I feel a bit ashamed, I'm pretty sure I could have figured this
I've always been puzzled by the fact that everything runs on a single
thread in Pd.
By default, Pd operates in "polling mode", i.e. the scheduler runs in
its own thread (the main thread) and communicates with the audio
callback via two lockfree ringbuffers (one for input, one for output).
Thanks Christof for the additional insight.
I've always been puzzled by the fact that everything runs on a single
thread in Pd.
I guess this single thread IS the audio thread because it processes
audio, and I've always heard that one must never perform too many
non-audio operations during an
How well does it work?
It seems to work quite well. With synthetic benchmarks I can get a 6x
speedup on my 8 core machine, but I need to do some more practical
testing and benchmarking.
It looks like the repo is based off of 0.52?
I think it's based on 0.53. I want to rebase it on 0.54, but
How well does it work? It looks like the repo is based off of 0.52?
Multithreaded DSP would have been much higher on my list than
multi-channel, so I'm wondering if I could get away with using your tree as
my basis for a while :)
- d
On Tue, 22 Aug 2023 at 01:17, Christof Ressi wrote:
> To
To expand on Miller's reply:
Conceptually, messaging and DSP are two separate domains. Sending a
message from a perform routine violates this separation. Instead you
should use a clock with delay 0 to defer the message to the begin of the
next scheduler tick.
Miller already mentioned the
Hmm, I see ... unfortunately my random bug is totally unrelated to this
weakness of my code.
Thanks Miller for the explanation and pointers to examples !
And thanks Claude for the extra example.
I'll check all my objects to see if there are other ones I can consolidate.
Cheers !
Joseph
Le
See bang~ in pure-data/src/d_misc.c for an example that uses a clock to
send a message from DSP.
On 21/08/2023 18:02, Miller Puckette wrote:
The built-in objects "delay", "metro" and "pipe" use clocks in various
ways.
On 8/21/23 18:02, Joseph Larralde wrote:
I just read in an answer from
Hi Joseph -
If you send a message from within the DSP chain that causes the chain
itself to be rebuilt it will crash Pd. That's not a thread problem, but
a (sort of) reentrancy problem. If you're the only user of your object
you can simply avoid doing that, but if you're publishing your
Howdy,
I just read in an answer from Christof to Alexandre : "never ever send a
Pd message directly from a perform routine ! Always use a clock !"
But I never took the time to deeply understand Pd's inner working and am
not sure why it is bad practice.
Not sure what could be the consequences
21 matches
Mail list logo
