Hey all
Using callbacks is certainly interesting for low-latency applications. I noticed that JACK allows blocksizes below 64, namely 32 and 16. However, those can only be used with callbacks disabled which means having to use an additional buffer again.
I wonder if the blocksize of 64 is deeply baked into Pd or if it could theoretically be made configurable. There might be other reasons why smaller (or larger) blocksizes would be interesting, but low-latency seems to be one.
I found the '-blocksize' flag, but it seems it only sets the blocksize for audio I/O and doesn't affect Pd's internal blocksize (and doesn't have any effect at all when running with -jack).
Roman
- Roman Haefeli reduzent@gmail.com [2022-01-12 15:08]:
Hey all
Using callbacks is certainly interesting for low-latency applications. I noticed that JACK allows blocksizes below 64, namely 32 and 16. However, those can only be used with callbacks disabled which means having to use an additional buffer again.
I wonder if the blocksize of 64 is deeply baked into Pd or if it could theoretically be made configurable.
Sorry, I didn't check this myself, but can {block~] be used in a top-level patch perhaps?
cheersz, P
On Wed, 2022-01-12 at 15:28 +0100, Peter P. wrote:
- Roman Haefeli reduzent@gmail.com [2022-01-12 15:08]:
Hey all
Using callbacks is certainly interesting for low-latency applications. I noticed that JACK allows blocksizes below 64, namely 32 and 16. However, those can only be used with callbacks disabled which means having to use an additional buffer again.
I wonder if the blocksize of 64 is deeply baked into Pd or if it could theoretically be made configurable.
Sorry, I didn't check this myself, but can {block~] be used in a top-level patch perhaps?
According to the documentation, [dac~ ]/[adc~] cannot reside in re- blocked (sub)patches. There is no mentioning of top-level patches.
However, my point was to allow to connect pd to jack running at bs=32 or bs=16 _with_ callbacks.
Roman
Hi Roman,
I wonder if the blocksize of 64 is deeply baked into Pd or if it could theoretically be made configurable.
Pd's scheduler block size is a constant value (64 samples), defined as DEFDACBLKSIZE in "s_stuff.h".
In theory, you can change the #define in "s_stuff.h" and recompile Pd (and all externals, just in case some of them rely on it), but that's obviously not a good solution.
Now, the "callbackprocess" function in "s_audio_jack.c" checks if the Jack block size is multiple of DEFDACBLKSIZE. As you noticed, this breaks for Jack buffer sizes smaller than DEFDACBLKSIZE.
Actually, Pd's Jack callback implementation could use a small ring buffer for such situations. For example, if the Jack blocksize was 16 samples, Pd would call m_audio_callbackfn() every 4 blocks to fill the buffer. Note that you would still have 48 samples of extra latency, but at least sound would be working :-)
Generally, there is no way to get lower I/O latency than 64 samples in Pd without changing DEFDACBLKSIZE and recompiling.
I found the '-blocksize' flag, but it seems it only sets the blocksize for audio I/O and doesn't affect Pd's internal blocksize
Yes. "block size" is really a misnomer. At least it should be called "hardware blocksize" or even "hardware buffer size". It does *not* set Pd's scheduling block size, which is really fixed at 64 samples.
(and doesn't have any effect at all when running with -jack).
In the case of Jack, the hardware blocksize can't be set dynamically in the client. Instead, Pd obtains the value from the Jack server. The same is true for the sample rate, btw.
Hi
Thanks for your detailed explanations, Christof.
On Wed, 2022-01-12 at 16:13 +0100, Christof Ressi wrote:
Generally, there is no way to get lower I/O latency than 64 samples in Pd without changing DEFDACBLKSIZE and recompiling.
I guess my question boils down to: Is it possible to make that a configurable (at runtime) parameter? Would it be worthwhile feature besides an assumingly lower latency in special cases?
Roman
On 1/12/22 21:04, Roman Haefeli wrote:
I guess my question boils down to: Is it possible to make that a configurable (at runtime) parameter? Would it be worthwhile feature besides an assumingly lower latency in special cases?
i prepared a patch that did that in 2004 or so. i don't think i still have it anywhere (though you could check on sourceforge).
gdsmf IOhannes
I was curious so I compiled pd-0.52-1 on linux, with DEFDACBLKSIZE set to 16. I set Jack up with buffer size 16, and run pd with jack backend.
Most of the patches in the help browser works, but at least these objects fail to load: sigcatch : unexpected vector size throw~ : vector size mismatch receive~ : vector size mismatch sigsend : unexpected vector size
In the options for ALSA, the current block size is displayed correctly as 16 but you cannot select it again once you change it.
Athos
Il giorno mer 12 gen 2022 alle ore 21:57 IOhannes m zmölnig zmoelnig@iem.at ha scritto:
On 1/12/22 21:04, Roman Haefeli wrote:
I guess my question boils down to: Is it possible to make that a configurable (at runtime) parameter? Would it be worthwhile feature besides an assumingly lower latency in special cases?
i prepared a patch that did that in 2004 or so. i don't think i still have it anywhere (though you could check on sourceforge).
gdsmf IOhannes _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
The objects in "d_global.c" use their own constant DEFSENDVS (for whatever reason) which you would have to change as well. Same for DEFDELVS in "d_delay.c".
Christof
On 14.01.2022 23:17, Athos Bacchiocchi wrote:
I was curious so I compiled pd-0.52-1 on linux, with DEFDACBLKSIZE set to 16. I set Jack up with buffer size 16, and run pd with jack backend.
Most of the patches in the help browser works, but at least these objects fail to load: sigcatch : unexpected vector size throw~ : vector size mismatch receive~ : vector size mismatch sigsend : unexpected vector size
In the options for ALSA, the current block size is displayed correctly as 16 but you cannot select it again once you change it.
Athos
Il giorno mer 12 gen 2022 alle ore 21:57 IOhannes m zmölnig zmoelnig@iem.at ha scritto:
On 1/12/22 21:04, Roman Haefeli wrote: > I guess my question boils down to: Is it possible to make that a > configurable (at runtime) parameter? Would it be worthwhile feature > besides an assumingly lower latency in special cases? i prepared a patch that did that in 2004 or so. i don't think i still have it anywhere (though you could check on sourceforge). gdsmf IOhannes _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
On Fri, 2022-01-14 at 23:17 +0100, Athos Bacchiocchi wrote:
I was curious so I compiled pd-0.52-1 on linux, with DEFDACBLKSIZE set to 16. I set Jack up with buffer size 16, and run pd with jack backend.
Most of the patches in the help browser works, but at least these objects fail to load: sigcatch : unexpected vector size throw~ : vector size mismatch receive~ : vector size mismatch sigsend : unexpected vector size
Oh, interesting. Haven't tried myself yet, but good to know that many patches wouldn't work. I can't get around using [receive~].
In the options for ALSA, the current block size is displayed correctly as 16 but you cannot select it again once you change it.
That makes sense. The menu dialog code would probably need to be adapted for that.
Roman
Oh, interesting. Haven't tried myself yet, but good to know that many patches wouldn't work. I can't get around using [receive~].
Have you seen my last reply (https://lists.puredata.info/pipermail/pd-list/2022-01/130716.html)? It describes how to fix this. (I would not recommend doing this in practice, though.)
If more people think that they need to run Pd at a lower scheduler block size, we should think about making it a runtime option. AFAICT, there is no technical reason why it has to be a compile time constant.
Christof
On 1/15/22 2:20 PM, Roman Haefeli wrote:
On Fri, 2022-01-14 at 23:17 +0100, Athos Bacchiocchi wrote:
I was curious so I compiled pd-0.52-1 on linux, with DEFDACBLKSIZE set to 16. I set Jack up with buffer size 16, and run pd with jack backend.
Most of the patches in the help browser works, but at least these objects fail to load: sigcatch : unexpected vector size throw~ : vector size mismatch receive~ : vector size mismatch sigsend : unexpected vector size
Oh, interesting. Haven't tried myself yet, but good to know that many patches wouldn't work. I can't get around using [receive~].
In the options for ALSA, the current block size is displayed correctly as 16 but you cannot select it again once you change it.
That makes sense. The menu dialog code would probably need to be adapted for that.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Christof
On Sat, 2022-01-15 at 15:51 +0100, Christof Ressi wrote:
Oh, interesting. Haven't tried myself yet, but good to know that many patches wouldn't work. I can't get around using [receive~].
Have you seen my last reply ( https://lists.puredata.info/pipermail/pd-list/2022-01/130716.html)? It describes how to fix this. (I would not recommend doing this in practice, though.)
Yeah, thanks, I read it _after_ I wrote my last mail. That's good to know.
If more people think that they need to run Pd at a lower scheduler block size, we should think about making it a runtime option. AFAICT, there is no technical reason why it has to be a compile time constant.
It's not that I'm requesting it, but if it was there, I'd certainly play around with it. I just wanted to check if it is feasible and also if it makes sense at all. If this is a sensible thing, I'll put it into a feature request.
Roman
I tried setting DEFSENDVS, DEFDELVS to 16 as well, and everything seems to be working fine now.
(I would not recommend doing this in practice, though.)
Why wouldn't you recommend it? (I am assuming you were referring to changing the DEFSENDVS/DEFDELVS define values).
I agree that it would be nice to have the "internal/rendering" blocksize of Pd be a runtime parameter as well.
If I understand correctly, one would have to:
- Add a runtime flag, eg. -rendering-blocksize (as opposed to the existing
-blocksize)
- Modifying all the code depending on the DEFDACBLKSIZE to use the run-time
value instead. I guess one way to do this would be providing the value through a global function so that the value cannot be changed from anywhere but the startup code.
- Have the default value of this now modifiable rendering block size still
be 64 for backward compatibility
- Making sure that the io block size is always forced to be at least the
size of the rendering block size
- For alsa settings, add the additional values that can be set to the menu
for the io block size
Would that be enough?
As for the need for it, I would personally use it, I tuned my linux system to run at 16 samples but I cannot use such settings when I want to run Pd (I can with Bitwig and Bespoke synth). In general I think that nowadays it would be useful, considering linux and Pd can be run in all sorts of embedded devices that in turn are part of more complex signal chains (eg: guitar pedalboards) together with several other digital gadgets, with all the latencies adding up.
Also, if I understand correctly, this would improve the time granularity with control-rate objects and messages... even though on the other end it might increase the relative overhead of the control-rate processing compared to the audio-rate one.
Athos
As for the need for it, I would personally use it, I tuned my linux system to run at 16 samples but I cannot use such settings when I want to run Pd (I can with Bitwig and Bespoke synth).
Sorry , a little off topic ...
how exactly did you achieve that ? could you provide some specs ? (linux distro, kernel, tweaks, JACK or ALSA, soundcard)
i never succeeded in getting any reasonable latency out of BITWIG (the "real" latency of let's say a pushed midi trigger and the soundfile in a slot being started was always much bigger than stated), so i ditched it in the end.
BESPOKE looks awesome, will dig into it ...
FWIW, i find REAPER a great program to team up with PD (via OSC communication), though i'm still not at the desired latency i'm looking for (any "real" latency less than 10ms would be fine with me)
thanks for any hints
best
oliver
You can use camomile (github.com/pierreguillot/Camomile) to wrap Pd inside a VST for 64-sample latency back and forth.
cheers Miller
On Sun, Jan 16, 2022 at 05:38:34PM +0100, oliver wrote:
As for the need for it, I would personally use it, I tuned my linux system to run at 16 samples but I cannot use such settings when I want to run Pd (I can with Bitwig and Bespoke synth).
Sorry , a little off topic ...
how exactly did you achieve that ? could you provide some specs ? (linux distro, kernel, tweaks, JACK or ALSA, soundcard)
i never succeeded in getting any reasonable latency out of BITWIG (the "real" latency of let's say a pushed midi trigger and the soundfile in a slot being started was always much bigger than stated), so i ditched it in the end.
BESPOKE looks awesome, will dig into it ...
FWIW, i find REAPER a great program to team up with PD (via OSC communication), though i'm still not at the desired latency i'm looking for (any "real" latency less than 10ms would be fine with me)
thanks for any hints
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
This sounds reasonable. I have made a feature request on GitHub: https://github.com/pure-data/pure-data/issues/1549
When I have time, I can make a PR. Or maybe someone else wants to do it?
Christof
On 16.01.2022 17:15, Athos Bacchiocchi wrote:
I tried setting DEFSENDVS, DEFDELVS to 16 as well, and everything seems to be working fine now.
(I would not recommend doing this in practice, though.)
Why wouldn't you recommend it? (I am assuming you were referring to changing the DEFSENDVS/DEFDELVS define values).
I agree that it would be nice to have the "internal/rendering" blocksize of Pd be a runtime parameter as well.
If I understand correctly, one would have to:
- Add a runtime flag, eg. -rendering-blocksize (as opposed to the
existing -blocksize)
- Modifying all the code depending on the DEFDACBLKSIZE to use the
run-time value instead. I guess one way to do this would be providing the value through a global function so that the value cannot be changed from anywhere but the startup code.
- Have the default value of this now modifiable rendering block size
still be 64 for backward compatibility
- Making sure that the io block size is always forced to be at least
the size of the rendering block size
- For alsa settings, add the additional values that can be set to the
menu for the io block size
Would that be enough?
As for the need for it, I would personally use it, I tuned my linux system to run at 16 samples but I cannot use such settings when I want to run Pd (I can with Bitwig and Bespoke synth). In general I think that nowadays it would be useful, considering linux and Pd can be run in all sorts of embedded devices that in turn are part of more complex signal chains (eg: guitar pedalboards) together with several other digital gadgets, with all the latencies adding up.
Also, if I understand correctly, this would improve the time granularity with control-rate objects and messages... even though on the other end it might increase the relative overhead of the control-rate processing compared to the audio-rate one.
Athos
On Bela we've been running with blocksize of 8 for a few years since 2016 and then we moved to 16 samples per block around 2018 I think (in both cases redefining the problematic constants). I think only in a couple of occasions this caused an incompatibility with a couple of externals relying on a hardcoded value of 64 instead of taking DEFDACBLKSIZE value from s_stuff.h.
Another drawback is the CPU penalty of running smaller blocks (which is what made us switch from 8 to 16 samples per block at the time). Smaller blocksizes means in general higher CPU usage. When running with a larger buffer size (which may be desirable when CPU performance is more important than latency), if the blocksize is hardcoded, the CPU penalty remains.
A runtime value would be a beneficial change for us.
Christof Ressi wrote on 16/01/2022 18:04:
This sounds reasonable. I have made a feature request on GitHub: https://github.com/pure-data/pure-data/issues/1549
When I have time, I can make a PR. Or maybe someone else wants to do it?
Christof
On 16.01.2022 17:15, Athos Bacchiocchi wrote:
I tried setting DEFSENDVS, DEFDELVS to 16 as well, and everything seems to be working fine now.
(I would not recommend doing this in practice, though.)
Why wouldn't you recommend it? (I am assuming you were referring to changing the DEFSENDVS/DEFDELVS define values).
I agree that it would be nice to have the "internal/rendering" blocksize of Pd be a runtime parameter as well.
If I understand correctly, one would have to:
- Add a runtime flag, eg. -rendering-blocksize (as opposed to the existing -blocksize)
- Modifying all the code depending on the DEFDACBLKSIZE to use the run-time value instead. I guess one way to do this would be providing the value through a global function so that the value cannot be changed from anywhere but the startup code.
- Have the default value of this now modifiable rendering block size still be 64 for backward compatibility
- Making sure that the io block size is always forced to be at least the size of the rendering block size
- For alsa settings, add the additional values that can be set to the menu for the io block size
Would that be enough?
As for the need for it, I would personally use it, I tuned my linux system to run at 16 samples but I cannot use such settings when I want to run Pd (I can with Bitwig and Bespoke synth). In general I think that nowadays it would be useful, considering linux and Pd can be run in all sorts of embedded devices that in turn are part of more complex signal chains (eg: guitar pedalboards) together with several other digital gadgets, with all the latencies adding up.
Also, if I understand correctly, this would improve the time granularity with control-rate objects and messages... even though on the other end it might increase the relative overhead of the control-rate processing compared to the audio-rate one.
Athos
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Athos Bacchiocchi -
Christof Ressi -
Giulio Moro -
IOhannes m zmölnig -
Miller Puckette -
oliver -
Peter P. -
Roman Haefeli