Hi all
Audio drop-outs happen, when Pd needs more time to do something than is available (i.e. the configured audio buffer size). The underlying reasons are manifold, often it is because something requiring lots of CPU power is processed in zero logical time. For such of those problems, that can be divided into smaller tasks or those that already are of an iterative nature, [nbuntil] may provide a solution to avoid audio drop-outs.
[nbuntil] works similar to the regular [until], but unlike the original, it breaks Pd's principle of "depth first". It measures how much time each iteration requires and delays the next iteration by this time. By employing [nbuntil], many kinds of tasks can be performed without causing drop-outs, that would otherwise block Pd for a certain amount of time.
Example applications include loading presets or dynamic creation of parts "in the background". Yet, I use it to pre-calculate a set of tables while audio is running. I could imagine using it to create an emulation of a threaded [soundfiler], though a proof of concept is yet lacking and needs to be created. Contrary to Miller's suggestion of using a [readsf~] in an upsampled subpatch, [nbuntil]'s adaptive approach uses the maximum available CPU power.
I'm curios to see whether other people find it useful and even find use cases I haven't thought of yet. Despite its rather simple design, I can't remember having seen this approach discussed here on the list. I'd also be interested if similar or different approaches have been used, but not yet discussed here.
I'm currently not in the urgent need of a vanilla pseudo-threaded [soundfiler], but if there is enough interest, I'd be happy to dedicate some time to it (not totally sure, that it would work, though).
Roman
Why not just trigger each iteration with [bang~]?
-Jonathan
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: Pd List pd-list@iem.at Cc: Sent: Sunday, December 16, 2012 4:51 PM Subject: [PD] [nbuntil]: an non-blocking [until] replacement
Hi all
Audio drop-outs happen, when Pd needs more time to do something than is available (i.e. the configured audio buffer size). The underlying reasons are manifold, often it is because something requiring lots of CPU power is processed in zero logical time. For such of those problems, that can be divided into smaller tasks or those that already are of an iterative nature, [nbuntil] may provide a solution to avoid audio drop-outs.
[nbuntil] works similar to the regular [until], but unlike the original, it breaks Pd's principle of "depth first". It measures how much time each iteration requires and delays the next iteration by this time. By employing [nbuntil], many kinds of tasks can be performed without causing drop-outs, that would otherwise block Pd for a certain amount of time.
Example applications include loading presets or dynamic creation of parts "in the background". Yet, I use it to pre-calculate a set of tables while audio is running. I could imagine using it to create an emulation of a threaded [soundfiler], though a proof of concept is yet lacking and needs to be created. Contrary to Miller's suggestion of using a [readsf~] in an upsampled subpatch, [nbuntil]'s adaptive approach uses the maximum available CPU power.
I'm curios to see whether other people find it useful and even find use cases I haven't thought of yet. Despite its rather simple design, I can't remember having seen this approach discussed here on the list. I'd also be interested if similar or different approaches have been used, but not yet discussed here.
I'm currently not in the urgent need of a vanilla pseudo-threaded [soundfiler], but if there is enough interest, I'd be happy to dedicate some time to it (not totally sure, that it would work, though).
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 17/12/12 08:06, Jonathan Wilkes wrote:
Why not just trigger each iteration with [bang~]?
because with [bang~] you would get a single iteration per block, rather than as many iterations as you have time for ... which seems to be the intention of [nbuntil], and very useful where you might want to do a loop which may be too long for one cycle but you can wait and use the results when they are ready, after a few cycles perhaps.
Simon
----- Original Message -----
From: Simon Wise simonzwise@gmail.com To: pd-list@iem.at Cc: Sent: Sunday, December 16, 2012 7:58 PM Subject: Re: [PD] [nbuntil]: an non-blocking [until] replacement
On 17/12/12 08:06, Jonathan Wilkes wrote:
Why not just trigger each iteration with [bang~]?
because with [bang~] you would get a single iteration per block, rather than as many iterations as you have time for ... which seems to be the intention of [nbuntil], and very useful where you might want to do a loop which may be too long for one cycle but you can wait and use the results when they are ready, after a few cycles perhaps.
Ah I see. So it assumes iterations won't take a majority of a dsp tick.
-Jonathan
Simon
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 2012-12-16 at 23:17 -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Simon Wise simonzwise@gmail.com To: pd-list@iem.at Cc: Sent: Sunday, December 16, 2012 7:58 PM Subject: Re: [PD] [nbuntil]: an non-blocking [until] replacement
On 17/12/12 08:06, Jonathan Wilkes wrote:
Why not just trigger each iteration with [bang~]?
because with [bang~] you would get a single iteration per block, rather than as many iterations as you have time for ... which seems to be the intention of [nbuntil], and very useful where you might want to do a loop which may be too long for one cycle but you can wait and use the results when they are ready, after a few cycles perhaps.
Ah I see. So it assumes iterations won't take a majority of a dsp tick.
No. Assume each iteration usually takes 5 ms under no load. If the CPU core the Pd thread is currently running on is under 50% load, one iteration of the same task would use 10 ms. (This purely hypothetical, I haven't thoroughly tested those cases yet).
Roman
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list@iem.at Cc: Sent: Monday, December 17, 2012 3:07 AM Subject: Re: [PD] [nbuntil]: an non-blocking [until] replacement
On Sun, 2012-12-16 at 23:17 -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Simon Wise simonzwise@gmail.com To: pd-list@iem.at Cc: Sent: Sunday, December 16, 2012 7:58 PM Subject: Re: [PD] [nbuntil]: an non-blocking [until] replacement
On 17/12/12 08:06, Jonathan Wilkes wrote:
Why not just trigger each iteration with [bang~]?
because with [bang~] you would get a single iteration per block,
rather than as
many iterations as you have time for ... which seems to be the
intention of
[nbuntil], and very useful where you might want to do a loop which may
be too
long for one cycle but you can wait and use the results when they are
ready,
after a few cycles perhaps.
Ah I see. So it assumes iterations won't take a majority of a dsp
tick.
No. Assume each iteration usually takes 5 ms under no load. If the CPU core the Pd thread is currently running on is under 50% load, one iteration of the same task would use 10 ms. (This purely hypothetical, I haven't thoroughly tested those cases yet).
What I mean is that if there's a dsp tick every 9ms and each iteration takes 5ms then you're still going to get dropouts because you've got time to start two iterations but not enough time to finish them.
I may be misunderstanding scheduling, though.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Cool, with [nbuntil] the workload is even spread over the cores! So now you can do calculations on long arrays without fear of CPU spikes. And in turn, audio latency may be set to lower level. Great solution Roman, thanks for sharing.
Katja
On Sun, Dec 16, 2012 at 10:51 PM, Roman Haefeli reduzent@gmail.com wrote:
Hi all
Audio drop-outs happen, when Pd needs more time to do something than is available (i.e. the configured audio buffer size). The underlying reasons are manifold, often it is because something requiring lots of CPU power is processed in zero logical time. For such of those problems, that can be divided into smaller tasks or those that already are of an iterative nature, [nbuntil] may provide a solution to avoid audio drop-outs.
[nbuntil] works similar to the regular [until], but unlike the original, it breaks Pd's principle of "depth first". It measures how much time each iteration requires and delays the next iteration by this time. By employing [nbuntil], many kinds of tasks can be performed without causing drop-outs, that would otherwise block Pd for a certain amount of time.
Example applications include loading presets or dynamic creation of parts "in the background". Yet, I use it to pre-calculate a set of tables while audio is running. I could imagine using it to create an emulation of a threaded [soundfiler], though a proof of concept is yet lacking and needs to be created. Contrary to Miller's suggestion of using a [readsf~] in an upsampled subpatch, [nbuntil]'s adaptive approach uses the maximum available CPU power.
I'm curios to see whether other people find it useful and even find use cases I haven't thought of yet. Despite its rather simple design, I can't remember having seen this approach discussed here on the list. I'd also be interested if similar or different approaches have been used, but not yet discussed here.
I'm currently not in the urgent need of a vanilla pseudo-threaded [soundfiler], but if there is enough interest, I'd be happy to dedicate some time to it (not totally sure, that it would work, though).
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Katja
Thanks for your feedback.
On Mon, 2012-12-17 at 11:56 +0100, katja wrote:
Cool, with [nbuntil] the workload is even spread over the cores!
I don't think that [nbuntil] will help in making Pd use more than one core. Since [nbuntil] is just an abstraction, everything run "below" it is still part of the pd process/thread. For fully exploiting many cores, real threading is needed, I suppose.
So now you can do calculations on long arrays without fear of CPU spikes.
That is the idea.
And in turn, audio latency may be set to lower level.
To some degree, probably. There is a certain range for it to work best. If each iteration is too small/fast, the penalty added by [nbuntil] is too big and it will by itself cause drop-outs. OTOH, if a single iteration takes too much time, this will also cause a drop-out (i.e. if it takes longer than the currently configured audio buffer setting). As a rule of thumb, the optimal CPU time for a single iteration to consume is probably around <audio buffer setting>/2.
Regarding your calculations for long arrays and depending on the complexity of your calculations, it might be better to iterate with an outer [nbuntil] loop and an inner [until] loop in order to reach a sensible iteration time for [nbuntil].
Roman
On Mon, Dec 17, 2012 at 1:21 PM, Roman Haefeli reduzent@gmail.com wrote: ...
On Mon, 2012-12-17 at 11:56 +0100, katja wrote:
Cool, with [nbuntil] the workload is even spread over the cores!
I don't think that [nbuntil] will help in making Pd use more than one core. Since [nbuntil] is just an abstraction, everything run "below" it is still part of the pd process/thread. For fully exploiting many cores, real threading is needed, I suppose.
You're right, your abstraction exploits threading which is already done. When running [nbuntil-help] on OSX, I notice CPU increase for both cores in Activity Monitor. But it is also the case with regular [until] in the patch.
Following the principle in [nbuntil], it would be possible to make a general abstraction for deferring subsequent tasks with low priority, no? Let's say [defer], a variation on [pipe], but where delay is proportional to CPU load. This could then be used in any straight sequence of subpatches which do a substantial amount of operations each.
Katja
Katja
On Mon, Dec 17, 2012 at 4:18 PM, katja katjavetter@gmail.com wrote:
On Mon, Dec 17, 2012 at 1:21 PM, Roman Haefeli reduzent@gmail.com wrote: ...
On Mon, 2012-12-17 at 11:56 +0100, katja wrote:
Cool, with [nbuntil] the workload is even spread over the cores!
I don't think that [nbuntil] will help in making Pd use more than one core. Since [nbuntil] is just an abstraction, everything run "below" it is still part of the pd process/thread. For fully exploiting many cores, real threading is needed, I suppose.
You're right, your abstraction exploits threading which is already done. When running [nbuntil-help] on OSX, I notice CPU increase for both cores in Activity Monitor. But it is also the case with regular [until] in the patch.
Wait this is not a matter of threading of course, the process is just switching between cores.
Katja